RFC: Does anyone remember there's a release of our own to get out?
On Thu, 26 Jul 2012 19:51:58 -0400
Michael Gilbert <firstname.lastname@example.org> wrote:
> On Thu, Jul 26, 2012 at 6:58 PM, Russ Allbery wrote:
> >> True. Part of the problem is appropriate terminology. This is a case
> >> of what I would call an "undermaintained" package. Even though the
> >> maintainer is still around, and may be quite active elsewhere, this
> >> package has not gotten any attention in 2 years (even though multiple
> >> upstreams have been released in the meantime).
> > Putting aside this specific example, I don't think the criteria you're
> > using to evaluate whether a package is undermaintained is valid. It's not
> > always correct that maintainers should be blindly packaging every upstream
> > release, and if upstream releases are minor and not important to Debian,
> > it's perfectly reasonable to not prioritize that packaging among the
> > various other things that one is doing.
Disagree - and it's pointless to argue about this during a freeze when
we can do nothing about it.
> It is more complicated than just length of time without an
... when a new upstream release exists ....
... and a bug report asking for the new release has been open for at
least half the length of time specified ...
... and the maintainer hasn't commented on the bug report about why the
new upstream release might be unsuitable for Debian ....
... and Debian is not or will not soon be in a release freeze ....
>, but that is a very straightforward quantity to look up and
> keep track of.
New upstream releases come with *risks* and need *testing*. Panicking
about new upstream releases shortly before or during a release freeze
is a complete waste of everyone's time!
There are very good reasons why the release team do not like to see new
upstream releases being uploaded around the time of or during a release
freeze. All this is quite apart from the fact that we have a *lot* of
packages which are native or where the DD *is* the upstream. We also
have a lot of packages where the previous upstream is all but inactive
and it is only the maintainer pushing patches upstream which even gets
a new release considered.
Please can we put this argument off until after Wheezy and concentrate
on things which will actually help get this release out? Please? Pretty
please with bells on?
(If encouragement doesn't work, maybe if everyone interested in the
release puts everyone who is not interested in the release in their kill
files / banned them from the lists & BTS, then we'd get some work done.)
The longer we take to release Wheezy, the more out of date Wheezy will
be when it is released. The more untested software gets rushed into
Wheezy, the more RC bugs will occur and the longer it will take to
*THIS IS SELF-DEFEATING!*
We know this, we've been here before - WHY must we keep on repeating
If everyone commenting on this RFC actually fixed an RC bug instead,
we'd actually be able to DO something about this problem because we'd
be able to make the release and then upload stuff for testing!
If you're not interested in helping Debian release Wheezy, fine, please
do the rest of us a favour and put your favourite pet peeve onto a Wiki
page and let's discuss it after the release. I don't mind if you
personally don't want to see the release get done but don't block /
distract those of us who do care. Some of us are relying on getting the
release done. If you're not helping the release, please don't become
part of the problem. Let the rest of us get some work done without
pointless distractions about things which are not going to help the
> If one sees a package that has not been uploaded in 2 years (or 6
> months or however long), I think we should make it so that they can
> feel free to liberal NMU it with a 10-day delay. If the maintainer
> was really planning to hold the package back for some reason, they can
> always cancel that (preferably with some kind of note as to why).
No. The maintainer block on a new upstream release should be via a bug
report, not having to respond to an unwanted NMU. IMHO NMU's are not a
wise choice for new upstream releases anyway, not least because the
person doing the NMU really cannot be expected to be as familiar with
the possible breakages as the maintainer - also because the "patch" is
During a release freeze, this whole argument is even more pointless
because there is *nothing* the release team are going to want to do
with new upstream releases whilst frozen.
I really am beginning to wonder if the privilege of being able to post
to this list should be conditional on the number of RC bug fixes made
by that person since the freeze started.
Come on people, we have a release to do. There are enough people to fix
all the RC bugs, if we all tried to fix one / two each. Instead it's
left to a handful of stressed-out individuals.
Honestly, complaining about upstream releases being too tardy to be
included and thereby *delaying our own release* is a bit rich. The
reasons that new upstream releases are not going to be in Wheezy is the
same reason why the upstream releases get delayed upstream - people
endlessly arguing about distractions instead of getting the release