So what next?

[Paul Anderson]

Stuart Anderson wrote:

> On Tue, 13 Apr 2004, Egbert Eich wrote:
> 
> > 1. I'm not sure if those conference calls should be the basis of this
> >    decision as they don't seem to represent the majority of developers.
> 
> It was representative of the majority of developers that were participating
> at the time.
> 
> >    Although I ask how the group could have reached a consensus when
> >    the majority of the people of the group have not even looked at the
> >    code.
> 
> The decision, was to declare a long term goal. There wan't much code to look
> at at the time, which is why the caveat was allowed that this was not a
> do-or-die situation. If the decision turned out to be obviously wrong, it
> would be reversed.
> 
> My point in bringing this up was to let everyone know that this decision
> was made to set this as a goal, and that they would be rehashing old ground
> if we went all the way back to the begining. Instead, I would rather see
> everyone focus on answering the outstanding questions, and proving that it
> was a good decisions. I think this would be more productive than backing up
> and questioning our own decisions.
> 
> If the answers to the questions are not satisfactory, then the question can
> be raised as to wether we should reverse the decision. The answers still need
> some come first, either way.
> 
> > 2. Furthermore I seem to remember that the consensus was that it is too
> >    erly to make a final decision since not everything seemed to have
> >    stabilized at the time this was discussed.
> 
> There has been some question as to the timing of when to switch to a modular
> release, but I don't think the goal of switching to a modular release has
> really been in questions.
> 
> > 3. We need to distinguish between a modular build environemnt and
> >    the choice of tools to achive this. Having a rough consensus on
> >    the former one doesn't necessarily mean that everybody agrees on
> >    the latter one.
> 
> It should be possible to use different tools to pull together the different
> modules. I think the agreement on the current tool is based on the fact that
> it seems to work "well enough". That certainly doesn't stop someone from
> building a new tool that does the job better.
> 
> >
> >  >
> >  > There may be a couple of things that are yet unproven, so we should clearly
> >  > identify what these are, and push to prove them to everyones satisfaction.
> >
> > There are definitly a bunch of things that I've brought forward that
> > haven't been answered.
> 
> I think we are much more knowledgable about the modular tree now, and can
> provide meannigful answers to the outstanding questions.
> 
> > The choice of build tools - which I consider suboptimal for our purposes -
> > has been made by a small group not representing the majority of developers
> > and it's possible that it doesn't even meet the needs of those who have
> > not been involved.
> 
> The decision was made by those that were putting forth the effort to get
> the work done. That doesn't seem to be unreasonable, nor does it preclude
> further discussion about a better tool.
> 
> > I don't think it is that easy. For some people there are other conditions
> > to be met than just build the tree in a straight forward and semi-automated
> > way.
> 
> These requiments may have not been heard by the right people at the right
> time. Reiterating them now would be helpful.


I think reiterating the pros and cons wouldn't be a bad idea.  When
this was first discussed, there were fewer people involved, and many
of the specifics (such as what you might be losing by moving away
from a monolithic build) weren't mentioned.  Since then, I think some
people have a better idea of what this entails, although I think
there are still a lot of unknowns for many.

Would this be worthy of some discussion at the X Developer's meeting
in two weeks?  Although I wouldn't consider that meeting as a decision
making forum for this, since not everyone will be able to attend, but
there will be a broader audience than those on this list.  It would
give those from other projects who use the autotools to describe
the benefits to them.  In addition, there could be a discussion on the
basics of the tools that would be used in the modular tree,
and that might demystify it for some as well as further illuminate
the differences between the modular and monolithic trees.  Perhaps
we can find some easy ways to help bridge the two in a fashion
that doesn't require lots of duplicated efforts.  If some of the modular 
proponents were willing to assist with that type of effort (if it's
even feasible), maybe it would feel like an easier transition for some.
Plus, we can perhaps further identify if the current monolithic proponents
object to the transition itself, or just to the timing of it.  Although
not everyone will be in attendance at that meeting, it seems like a
logical time to at least discuss it.

Based on what I've followed in these discussions so far, I think both
sides have valid arguments.  Using tools that are common and
well-understood by a larger pool of open source developers is
good for the organization in the long term.  At the same time, 
I can understand that converting to a new build framework is 
just something that gets in the way of the real fun of pulling
in, evaluating, and experimenting with new features on their platform
of choice.  It would be nice if we could find a way to balance 
these short- and long-term needs accordingly.

-paul