On Thu, 26 Jul 2012 19:51:58 -0400 Michael Gilbert <mgilb...@debian.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. > > Agreed. 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 > upload ... 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 release. *THIS IS SELF-DEFEATING!* We know this, we've been here before - WHY must we keep on repeating this? 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 release! > 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 usually meaningless. 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 DONE. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpVXDfb4oBDb.pgp
Description: PGP signature
