Debian 2.0 compilation effort
Jim Pick <jim@jimpick.com> 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
everything.)
Steve
dunham@cps.msu.edu
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: