Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sun, Mar 20, 2005 at 12:13:13PM -0500, David Nusinow wrote:
> On Sun, Mar 20, 2005 at 10:05:15AM +0100, Sven Luther wrote:
> > On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote:
> > > On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote:
> > > > [1] The installer might be a point, but since all sarge architectures
> > > > will have a working installer and I hope there's not another
> > > > installer rewrite planned for etch this shouldn't be a big issue.
> > >
> > > This is still an issue. Joey Hess's mails have indicated very clearly that it's
> > > difficult to get an installer release out even when all arches are already
> > > supported.
> >
> > This is a non-issue. The main problem was the kernel situation, which will be
> > streamlined for etch into a single package, and maybe build issues, which
> > could be solved by a separate build queue or priority for d-i issues.
>
> You know, you keep saying this and I have a really hard time
> believing it, although I don't follow the kernel list so please
> enlighten me if I'm wrong.
Ok.
> If you have a single source package for 12 different architectures
> that's great, because when you have a security fix you can take
> care of that more easily. That's awesome.
Indeed. And better yet, you build the .udebs from the same package, so you
don't need to build the kernel and then build the .udebs.
> But then you'll be trading off for the same problems that every
> single other packge faces: namely that if a kernel on a single arch
> has an RC bug then it affects the kernels on every arch. This strikes
> me as being very problematic, and the only way I see around it is
> to downgrade actual RC bugs, which isn't really a solution at all.
Then we rebuild. This has some implications for slower arches, and this is
post-sarge issue anyway, so there is time for it, but the only solution for
this is to do partial rebuilds, and have a testing override for kernels on
slower arches.
Still, my claim is that delays like the ones joeyh complained about would
mostly dissapear. A bit of context about them :
1) a security fix causes an abi change.
2) a new kernel-source gets uploaded.
3) all arches need to individually upload kernel-images.
4) since there was an abi change, the package name gets modified, and thus
has to wait in NEW for NEW processing.
5) .udeb packages have to be built (usually by the debian-boot team), and
uploaded. (don't know if this implicates a second NEW processing).
6) the .udebs and .debs have to move into testing simultaneously to avoid
GPL violation, and general messy dependency and rebuild issues.
7) the debian-installer daily images need to be built out of SVN using the
above .udebs and tested.
8) the debian-installer package is upgraded in sarge, and uploaded.
9) each individual autobuilders need to process this package, which may or
may not be fast dependending on the actual auto-builder situation.
Doing this for all arches, with unsynchronized (and maybe off for a couple of
days) per-arch kernel/debian-boot maintainer causes no end of trouble,
especially with the additional delay the NEW processing imposes, is what
causes upto two month upgrade times which joeyh speaks about.
having a common kernel package will greatly simplify the parts of this process
which involve the kernel-team, and let you just do the security fix, build and
upload (either auto-built or hand-built), and then pass the baby to the
debian-boot people to handle as usual.
Hope this clarifies things a bit.
Reply to: