Re: MIA maintainers and RC-buggy packages
> Did you document your attempts so people willing to help have a point > to start from? No, and all the blame for that goes to me. BTW the same holds for all of my other packages, I'm more than willing to accept help/co-maintainership. Thanks for the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
On Sun, Dec 04, 2016 at 01:14:42PM +0100, Christoph Biedl wrote: >... > To add a few criteria, I'd remove a package from sid only if it >... > * has been orphaned for a longer time, say: a year > So again users of that package had a grace period to ask for work on > that package. >... Two questions: 1. Whom and how should a user ask? 2. How would a user even notice that a package that is important for him has been orphaned? The majority of Debian users are running stable, and upgrade to a new stable every 2 years. Example for the packages we are talking about: ispell-lt (#704968) Orphaned for 3.5 years, no open bugs. This is a package with relatively low popcon that is not being adopted, both for an obvious reason (Lithuania is a small country). There are likely *users* for whom this package is important, but the number of *developers* who did a package upload in 2016[1] and speak Lithuanian might be zero. > Christoph cu Adrian [1] any package, as definition of "active developer" -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: MIA maintainers and RC-buggy packages
Michael Meskes wrote... > Sure, but then it would be nice if you'd tried finding out if nobody > cares. As usual the real world is neither white not black, but some > shade of gray. The problem with the package is that the new version > does not build on my system but I lack the time to debug, could be > minor but still. Did you document your attempts so people willing to help have a point to start from? > If anyone wants to help, the package is tora. At least the current serious bug #811663 was rather easy to handle. You should have got mail. Christoph signature.asc Description: Digital signature
Re: MIA maintainers and RC-buggy packages
Emilio Pozuelo Monfort wrote... > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. This seems very reasonable, go for it. Such an approach would also ease QA uploads for packages and should overall improve package quality. It is quite disturbing to see how many packages dropped out of stretch due to the three big migrations (gcc-6, openssl 1.1, debhelper), even if fixing it would take less that an hour. Also, in spite of all the work the people behind them did, including long grace periods. So we have a lot of de-facto orphaned packages and it's about time to make such a status official sooner. FWIW, I consider salvaging several packages that are debhelper compat level 4 or earlier. But I always wondered whether this wasn't a good time to go beyond the bare necessities and do all the good things in packaging that were introduced in the past ten years, like dh7 style debian/rules, 3.0 (quilt) source format, machine readable debian/copyright etc.etc. - although this is rather QA work than NMU. But assuming the package is technically unmaintained, why not do work that has to be done anyway and will help a future maintainer? > I think we should also have an auto-removals-from-sid[1] (...) > [1] With a *very* conservative criteria. We don't want to remove a package > from > the archive after 30 days because of 1 RC bug. Not so sure about this. There still might be folks around that find that particular package useful for their work. In an ideal world they'd let us know. In real life I've experienced they are not sure about the procedures and are always happy to meet a Debian guy so they can tell about their concerns. My usual answer "File a bug, it's just an e-mail, you won't get eaten for small mistakes in form" sometimes worked, often it was better I took care of that myself. So we (as in Debian) suffer from the usual problem of not getting enough feedback, having to guess. Therefore, in case of doubt, rather keep a package. Also resuming work on a existing though pretty broken package is a lower bar then doing the re-entry procedure. To add a few criteria, I'd remove a package from sid only if it * is plain broken This means the code, not the packaging. * (no longer) serves a reasonable purpose If a package is specific for a task or feature that is no longer supported (think set6x86 which was for CPUs that are now pretty old), there is no reason to keep it. * no longer exists in older supported distributions Since still users might not learn their package is no longer part of the now-stable until they upgrade. * has been orphaned for a longer time, say: a year So again users of that package had a grace period to ask for work on that package. Personally, I'd also appreciate notifying debian-devel about an upcoming removal from sid, somewhat similar to ITPs, so there's a last chance for any interested party to pick the package. And there's still the shortcut using RM: Christoph signature.asc Description: Digital signature
Re: MIA maintainers and RC-buggy packages
> > The question is absolutely valid, but maybe I should rephrase it to > > "Why > > are you contacting the uploader only and not the team as well?" > > Because it's the first step. Would have been nice to know. Anyway, I can see your point. > > > * Also: what should we do with packages that are marked as team- > > > maintained > > > but are really orphaned? > > > > Which is defined how? > > I can define that as "nobody actually cares about the package". Sure, but then it would be nice if you'd tried finding out if nobody cares. As usual the real world is neither white not black, but some shade of gray. The problem with the package is that the new version does not build on my system but I lack the time to debug, could be minor but still. I'd like to keep the package around, if it still has the same functionality. Upstreams docs are not absolutely clear about this and I cannot check without building it. If anyone wants to help, the package is tora. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 09:25:11AM +0100, Michael Meskes wrote: > > human maintainer". 1 was "why are you asking me, I am only an > > uploader, > > the package is team maintained" even though that person was the only > > actual uploader (since 2002 till 2012). I've sent the list of my > > pings to > > the MIA team. > > I don't like the way you are picturing this. Sorry, I must have misunderstood you. > The question is absolutely valid, but maybe I should rephrase it to "Why > are you contacting the uploader only and not the team as well?" Because it's the first step. > > * Also: what should we do with packages that are marked as team- > > maintained > > but are really orphaned? > Which is defined how? I can define that as "nobody actually cares about the package". -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 06:23:17PM +0500, Andrey Rahmatullin wrote: > > I think we should also have an auto-removals-from-sid[1] (the crowd > > applauded > > when I mentioned that in my Debconf talk), which would solve/help your high > > number of orphaned packages. > What real problems will this solve apart from having less bad packages in > the archive? is this question ment as a reference to "what have the Romans done for us"? Having many bad packages in the archive is a real problem. Removing some of these packages is part of the solution to that, another part is fixing some others. -- cheers, Holger signature.asc Description: Digital signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I think we should also have an auto-removals-from-sid[1] (the crowd applauded > when I mentioned that in my Debconf talk), which would solve/help your high > number of orphaned packages. What real problems will this solve apart from having less bad packages in the archive? -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 11:42:02AM +0100, Mattia Rizzolo wrote: > And: you're suggesting to do a QA upload without changing maintainer > field? That seems ridiculous to me: QA uploads are uploads where > maintainer is QA, right? You're suggesting to change the meaning to > "big NMU", basically? Let's just call them NMU. Yes, of course I've meant an upload without the usual restrictions of a NMU. -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. Yes, totally agree. That's what I was trying to say, sorry if I didn't convey it properly. But I'm very conservative in trying to avoing disputes and flames, and I'd like to come up with an algorithm good for everyone, that covers as many cases as possible. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote: > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. > > I think we should also have an auto-removals-from-sid[1] (the crowd applauded > when I mentioned that in my Debconf talk), which would solve/help your high > number of orphaned packages. > [1] With a *very* conservative criteria. We don't want to remove a package > from > the archive after 30 days because of 1 RC bug. every word fully seconded, those are two very nice ideas, I hope to applaud their implementations soon :) -- cheers, Holger signature.asc Description: Digital signature
Re: MIA maintainers and RC-buggy packages
On 03/12/16 11:42, Mattia Rizzolo wrote: > On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote: >> * So, the final question: how much time should pass since the last >> maintainer upload (since removal from testing, since the first still >> unfixed RC bug, how many NMUs should exist since the last maintainer >> upload) to be able to just do a QA upload (without changing the Maintainer >> field as it's prohibited on the https://wiki.debian.org/Teams/MIA page) >> instead of finely-crafting minimal diffs and fixing only things allowed by >> devref 5.11.1? > > We discussed several times internally in the MIA team during the year > how to just "declare" a maintainer gone based on the current state > (last upload, gpg key ok, number of RCs, number of NMUs, etc), but the > consensus has been that it's just plain hard/impossible to give an > appropriate answer good for all cases. We shall discuss this again at > DebConf instead. I would suggest to come up with some algorithm to determine if a package is effectively unmaintained, and implement it in an automatic way that gives maintainers prior notice and a chance to react, like we do with auto-removals. Then if nothing happens in a reasonable time frame, the package gets orphaned. I think we should also have an auto-removals-from-sid[1] (the crowd applauded when I mentioned that in my Debconf talk), which would solve/help your high number of orphaned packages. Cheers, Emilio [1] With a *very* conservative criteria. We don't want to remove a package from the archive after 30 days because of 1 RC bug.
Re: MIA maintainers and RC-buggy packages
On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote: > * So, the first question is: should I spend my time on getting these > packages back to testing so they would be a part of the next release? Or > should I spend my time on other RC bugs fixing which will help release > stretch faster? IMHO, ponder popcon, you're personal feeling on what the package is, the actual issue, and then see what's better. Though I believe that if they arrived at this point they are not worth much of your time, but of course that's entirely up to you! [reflowing] > 1 was "should > be orphaned, though we don't have a standard method to orphan team > packages". > 1 was "why are you asking me, I am only an uploader, > the package is team maintained" even though that person was the only > actual uploader (since 2002 till 2012). sigh. Yes, we don't have a standard method. But if the team *is* the uploader (as often is the case), then there is only so much you can do. Probably before orphaning you can email the team ML, but of course contacting the single uploader (that is the de-facto maintainer), before writing to a public ML that you are proposing to wrestle a package out of the uploader only seems nice? > 1 was "I will move to a team" and I answered "a package needs a > human maintainer". sigh². > I've sent the list of my pings to the MIA team. Thanks. You've already received a reply from us. > * So: is it a real problem that there are packages that should be marked > as orphaned but they aren't? Should we spend any effort on marking more > orphaned packages? If yes, how should we do that? There surely are a lot of packages that are de-facto orphaned around here. Thorsten Alteholz writes on his blog about adopting orphaned packages (http://blog.alteholz.eu/2016/11/my-debian-activities-in-october-2016/), and as he noticed the number of orphaned packages is steadily increasing. We're now at 1007 packages as of yesterday wnpp report https://lists.debian.org/debian-devel/2016/12/msg00023.html (I wonder if we have any graph?) Since the MIA team restarted their efforts earlier this year the number of orphaned packages has been increasing, I'm not sure if that's for the worse of the better, but it did... > * Also: what should we do with packages that are marked as team-maintained > but are really orphaned? I suggest: contact uploaders to check if they are fine, then contact team and seek ack, then file the bug (this is assuming they reply, if they don't, then it's harder). > When fixing the RC bugs I always looked through other bugs in the same > package and applied trivial patches to the packaging. I've added > debian/source/format where it was missing. In some cases I've completely > replaced the packaging with 4-line d/rules. In at least two cases I fixed > empty -dbgsym packages. I did such things too, and even received thanks, regardless of the fact that NMUs are not supposed to do any of that. > * So, the final question: how much time should pass since the last > maintainer upload (since removal from testing, since the first still > unfixed RC bug, how many NMUs should exist since the last maintainer > upload) to be able to just do a QA upload (without changing the Maintainer > field as it's prohibited on the https://wiki.debian.org/Teams/MIA page) > instead of finely-crafting minimal diffs and fixing only things allowed by > devref 5.11.1? We discussed several times internally in the MIA team during the year how to just "declare" a maintainer gone based on the current state (last upload, gpg key ok, number of RCs, number of NMUs, etc), but the consensus has been that it's just plain hard/impossible to give an appropriate answer good for all cases. We shall discuss this again at DebConf instead. And: you're suggesting to do a QA upload without changing maintainer field? That seems ridiculous to me: QA uploads are uploads where maintainer is QA, right? You're suggesting to change the meaning to "big NMU", basically? Let's just call them NMU. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
> human maintainer". 1 was "why are you asking me, I am only an > uploader, > the package is team maintained" even though that person was the only > actual uploader (since 2002 till 2012). I've sent the list of my > pings to > the MIA team. I don't like the way you are picturing this. The question is absolutely valid, but maybe I should rephrase it to "Why are you contacting the uploader only and not the team as well?" > * Also: what should we do with packages that are marked as team- > maintained > but are really orphaned? Which is defined how? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
Andrey Rahmatullin writes ("Re: MIA maintainers and RC-buggy packages"):
> On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > Frankly, I would have been tempted to let a lot of those packages slip
> > out of stretch. It depends what they were, of course.
>
> I was following an advice received on IRC: if a package has a popcon of
> even 20 then most likely there are 20 people who will benefit from the
> fix.
I think the advice you got on IRC was good. Thank you, and thanks for
(effectively) correcting me.
Keep up the good work!
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: MIA maintainers and RC-buggy packages
On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote: > > * So: is it a real problem that there are packages that should be marked > > as orphaned but they aren't? Should we spend any effort on marking more > > orphaned packages? If yes, how should we do that? > > No, I think this is a waste of time. It it easy to see (eg from the > BTS and tracker) that a package is effectively orphaned. Even if we don't apply the letter of our rules about NMUs and hijacking to effectively orphaned packages, there are wnpp-alert and how-can-i-help that directly use our official wnpp marks to show the packages in need of help. There is also a filter on the UDD bug list and maybe other places. There can be (or there are?) some metrics about the archive state. > Frankly, I would have been tempted to let a lot of those packages slip > out of stretch. It depends what they were, of course. I was following an advice received on IRC: if a package has a popcon of even 20 then most likely there are 20 people who will benefit from the fix. > In the absence of bugs that "ought to have been dealt with" (which > would include RC bugs and bugs containing good patches, but not > necessarily any other kind of bug) I don't think lack of uploads > necessarily proves very much. > > Likewise "only NMU uploads" doesn't necessarily prove very much. > Maybe the nominal maintainer is actively reviewing the NMUs even, but > sees no need to intervene. That sounds correct. -- WBR, wRAR signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
Andrey Rahmatullin writes ("MIA maintainers and RC-buggy packages"):
> * So: is it a real problem that there are packages that should be marked
> as orphaned but they aren't? Should we spend any effort on marking more
> orphaned packages? If yes, how should we do that?
No, I think this is a waste of time. It it easy to see (eg from the
BTS and tracker) that a package is effectively orphaned.
> * Also: what should we do with packages that are marked as team-maintained
> but are really orphaned?
The same thing we should do with any package.
> When fixing the RC bugs I always looked through other bugs in the same
> package and applied trivial patches to the packaging. I've added
> debian/source/format where it was missing. In some cases I've completely
> replaced the packaging with 4-line d/rules. In at least two cases I fixed
> empty -dbgsym packages.
Your diligence is commendable.
Frankly, I would have been tempted to let a lot of those packages slip
out of stretch. It depends what they were, of course.
> * So, the final question: how much time should pass since the last
> maintainer upload (since removal from testing, since the first still
> unfixed RC bug, how many NMUs should exist since the last maintainer
> upload) to be able to just do a QA upload (without changing the Maintainer
> field as it's prohibited on the https://wiki.debian.org/Teams/MIA page)
> instead of finely-crafting minimal diffs and fixing only things allowed by
> devref 5.11.1?
Any package that got autoremoved from testing without response from
the maintainer should be treated as orphaned. Likewise any package
with an RC bug with no action for months.
In the absence of bugs that "ought to have been dealt with" (which
would include RC bugs and bugs containing good patches, but not
necessarily any other kind of bug) I don't think lack of uploads
necessarily proves very much.
Likewise "only NMU uploads" doesn't necessarily prove very much.
Maybe the nominal maintainer is actively reviewing the NMUs even, but
sees no need to intervene.
If the package is not clearly orphaned I think the best approach is a
QA upload to DELAYED. How about adding the QA team to Uploaders while
you're at it ? :-)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
MIA maintainers and RC-buggy packages
Hello. During the last week or two I've spent some time looking through the packages with RC bugs, mostly those that are removed from testing, have popcon 100+ and don't have recent activity on the bug report. I skipped bugs like "depends on obsolete piece of software" or "crashes in some circumstances", most of the bugs were FTBFSes caused by obsolete packaging or incompatibilities of the old code with the current environment. Unsurprisingly, most of these packages didn't have a maintainer upload since e.g. 2012 and have the RC bug open for last 3+ months. Some of them have some team in the Maintainer header, some have people in Uploaders who never made an upload. Some of them had 3 NMUs in last 3 years. * So, the first question is: should I spend my time on getting these packages back to testing so they would be a part of the next release? Or should I spend my time on other RC bugs fixing which will help release stretch faster? Next, I contacted all maintainers or such packages, telling them that their package X had its last maintaner upload on X and has an RC bug #X since X, asking them to orphan the package if they are not interested in it anymore and to also orphan other their packages they are not interested in. I've sent about 30 emails in last 6 days. I've got 9 immediate answers. 3 were "should be orphaned". 2 were "I will try to fix this". 1 was "I will fix the package" but about a different package. 1 was "should be orphaned, though we don't have a standard method to orphan team packages". 1 was "I will move to a team" and I answered "a package needs a human maintainer". 1 was "why are you asking me, I am only an uploader, the package is team maintained" even though that person was the only actual uploader (since 2002 till 2012). I've sent the list of my pings to the MIA team. * So: is it a real problem that there are packages that should be marked as orphaned but they aren't? Should we spend any effort on marking more orphaned packages? If yes, how should we do that? * Also: what should we do with packages that are marked as team-maintained but are really orphaned? When fixing the RC bugs I always looked through other bugs in the same package and applied trivial patches to the packaging. I've added debian/source/format where it was missing. In some cases I've completely replaced the packaging with 4-line d/rules. In at least two cases I fixed empty -dbgsym packages. * So, the final question: how much time should pass since the last maintainer upload (since removal from testing, since the first still unfixed RC bug, how many NMUs should exist since the last maintainer upload) to be able to just do a QA upload (without changing the Maintainer field as it's prohibited on the https://wiki.debian.org/Teams/MIA page) instead of finely-crafting minimal diffs and fixing only things allowed by devref 5.11.1? -- WBR, wRAR signature.asc Description: PGP signature
