If I may, I have a couple questions/observations: 1) If there is functionality developed in a branch, what are the mechanisms for deciding if this functionality will become part of the "main" branch? This is not clear currently.
2) One view of having large numbers of divergent branches is that it splits project resources across many uncoordinated efforts, diluting the effect each branch can achieve - the "many-branches" development model is a lot like forking, which open source has an adversion too except under extreme circumstances (like XFree86 vs. X.org). The reason for this is simple - development in isolation increases the risk that a significant development effort will result in work that is not accepted by the large community as part of the "official" distribution, and dilutes effort which could have made the original project better. Marketing dictates that users, with understandably limited attention spans, will not wish to expend the effort to understand many similar forks of software. When competiting for that attention, focus is critical. How do many individual divergent branches impact the user perception of Axiom as a focused product likely to deliver results? 3) If we are going to require TeX/LaTeX as a core component, what is the minimal subset of (say) TeTeX and MikTeX that will provide us with the functionality we need to create pamphlet file builds? We include GCL because it prevents issues with GCL as a separate program, and now the evidence suggests that this procedure might also be needed if LaTeX is never to be an issue on any platform. I understand the desire to have full functionality with minimal requirements from the system - on Windows it is almost essential. But with automake/autoconf we should be able to have our cake and eat it too. If the only way to resolve this is to have either an external-latex or internal-latex build option and build whatever subset of TeX is actually required for Axiom, how difficult would that be to achieve? A good open source project always requires some compromise, so if I may let me suggest we see if there is some solution that can be found which lets us move forward. As I understand it: a) One side of this argument is that any build options which encourage the use of non-literate programming styles of development should be discouraged in order to promote the usage of literate programming as a style. b) Another side is that minimal testing of machine-program functionality on systems without LaTeX is a valid check on the portability of Axiom to the new platform. What about this? If we accept that LaTeX is an indespensible part of the build process, we treat it like GCL and provide enough of TeX and LaTeX internally to produce what we need. However, we also create a config option which will check only the machine level code, including the building of TeX itself. (If TeX doesn't build on a platform this will be held a bug Axiom must deal with, the same as a GCL bug.) This will accomidate work styles different from that of the fully literate program writer (which is a rare breed both in terms of training and the skill level needed), and ultimately any patches submitted back to Axiom (from whatever source) must be quality vetted by the core team anyway in order to ensure the standards have been met. The default settings will not neglect the LaTeX build - a developer would have to specifically seak out a way to not build the LaTeX based components of the system. Similar to the "--without-X" option in some software - you don't go looking for it unless there is a reason you want it. We can argue about whether there SHOULD be a reason to want it, but the tool is there for those who want to use it. Coversion to literate programming is a gradual process, I think, and making it smoother/more gradual for those new to it is most likely a good idea - in the end, those who might have given up early can be eased onto the hook ;-) The drawback, of course, is that this would be one more bundled package in Axiom. However, the autoconf work should make this ultimately an optional choice - download only Axiom and try to build using only externals (GCL, LaTeX) or download a much larger system that requires only the most rudimentary bootstrapping binaries conceivable. There are two philosophies at work here, and I would rather see both accomidated to some degree and allow us to keep our coherence as a project. But that's just me. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
