axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: Requiring LaTeX


From: C Y
Subject: Re: [Axiom-developer] Re: Requiring LaTeX
Date: Fri, 1 Sep 2006 19:51:00 -0700 (PDT)

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 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]