Debian 2.0 compilation effort
Jim Pick <firstname.lastname@example.org> writes:
> [1 <text/plain; US-ASCII (7bit)>]
> > FWIW, RedHat went the other way, their first libc6 beta was missing
> > anything that they didn't have compiled for libc5 yet. We really
> > should have done the same thing and not allow packages in until they
> > were converted. That would have put pressure on people to do the
> > conversion.
> I think we've done a good job - we just haven't finished it off.
Yes, we're doing a good job. (Although it was a little slow at first
getting key libraries moved over.) One interesting note is that, for
a while, we were ahead of them with the Sparc glibc stuff.
> Red Hat has an advantage in that their distribution is actually quite
> small - they don't have to work in all those "contrib" packages into
> their release.
> But we were in good shape to start pushing for a release back in August,
> ie. we've been pretty relaxed about the whole thing, whereas Red Hat has
> to get a product out the door in order to make money.
It would be nice to get a polished glibc release out the door, then
work on a 2.1 that adds fully integrated PAM support, diety, and
various other goodies.
Right now it is quite a leap for a user to go from bo to using one or
two packages from hamm.
> > One big issue is boot floppies. Another is FTP install, which hasn't
> > worked right for years.
> We should be able to fix that - I'm not sure what the problems are though.
Packages not being installed in the right order. I don't know the
details, Ian or someone can correct me, but it seems to be related to
predepends. I believe predepends require that another package either
be installed or installed and configured (can't remember) and the ftp
"method" isn't taking care of this.
> > We could have our testers start testing upgrades from bo right now,
> > I'm sure there are still a few issues to work out.
> I think we should build a master list of package testers. 1500+ packages
> times 5 testers per package is a pretty huge list. That means each
> developer would have to act as a tester for 40 packages. All they have to
> do is submit a "Pass" report, or file additional bugs. Maybe that is
> way too much work? Maybe we could cut it down a bit by first withdrawing
> packages that shouldn't be released?
IMHO, a good first step would be to organize a massive non-maintainer
compilation effort RSN. This will give us a better picture of what we
need to withdraw and how much more effort is needed.
It would be nice if we had an interactive web site with a list of the
current state of all of the libc5 packages. (e.g. who is working on
it, whether they are done, etc.) Could a web person put something
like this together quickly (my perl-cgi is to rusty)?
The idea would be that a maintainer could see who is doing what, claim
a package, or mark a package as "done" (ie. uploaded). Maybe a space
for a one line comment describing any problem with recompiling the
package. (old source format, etc)
(It would have faster turnaround time than using email to negotiate
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .