Package maintenance ideas
Hi...
I'm back from vacation and ready for action again :) Sounds like things
were pretty feisty while I was gone :)
Anyway, on to business. I've been thinking heavily about our patches and
how they relate to the other platforms, etc....namely, how could our
platform-specific stuff be isolated so as not to bother other ports. I've
also been thinking about how package maintenance can be handled in a
multi-platform distribution like Debian 2.0 is to be. I'll address each
of these separately...
First off, our patches for Alpha-specific and/or glibc-specific stuff.
My patches lately have been made in such a way that all glibc-specific
stuff is #ifdef'ed in such a way that if __GLIBC__ is defined (as it is in
the header files), it will use the glibc-specific code, otherwise, it uses
the upstream code. This isolates things pretty well and allows for
great cross-platform compatibility. In the few instances where
Alpha-specific code is required, however, more complicated steps need to
be taken. I've tried using the __ALPHA__ define as an #ifdef condition,
but found out that it's also defined for Digital UNIX, which can yield
some unwanted results sometimes (that's why "man" was kinda broken for
awhile). I have a few ways of doing it now, but they're not pretty. If
anyone has any ideas on how to cleanly do this, let's talk about them now.
I'm still not totally up-to-speed on some of the nuances of glibc etc., so
my solutions have been kinda strange at times.
Secondly, it's becoming obvious to me that autodetection of architectures
may be beneficial in debian/rules files if a configure script isn't being
executed during the build process. Alot of fixes that I have done involve
commenting out "-m486" switches which, although we need to do them, are
not optimal for cross-platform optimisation compatibility. Although the
Alphas don't have an optimisation switch for the specific processors yet,
my guess is that we will eventually and it would be much better to allow
such switches to be enabled by the rules scripts on build rather than
hard-coded within them. Again, any ideas on how this could be
accomplished would be great....
Lastly, the huge issue of package maintenance once Debian 2.0 gets
released. The current system is fine for a single-architecture
distribution, but once we introduce other platforms, it gets VERY furry.
Here's a typical problem that I can already see happening:
Mr. Smith maintains the foo package on the x86 platform and is the
average maintainer with only one computer immediately available to him (a
Pentium). He is on the mailing list for foo and updates his package in a
timely fashion. If any problems come up security-wise or operationally,
he is knowledgable in programming to fix the problems.
Now, Mr. Jones asks Mr. Smith if foo is available on his Alpha. Of
course, since Mr. Smith doesn't have an Alpha, he says no, not yet, but
asks Mr. Jones to build it for him and clues him in on what little Mr.
Jones needs to know in order to build it (again, a common scenario). Mr.
Jones successfully builds an Alpha package for foo and also submits a few
glibc and Alpha-related patches to Mr. Smith. Ok, so far so good. Here's
where it gets ugly.
Mr. Zed submits a bug report via the bug tracking system. The e-mail
notification goes to Mr. Smith, who then fixes the bug and releases a new
x86 package. Because Mr. Smith maintains 20 packages, he forgets all
about Mr. Jones' work on the Alpha and, thus, the Alpha version falls
behind in features and/or bug-fixes. Wait, it gets worse....
Let's say Mr. Jones realises about a month later that Mr. Smith updated
foo. He then ftp's the source again, but realises that Mr. Smith forgot
to incorporate his patches into the source code. Not only that, but the
patches that Mr. Smith did to fix the bug are glibc and Alpha
"incompatible" and need further work. Thus is born the "rats nest". It
gets to be a horrible cycle of work duplication at that point since two
people have to patch the same package twice and fix each other's patches.
But wait, there's more...
Everything works out regarding foo for awhile. Then, another bug report
is filed, but this time, even the upstream author doesn't know what to do
or how to fix it. He asks for ideas from Mr. Smith. Mr. Smith is
clueless too, since his programming knowledge is kinda limited. Mr. Jones
has been in computers since the dawn of time and writes programmes in
languages that haven't even been invented yet (hehehe...a little humour
here). Since Mr. Smith forgets Mr. Jones did work on foo in the past, Mr.
Jones' vast programming knowledge and ideas are an untapped resource and
the bug takes two months to fix. Then, we start the cycle detailed in the
previous paragraph all over again.....
So, under the current maintainer system, it seems that there will be a
huge duplication of effort going on. Here's my ideas....
* Multiple maintainers per package:
Every package has an "official Debian" maintainer per platform that the
package is ported to. This would allow for everyone to know who is
involved with the package. A "master maintainer" may be beneficial too,
since it would allow for a coordinator for the revisions made to a
package. This master maintainer would just be responsible for
consolidating patches into a common, multi-platform-happy patch.
* Revision of the bug reporting system to notify all maintainers of said
package:
Would allow all maintainers involved to be notified simultaneously of
bug reports.
* Communication between all maintainers for a package:
This can be done via a web site or even just e-mail. It would
greatly facilitate development efforts and would allow for the
maintainers to pool their knowledge to solve problems if needed.
* Simultaneous release of a package across architectures if possible:
Would let the users of the packages know that they can find their
package on their platforms as soon as it's announced on the announce
list.
As you can see, alot of thought went into this. I would say that the last
point is a tough one for a newly Debianised package, but I'm sure it
wouldn't take long to pick up maintainers from other architectures after
awhile. After all, most of the work would've been done by the primary
maintainer and any patches needed for other architectures could be
incorporated through a collaborative effort between the maintainers. The
other great advantage for this kind of system is that the maintainers
would each have all of the other platforms available for testing how
"happy" their patches will work across them.
What do you all think of these ideas?? I wanted to vent this stuff here
and get my ideas more refined before I started the same discussion on
debian-devel soon.
Thanks :)
Chris
------------------------------------------------------------------
Christopher C. Chimelis chris@classnet.med.miami.edu
Systems Supervisor
Division of Biomedical Communications
University of Miami School of Medicine
--> finger chris@classnet.med.miami.edu for PGP public key <--
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: