Re: bits from the release team
On Wed, Jan 04, 2006 at 01:11:00PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > For the installer, sure, but the generation of the d-i kernel .udebs is only
> > marginally of their relevance, and furthermore they don't want the
> > responsability associated with it, and as proof i can show you that joeyh
> > upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the
> > other architectures, defaulting it upto the porters, which are the exact same
> > guys doing the kernel packages. So joeyh and fjp can't have it both way.
>
> Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access
> to every other architecture out there, and with some of the
There is absolutely no need for any architecture access to simply repackage
the modules into an .udeb. Absolutely no need.
> architectures that I do have access to suffering from unaddressed kernel
> bugs (ie #332962) that make my hardware for them useless for testing new
> d-i releases, as well as being limited to modem speeds, makes it
> difficult to maintain anything more.
So, what do you think d-i is so special that it deserve special attention, and
should not fall in the common case of debian kernel bugs ? Maybe you will in
the future start building your own kernels too ?
It is just damn repackaging, nobody asks you to test anything at all.
> If you take a closer look at the commits in question, my changes were
> limited to kernel-wedge, which means the maintainers for other arches
> benefit from them. Probably the packages for other architectures can be
> updated with just a rebuild and simple testing, although it can be very
this has not been the case in the past, and you should simply have rebuilt and
uploaded them or something.
> hard to tell, since what hardware is common on which architectures, and
> thus which udebs it should go into, is not always easy to determine if
Indeed, which is why it is not needed to duplicate that process twice, once
when the kernel port maintainer choses which config option to include and
which not, and twice when you chose to include those modules in the .udebs or
not.
> you're not intamately familiar with the architecture. Which is a good
> reason to have maintainers who are, instead of me.
None, except for modules concerning the powerpc64 hypervisor and virtual scsi
stuff, of the upgrades that i did for powerpc since the sarge release needed
that kind of intimate knowledge. And all the changes i did, where mirrored on
x86 or something, and i lost maybe 2 hours or so each time time which i could
have spent doing useful work.
> Saying that this means I lack responsibility and am only interested in
> taking the easy way out is, again, insulting. <plonk>
No, but you cannot deny that both you and Franz have been ranting against the
porters not taking their duty seriously in the past, and this is one area
where you could make their time more worthwhile, but chose not to.
Friendly,
Sven Luther
Reply to: