Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 03:11:02PM -0800, Steve Langasek wrote:
> On Tue, Mar 08, 2005 at 04:54:34PM +0100, Sven Luther wrote:
> > On Tue, Mar 08, 2005 at 06:12:03AM -0800, Anthony Towns wrote:
> > > Sven Luther wrote:
> > > >>It's hard to take this sort of discussion as anything but an attack on
> > > >>ftpmaster, since there are plenty of teams in Debian that're even less
> > > >>transparent and effective than us. But given how these sorts of
> > > >But they are less a hindrance to the daily work of maintainers, and can
> > > >thus
> > > >more easily be avoided/worked around/whatever.
>
> > > If you think ftpmaster is a hindrance to your daily work, it's trivial
> > > to avoid it -- upload to your own site instead, or to people.debian.org.
>
> > And hack debian-installer to by default get powerpc kernels out of a personal
> > archive ? I almost did that when NEW processing disintegrated two years ago
> > during the compromise, but i don't think this is compatible with the
> > release-management work surrounding the d-i.
>
> > As a result of 1 and a half month waiting in processing the
> > kernel-latest-powerpc metapackage for example, we will not have support for it
> > in d-i rc3, for example, and thus future upgrades of kernels installed with it
> > will be problematic.
>
> Here is the relevant section of the .changes file for the package in
> question:
>
> Date: Wed, 12 Jan 2005 17:40:59 +0100
> Source: kernel-latest-powerpc
> [...]
> Changes:
> kernel-latest-powerpc (101) unstable; urgency=low
> .
> * Typo in debian/control created kernel-headers-2.[46]-powerpc instead of
> kernel-headers-2.[46]. Fixing this means another wait in the NEW queue :(
>
>
> This merely underscores the contrast between Anthony's recommendation --
> being resourceful enough to find a way to achieve the things you care about
> when no one is interested in helping you -- and what you've done in this
> case -- whine that a name change on *headers* metapackages that are used
> nowhere in the installer prevented you from improving the quality of that
> installer.
It was a damn typo i oversighted in the 100 version. And the mention that
itmeans a wait in the NEW queue was in no way a whining, but an informative
mention to whoever would look in the svn archive for the package wondering why
this problem (which marked kernel-latest-powerpc uninstallable for almost two
month) was indeed solved and waiting in NEW.
and notice that these packages are not used on powerpc because Kamion didn't
modify base-installer to use them, while they are used (unless i am mistaken)
in the x86 case, and in general are meant to be used, which makes changing
kernel possible without rebuilding the base-installer .udeb, and thus allows
more flexibility.
Notice also that the metapackages in question where ones transfered from
wheree Jens had put them, namely in the kernel-images themselves, which caused
lot of breakage as you well know once we had more than one kernel version in
the archive.
I mentioned this fact to Kamion, and he told me he would not bother
ftp-masters about this, since the packages name where to generic for his, and
dismissing my argument that these where the names of the kernel-header
metapackages previously used.
I also wrote an email to ftp-masters explaining why it was important that this
package got processed to the d-i release schedule, and also mentioning 2.6.10
whihc was a potential release candidate, that email was helpfull and nice, but
i got nil reply to it.
And i think that this is the real problem here, any mention of the NEW queue
is seen by the ftp-masters and others involved like whining, and there is a
knee-jerk reaction to fully dismiss the issue as far as possible then, while
it may well be some half humorous attempt to get over the frustration of it or
just be informative.
> And with all that, the kernel-latest-powerpc package is still in an RC
> broken state, because you chose to make a last-minute reorganization of
> kernel-patch-powerpc-2.4.27 without updating kernel-latest-powerpc to match.
> You can hardly blame the ftpmasters for this state of affairs.
Nope, i uploaded the fix. it's in NEW again i think, let me check. Ah, no,
they where accepted on march 5, please check your sources before making such
aggressive claims.
And you can't really take the argument both way, in one saying that the
ftp-master are volunteers and work on things as their time allows, and on the
other side imply that the rest of the developers are just slaves to be held to
thight release schedules.
> > And we will soon upload 2.6.11 kernels, which will mean handling of N+1 NEW
> > packages, where N is the number of architectures supporting the 2.6 kernels.
> > This could easily enough be automated, and i don't think the NEW reporting to
> > the US agencies needs to go done to the level of renamed binary packages or
> > new versions of basically the same thing.
>
> Frankly, looking at the frequency and timing of some of your package name
> changes, I think having ftpmaster oversight here is a very, very good thing.
Please provide detailed data, using unproven caloumnious claims like the above
is not in order.
> None of this is on-topic for -vote, but I felt the outlandish claims that
> ftpmasters were causing delays for d-i RC3 should not be allowed to stand
not delays to d-i rc3 as see, but to a usefull feature of it.
Now, if you had decided to go with 2.6.10 kernels after all, the delay in
getting he 2.6.10 powerpc kernels processed would have been cause for a rc3
delay due to the lack of chance for testing they had gotten.
> unchallenged. If you really feel compelled to argue about this further,
> please take it to debian-devel, where explanations of why gratuitous package
> name changes are bad are on-topic. M-F-T set accordingly.
If so, please keep me in CC on any replies as i don't read the too-high-volume
debian-devel. Altough i will send this one one last time to debian-vote, since
there where some inexactitudes in your above claims.
Friendly,
Sven Luther
Reply to: