Modularization development notes [was Re: RFA sent to the ArchWG]

[Kevin E Martin]

On Thu, Apr 14, 2005 at 02:42:41PM -0700, Jeremy C. Reed wrote:
> On Thu, 14 Apr 2005, Kevin E Martin wrote:
> 
> > Should we remove Xpm from the lib module as well and just include it
> > from the upstream source as a tarball?  Also, who is the upstream
> > maintainer?  It seems we've applied quite a few fixes but I wonder how
> > many of them have been pushed back upstream.
> 
> http://www.inria.fr/koala/lehors/xpm.html was the main Xpm webpage. But no
> source code updates since March 19, 1998. Over nine fixes since then.
> 
> I believe most Unix flavors and Linux distributions provide Xpm from their
> XFree86 or Xorg since it is better maintained.

Okay, I think we should integrate it.  I will remove it from the
external tarball section.

> We already have libXpm modularized (/cvs/xlibs/Xpm). It appears to have
> been last updated (by Daniel) on January 29, 2005 to "Import security
> fixes from X.Org HEAD."

Yes, exactly, and I want to be able to use as much of this work as
possible.

This is what I was trying to explain in the "Autotooling the modules"
section of my devel notes.  The idea is that we will use as much of the
autotooling from xlibs, xapps, xserver, and Debrix as possible.  I hope
that we can use it all, which will get us close to where we want to be,
but we should examine what has been done and ask those involved if they
have figured out better ways to autotool the code since they did the
work or if they have learned lessons that we should make sure not to
repeat.  Basically, I don't want to recreate the wheel nor do I want to
repeat the mistakes of the past.

I think it's important to have those involved in the previous efforts
explain the what they did, what worked/didn't work, how they approached
the problem, etc. so that the rest of us who weren't involved can learn
and will be able to participate in the current autotooling effort from
the beginning.  Otherwise, I fear that the rest of us will have to sit
on the sidelines while others do most of the work.  They will also end
up being the sole support of the new build system until the rest of us
catch up.  That puts a tremendous burden on them and increases the
knowledge gap.  The rest of us will catch up, but I feel it would be
better for that to happen up front instead of during development.

Also, we've committed to write a transition guide and the explanation of
how to autotool components is part of it.  Discussing it here in e-mail
to get more people involved, build understanding and consensus around
the methods used will serve as a foundation for that document.  I don't
think this needs to be anything too complex or to spell things out in
gory detail.  All I'm suggesting is that those involved explain the
basic techniques, conventions and options used for each module.  This
has the added benefit that it will help us to have a consistent build
system across the modules.

BTW, I encourage everyone to look through the code from the previous
autotooling efforts as that will also help those not directly involved
catch up.

Kevin