Re: NEW handling ...
On Sun, Mar 20, 2005 at 08:20:40PM +0100, David Schmitt wrote:
> On Sunday 20 March 2005 12:08, Sven Luther wrote:
> > On Fri, Mar 18, 2005 at 02:40:34PM +0100, David Schmitt wrote:
> > > On Friday 18 March 2005 13:26, Sven Luther wrote:
> > > > And yes, i volunteer to help out NEW handling, if that help is wanted.
> > >
> > > Vapourware. I believe that for most packages it is quite easy to see why
> > > they are not allowed into unstable. Compile this list+reasons so that
> > > everyone who is interested in these packages can quickly see where the
> > > problems are. If there is any interest in contents of NEW this list would
> > > be very handy to get a quick overview of the problems plaguing NEW
> > > packages.
> >
> > I can even tell you now all the easy ones: all libraries which are policy
> > mandated to change their source name in case of soname change. The
> > kernel-source and various kernel-patch/image/whatever package or other
> > packages which need to have the version number embedded in the package
> > name. Source package which gain or loose a couple of binary packages in a
> > reasonable and easy-to-autocheck way.
>
> The way you say that leads me to the conclusion that you are only guessing.
>
> Do you really want to know how many libraries in NEW currently are waiting for
> a binary with a new soname?
Ok, i take that back, i just learned that the library case is somewhat more
complicated, since sometime they change soname in binary packages but not in
library packages.
This most certainly doesn't apply to kernel-source packages though, where an
abi change security upload will need at least one NEW processing per arch, and
often only the first upload gets processed, and the arches who come later are
left to smolder in the NEW queue forever. Well, the new blood in the
ftp-master team will make this an issue of the past probably.
> One:
>
> liboil0.3 0.3.0-1
> source i386 unstable
> 2 months David Schleef #284486
>
> liboil 0.3.1-1
> source i386 unstable
> 2 days David Schleef
Ok, so what ?
> Let's take a look at kernel images stuck in NEW:
>
> $ egrep '^<td[^<]*</td>' new.html | cut -d '>' -f 2 | cut -d '<' -f 1 | grep
> kernel
> kernel-patch-2.4-blooper
> kernel-patch-2.4-pom
> kernel-latest-2.6-hppa
> kernel-patch-suspend2
> kernel-image-2.6.8-ia64
> kernel-image-2.6.10-sparc
And at least this sparc kernel should be processed ASAP, since it is the last
2.6.10 kernel we are waiting for. The ia64 kernel is probably also over-due,
since 2.6.8 is a release candidate, and as far as i know, the
kernel-latest-2.6-hppa is just the officialization of the dropping of the 2.4
hppa kernels.
The remaining are just random kernel patches, not part of the actual kernel
packages.
notice that the kernel-patch-suspend2 patch is part of the ubuntu hoary
kernel.
> Using some awk magic I get this table:
>
> kernel-patch-2.4-blooper 1.1
> source all unstable
> 11 months Matthew Grant
> kernel-patch-2.4-pom 20031219-1
> source all unstable
> 11 months Matthew Grant
>
> We already talked about those.
>
> kernel-latest-2.6-hppa 2.6.8-1
> source hppa unstable
> 1 month Kyle McMartin
See, over kill, kernel-latest are packages whose vocation is to be used by d-i
base-installer, which is now frozen, and thus cannot be used here. Which means
we are saddled with no hppa meta-packages for the livetime of sarge as stable
release. The same happened for powerpc.
> debian-kernel managed kernel-image tracker packages seem to be called
> kernel-image-$ver-$subarch (e.g. kernel-image-2.6-686). Debian should strive
> to unify this as much as possible. REJECT. No wait, REJECTing this out of
> hand would lead to a pissed maintainer filling FMs mailbox. FMs are not
> debian-mentor, just let it rot, perhaps someone can clue him in...
Rejecting those would lead in a pissed kernel maintainer team i would say.
> kernel-patch-suspend2 2.1.8.1-1
> 2.1.8-3
> source all experimental
> 1 week martin f. krafft #292479
>
> I have already grabbed that one from the repository on martins page since I am
> desperatly wanting to hibernate my laptop. Well obviously not desperatly
> enough because I haven't yet fixed the patch for 2.6.10-current which would
> be needed to get any semblance of ACPI working on this one.
>
> kernel-image-2.6.8-ia64 2.6.8-13
> source ia64 unstable
> 3 days Debian Kernel Team
> kernel-image-2.6.10-sparc 2.6.10-6
> source sparc unstable
> 3 days Debian Kernel Team
>
> That leaves two packages which are only three days old. There are
Sure, these should have been auto-accepted, and this 3 days delay is
unacceptable. I guess the ia64 kernel even contains security fixes, and is a
sarge release candidate, and the 2.6.10 is a sarge fall-back release
candidate.
> > > Having a website separating the hard cases from the easy ones is the
> > > first step needed to get a discussion about the rest going.
> >
> > no, first step is getting a guarantee that the above will be useful and
> > accepted, or at least considered by the ftp-masters, or it is just work
> > that will be thrown away, and i have better things to do than that.
>
> You still want to "force" others to do work for you. There can be no guarantee
> from a volunteer in the face of real life and real problems.
So, i have a choice of working on the debian kernels, where i have a control
on, and work on some other random stuff i have no guarantee it will ever be
useful. My time is limited, so i am going to invest it in something that will
be useful, not something which may well be wasted time.
> The only way you have to accelerate things is to do the work yourself. Since
> there are no statistics but only anecdotal evidence from some pissed
> maintainers you also won't be able to measure any progress you cause. In the
I will most certainly know when security updates on debian kernels are held in
NEW because this is not automated, thank you.
> worst case, you will be able to collect the needed hard statistics (and
> stories behind the packages) to convince the project that current FMs really
> are the lazy sods you and will put you in charge since you already
> demonstrated your ability to do the grunt work.
i hope this changed, but see aj denying there was any NEW problem and people
just like to whine and complain.
> > > And "discussion" in this case doesn't mean posting long rants from the
> > > uploaders on d-devel how unfairly the cabal has ignored his package since
> > > he uploaded it five years ago to NEW and never cared afterwards.
> >
> > I on various case posted to ftp-masters about some of my packages in NEW,
> > which where important to get processed for whatever reason. I never got a
> > single reply on any of those.
>
> Thanks for making my point: "discussion" doesn't include "prods" from the
> packages maintainer to ftpmaster@d.o why his package is oh so much more
> important and perfect than everything else. As Anthony also stated several
Nope, why a powerpc 2.6.10 kernel being accepted ASAP in the archive is
important to get it tested as much as possible, especially as the special
debian-release/debian-kernel meeting made it a potential release candidate at
the start of february. It eventually got accepted, but i didn't get a single
reply to that post. I worked hard to make sure the powerpc 2.6.10 kernel was
uploaded, even putting aside some other work (even RL work), in order to make
it happen, and for what ? For having it smolder in NEW ?
> times in the last few weeks this behaviour will only alienate those behind
> ftpmaster@d.o further.
Because they can't take critics, and feel that everyone complaining is out to
get them, instead of there being a real problem. I have been in this since
years, and that has ever been a problem with people in the ftp-master
position.
> > But let's hope that the new blood and organisation of the ftp-master's team
> > will help get this situation to manageable proportions, as new blood helped
> > in the NM case, and others too.
>
> Since I too am not willing to do the work (NEW is fast enough[tm] for me) we
> have to wait for others to step up.
Yep, so let's hope this is will not be a problem in the future, but you
obviously are not under pressure from the release/d-i schedule and thus able
to wait weeks for some package to be processed. And notice i didn't bother the
ftp-masters for some other nice packages we have in NEW and that i am partly
responsible for, but only those that are important in my eyes of maintainer,
and member of both the kernel and d-i team.
I think i would have warranted at least a reply on this case, don't you think ?
Friendly,
Sven Luther
Reply to: