I would have to disagree, Charlie. If Mitel truly absorbed contribs at a high rate, then your proposition makes sense. Bug fixes and minor enhancements, yes, I have to agree Mitel are responsive. However, full fledged contribs that add non-trivial functionality to the system are not that often added to the base distribution. And as changes to the stock templates are often required in order to accomplish such things, some forking is inevitable. I submit it is unreasonable to expect all contribs to become part of the base stream, and equally unreasonable to expect contribs to not modify base template functionality. Note that adding a custom template does not fork the base distribution -- doing it your way, creating a modified base distribution package, DOES fork the distribution.
Anyway, if you fork base packages to handle base template modifications, then having this contrib's version of a base package, and then that contrib's version of the same base package, creates as much confusion as it solves. I don't believe that is the answer.
For example, let's say for whatever reason I have a different way of handling proxies, but it is not something that Mitel will adopt anytime soon -- if ever. That is a very likely scenario as history bears out. This hypothetical contrib needs to replace the */etc/httpd/conf/httpd.conf/35ProxyPass template, since my contrib will be handling proxypass entries. No way around it -- I'm doing the ProxyPass handling, so a new fragment won't do. I have to replace the stock template.
Am I supposed to write my template to the */templates directory, replacing the stock template? I think not, as that would be bad form. For a number of reasons, including but not limited to those mentioned above. I'm frankly surprised you would suggest anyone or anything other than Mitel modify the stock templates. Those are the baseline and the failsafe. And how many times have you yourself cautioned folks to not modify the stock templates? And how many people have posted the "I did this or that, installed this or that, and now I want to go back" message on the forums. If you don't modify the baseline, going back is easy.
Back to our scenario, do I write it into the */templates-custom diretory? Maybe, but now I have to worry about whether or not a user has their own custom 35ProxyPass template, and how to handle it if they do. Using --force would be bad form as well. It is not my domain to overwrite someone else's work. I can create a warning message and install my template to something like 35ProxyPass.1, or can move the existing template to a .1 file. Either way, the double expansion is unlikely to produce desirable results.
So maybe I copy the existing template to some /tmp file, or my new template, and then warn the user. Not elegant, either.
The problem is, I have no way of knowing if an existing template in templates-custom came from another contrib, or is the hard work of a local end-user. We don't have to feel so bad if we overwrite a contrib template. Unpleasant, but a conflict that would need to be solved. Overwriting some local guy's work, though, that can be very bad news.
If I'm installing into a templates-contrib area and I happen to wonk on some other contrib's files, at least I still have my baseline and the other package can be reloaded and I've not killed any hard work by the local user. Sure, if it another contrib's file, then there's a conflict to be resolved. Hopefully, if contrib authors are worth their salt, they'll have tested enough to know when/where conflicts occur and have already provided alternatives. Or at the very least, when the conflict is first reported, they'll work together to reach a quick resolution.
There is no ideal solution, of course. But I think the concept of a "vendor" or "contrib" or "addon" template area has enough merit to warrant consideration. I think we can all agree that the stock templates should not be modified except via official Mitel updates. Having that stock fallback point is a very good option. It also seems reasonable that end-user local customizations should not be subject to replacement by either Mitel or contributed packages. Which leaves the dilema, what is a good way to allow contrib customizations, essentially third-party software, to be installed but without worry of modifying the stock templates nor interfering with local modifications.
Perhaps an alternative is to use a template registration system, but that implies some extra effort in the creation of a management interface. The current directory based system has elegance in its simplicity.
I don't think patching base distributions is the answer. Nobody can righly reconcile how to install
e-smith-base-1.2.3-contribA
e-smith-base-1.2.3-contribB
e-smith-base-1.2.3-contribC
if they each are modifying the same template. Last installed wins? How is this better in any way?
I think the faulty assumption is that contrib and custom templates are somehow forks of the base distribution. Taking an e-smith-*.rpm and changing it, that is a fork. Creating a contrib to do something new and different is not a fork. At whatever time Mitel decides to include the contrib in the base distribution, then it is up to Mitel and perhaps the original developer to manage the proper integration with the base (or new) packages. Then, if and only if development continues in the original contrib, you might argue that it is a fork. The integration work? You'd have to do it anyway, what with various forks of the base packages floating around if we handle it as you propose.
Here's the problem, Charlie. If I take the appropriate e-smith-* packages and implement the templates-contrib capability, how long do you suppose it would be before it becomes part of the base release? Until it does, I have would have forked the distribution. Would anyone use such a feature? Not if they are smart, not until it is part of the base. Since Mitel does not publicize roadmaps or endorse new feature development (endorse meaning, if you build it we WILL include it), then it is not worth my effort to develop what will only be a fork in the code with no assurance that it will persist as part of the product, and it is not worth anyone else's efforts do use it if I did develop it since it might become obsolete or non-functional at any time. That, I believe, is the #1 hindrance to development within the community by any other than a handful of hardcore devotees and those who receive paychecks from Mitel.
On the other hand, if I create a replacement for 35ProxyPass, don't put it into a forked e-smith-* base RPM, and had a templates-contrib directory in which to install it, would anyone use it? Sure, why not? It would not affect the development of the base package at all. And it has all the peaceful co-existance described above.
By the way, if I were to fork a base package and include my 35ProxyPass, what happens when Mitel releases an update that does not include my changes but wants to install a new 35ProxyPass file? Is the Mitel package going to know that the template has been replaced and not overwrite it? Probably not. I would likely have to go back and reinstall the contrib to regain the prior functionality. That would be pointless and unnecessary.
Okay, enough examples and questions and hypothesizing. As I said, there is probably not a perfect solution. I happen to strongly believe that have a third template area is a better solution than what we currently have. And disagree completely with your view as to what constitutes forking the base system.
Scott
5 Replies
1561 Views