Modularization proposal approved

[Kevin E Martin]

On Sun, Apr 17, 2005 at 09:18:32AM +1000, Daniel Stone wrote:
> On Sat, Apr 16, 2005 at 01:27:34AM -0400, Kevin E Martin wrote:
> > On Sat, Apr 16, 2005 at 11:31:30AM +1000, Daniel Stone wrote:
> > > On Fri, Apr 15, 2005 at 09:12:16PM -0400, Shawn Starr wrote:
> > > > Who's coordinating things? It's Friday and I'm home, so I might as well be 
> > > > useful :)
> > > 
> > > No-one's really co-ordinating anything; just start hacking on whatever
> > > takes your fancy.
> > 
> > I'm not quite sure where that came from, since the topic of discussion
> > for the past several days has been exactly how to coordinate the work --
> > see the recent threads.
> 
> Sure, but no-one needs any permission to start work, and there's
> arguably no proper linear progression to follow.

You're correct in that no one needs permission here, and I'm all for
hacking out prototypes and then proposing them to the group here.  That
would be a great starting point.  And, in fact, we already have several
prototypes: xapps, xlibs, xserver and DebriX.

But, I think it's a little early to begin the implementation since we
haven't built any consensus around what conventions we want to follow so
that we can create a consistent build system.  We're setting precedent
here, and it pays to think through the problem at the beginning to make
sure that we're all on the same page (so work is not wasted), and then
to coordinate what needs to be done (so work is not duplicated).  I
think we're very close though.  Let me try to explain it in a different
way...

Normally, this would be a chicken and egg type problem where we would
need to make some prototypes for us to figure out what needs to be done
before settling on the conventions and standard options used in the
autotool build system; however, we're in much better shape here.  As I
mentioned above, we've already got several existing autotooled projects
from which we can draw as much experience (and the build system code) as
possible.  We just need to make sure that everyone here understands what
was done in those projects so that we can build consensus around those
solutions, which I think will be fairly easy to do once everyone
understands what was done.

Currently, we've got a group of people here who were involved in those
previous autotooled projects and they have a significant amount of
knowledge built up.  However, there is another group here that was not
involved who need to build that knowledge so that they can understand
what we're trying to build consensus around.  I'm sure it's probably
frustrating for those that already have this knowledge, but to get the
others to agree to the solutions proposed in the existing autotooled
projects, they need to understand what was done in those projects.  This
primarily comes from studying the build system (which everyone should be
doing), but it is a learning process and takes a little bit of time.

What would significantly speed up this process is for those involved to
explain what was done, what did and did not work, what should be changed
this time around, etc. so that the people not involved in the previous
projects don't have to study the code completely cold and the discussion
and writeups can serve as the basis for the transition guide.

I'm not sure how else to explain this.
Does that explanation make sense to everyone?

Thanks,
Kevin