Re: beta 2 and beyond
On Thu, Jan 15, 2004 at 07:35:26PM +0100, Gaudenz Steinlin wrote:
> I request you to make an exception for discover as the next upload
> should have no impact on d-i and fixes quite important bugs in the deb.
> We might delay the next discover-data upload some day as this is more or
> less cosmetic and the really important fixes are in the archive.
I'd also like to see this. The module sorting bugfix is fairly
important, and if it turns out that it causes problems we can simply
back out that change before beta3/release. As for discover-data, I don't
see the point in not having those changes in, since they're very minor
and do fix actual bugs found by our testers.
> > - discover 2
> > I guess all the hard work has been done. IIRC the plan is to
> > upload it with a different name, so we can test installs using
> > it before swtiching overything away from discover 1. If this
> > does not involve renaming the existing discover udeb, it will
> > meet requirement I., and can be uploaded to unstable soon.
> This is already in the archive. But I jus discovered it did not build on
> the autobuilders due to a problem with the build depends:
> discover2 depends on kernel-headers-2.4.20-386 | kernel-headers which
> yields "E: Couldn't find package kernel-headers-2.4.20-386". How can I
> best solve this? Should I include the relevant kernel headers in the
> package or build-depend on a kernel-headers package for every arch?
> If I can't build-depend on a virtual package this is going to cause
> headaches as these headers change their package name with every new
> kernel released.
Are we really planning to switch over to discover2 for the release!?!
Switching a mature and well tested package for a brand new one this
close to release would be bad, and I hope I'm not the only one who
thinks this.
> > - 2.6 kernel
> > For some arches at least, possibly not as the default but
> > available as an alternate boot on the CDs. Blocked by discover 2.
> How is this connected to discover2?
> Someone simply has to come up with a discover-data list for 2.6. I think
> we should not put to much energy in 2.6 support as I hope most/all
> hardware will be supported by 2.4 for some time. So changing to a 2.6
> kernel can be done after the installation.
And for discover1, there is a patch that apparently works to allow
discover1 to work with 2.6. This is my only reservation about releasing
discover1 to sarge, since people will undoubtedly be using 2.6 with
sarge, and I want to make sure the discover that we release supports
them. If we're just going to go with discover2 instead, then I'll give
up that idea though.
> > - switch to subversion
> > It would be good to reorganise the tree, and some things are
> > waiting on that being done. Since this has the potential to
> > disrupt everything else during the transition, we'll have to be
> > very cautious.
> This would be a good idea.
I'd like to move the discover alioth project in to svn as well.
- David Nusinow
Reply to: