proposal for changing the "Nonresponsive maintainer" policy
Please see https://pagure.io/fesco/issue/2149#comment-579981 for the full text of the latest proposal. The biggest change is that the reporter would have less work to do (fesco would take care of sending reminders from its ticket), and the reported would normally be assigned comaintainership rights soon after opening the fesco ticket, to speed the whole procedure up. Any comments here or in the fesco ticket are welcome. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: nonresponsive maintainer policy
On 08/02/2010 01:41 PM, Michael Schwendt wrote: On Mon, 02 Aug 2010 12:31:22 +0100, James wrote: Remember that some packages get very little activity because they need very little. And these are not a problem at all. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. [snipped the rest here] Uh, come on, ... that's not helpful. There are ideas how to detect absent maintainers early by collecting and *combining* information available in the Fedora intrastructure. Not by having a single old stable pkg trigger an AWOL alarm. [snip] Really? So imagine this scenario. Packager foo has two packages, bar and baz. bar is a package much like ed, which needs very little attention, and goes for a year without anything needing doing to it, no koji activity happens. This increases the hidden little AWOLness counter. foo then goes on holiday for a week, and forgets to mention this on his fp.o page. A bug is found in package baz. Bug reports are filed - users are impatient. It's noticed that foo has a very high AWOLness counter due to foo's other package. He is surprised to learn that he's been declared AWOL and had his packages removed when he returns from holiday. As I read the initial proposal, this is entirely plausible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On Tue, 03 Aug 2010 11:27:00 +0100, James wrote: On 08/02/2010 01:41 PM, Michael Schwendt wrote: On Mon, 02 Aug 2010 12:31:22 +0100, James wrote: Remember that some packages get very little activity because they need very little. And these are not a problem at all. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. [snipped the rest here] Uh, come on, ... that's not helpful. There are ideas how to detect absent maintainers early by collecting and *combining* information available in the Fedora intrastructure. Not by having a single old stable pkg trigger an AWOL alarm. [snip] Really? So imagine this scenario. Packager foo has two packages, bar and baz. bar is a package much like ed, which needs very little attention, and goes for a year without anything needing doing to it, no koji activity happens. I also own at least one such package. This increases the hidden little AWOLness counter. foo then goes on holiday for a week, and forgets to mention this on his fp.o page. A bug is found in package baz. Bug reports are filed - users are impatient. It's noticed that foo has a very high AWOLness counter due to foo's other package. He is surprised to learn that he's been declared AWOL and had his packages removed when he returns from holiday. As I read the initial proposal, this is entirely plausible. No. The packages won't be removed. That's not the goal. It could be, however, that another contributor becomes a co-maintainer and applies a fix while you are on vacation. And that's a good thing, provided that the fix is fine. You would return from vacation to learn that your precious users have not been interrupted for more than a few days by an unexpected bug. In case it's a show-stopper bug, it could be that a helpful provenpackager jumps in to apply a fix _even without_ any new AWOL-detection procedure (but provenpackagers are not supposed to take care of unmaintained packages). Apart from that, your scenario is overly negative. Sort of a worst-case assumption. It could be that there is a threshold of N bugs that would need to be reached before a script would even consider taking a closer look at some person. More typical are packages, where the packager has dozens of open tickets, which have not been touched at all in several weeks/months. They are in a poor state already before someone notices that the packager seems to be missing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On Tue, 03 Aug 2010 11:27:00 +0100 James Findley s...@gmx.com wrote: Really? So imagine this scenario. Packager foo has two packages, bar and baz. bar is a package much like ed, which needs very little attention, and goes for a year without anything needing doing to it, no koji activity happens. This increases the hidden little AWOLness counter. foo then goes on holiday for a week, and forgets to mention this on his fp.o page. A bug is found in package baz. Bug reports are filed - users are impatient. It's noticed that foo has a very high AWOLness counter due to foo's other package. - Maintainer is nominated as AWOL. - FESCo (or whatever humans are supposed to) look at this and decide that he's not really awol, he's just away from his computer. He is surprised to learn that he's been declared AWOL and had his packages removed when he returns from holiday. I think much more likely would be that if the bug/issue was security or critical, a provenpackager would step in and fix it. If he wasn't back in a few more weeks the packages would be orphaned and passed on to a new maintainer. As I read the initial proposal, this is entirely plausible. I don't think so. Any process needs to have a human check at the end. We shouldn't automate it fully as there will be false positives. Humans should look at the case and catch stuff like the above. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On 07/30/2010 10:31 PM, Kevin Fenzi wrote: On Fri, 30 Jul 2010 16:28:11 +0200 Sven Lankess...@lank.es wrote: On Fri, Jul 30, 2010 at 03:28:42PM +0200, Michael Schwendt wrote: I think we should add some policy to address those unmaintained packages, There is the non-responsive maintainer policy already. That policy isn't the easiest one to follow though. I understand that taking someones packages away should never be easy but maybe we could develop some metrics for the awolness of a maintainer and use that to possibly speed up the process. I would love a better policy. It's hard to balance tho... between someone who is just busy and someone who is really missing. ;( I think one thing that would help is perhaps to form a group that looks for these people (possibly using what you are talking about below), tries to contact them and if that fails marks them as missing. I know that seth worked on something similar based on commit frequency. What I could think of is: * Look at the FAS activity If a maintainer has multiple request for commit rights to his package which have not been answered in a long time that would increase his awolness counter. (This would mean that we need to encourage people to actually deny requests that they don't want to approve - currently it seems to be accepted that denying a request is rude and the more polite way to not approve a commit request is to just ignore it). I'm not sure just not acting on a request there is a sign of awol. They could just be waiting for the person to prove themselves, or some other reason. But if there is no pkgdb activity at all, I think thats an indicator perhaps. * Check if he actually has a current certificate to interface with koji Good idea. * Look at koji activity Yep. If a maintainer hasn't done any build in koji for three months or more that would increase his awolness counter. yeah, or any git commits, etc. Remember that some packages get very little activity because they need very little. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. If a package is no longer under heavy development, and is in a stage where releases happen very rarely if ever, and bugfixes are similarly rare, then what do you expect people to do? Reformat the spec file every three months so as to avoid the AWOL counter? Unless there are open bugs against a package with no activity from a maintainer, or it's way behind upstream (in which case there should probably be a bug open), the fact that nothing has happened in koji for three months isn't a problem. Lots of packages in Fedora are not bleeding edge GUI apps needing constant TLC. Please remember this when creating policies. -siXy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
2010/8/2 James Findley s...@gmx.com: On 07/30/2010 10:31 PM, Kevin Fenzi wrote: On Fri, 30 Jul 2010 16:28:11 +0200 Remember that some packages get very little activity because they need very little. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. If a package is no longer under heavy development, and is in a stage where releases happen very rarely if ever, and bugfixes are similarly rare, then what do you expect people to do? Reformat the spec file every three months so as to avoid the AWOL counter? Unless there are open bugs against a package with no activity from a maintainer, or it's way behind upstream (in which case there should probably be a bug open), the fact that nothing has happened in koji for three months isn't a problem. Lots of packages in Fedora are not bleeding edge GUI apps needing constant TLC. Please remember this when creating policies. Obviously, if upstream don't have a new release and the package itself doesn't have any security issue, then we don't need update it. However, I think tracking upstream in rawhide is necessary even they are command only packages. That's why gcc/glibc/coreutils in fedora rawhide are the latest version. Also, some packages which under active development are not updated for several years not just several months. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
On Mon, 02 Aug 2010 12:31:22 +0100, James wrote: Remember that some packages get very little activity because they need very little. And these are not a problem at all. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. [snipped the rest here] Uh, come on, ... that's not helpful. There are ideas how to detect absent maintainers early by collecting and *combining* information available in the Fedora intrastructure. Not by having a single old stable pkg trigger an AWOL alarm. So far: A package can have dozens of unresponded tickets in bugzilla (with perhaps all of them not having been looked at), a new upstream release made a year ago, a maintainer who has dropped of Fedora and hasn't renewed certs for half a year, ... and nobody would notice. Provenpackagers would apply hot-fixes in Rawhide for FTBFS issues. Once somebody discovers that the package is an orphan, starting the non-responsive maintainer procedure wouldn't be much of a big deal. What's 3-4 weeks compared with N months? Though, repeatedly the packagers (sometimes new ones who would join Fedora for a single pkg), who would like to take over an orphan, have pointed out that they consider the procedure tedious and a pain (and I understand that failed attempts at contacting a person is no fun). Especially if a pkg has been in a poor state for N months anyway even in the stable dist releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nonresponsive maintainer policy (was: Re: Can anyone contact Balint Christian (rezso)?)
On Fri, Jul 30, 2010 at 03:28:42PM +0200, Michael Schwendt wrote: I think we should add some policy to address those unmaintained packages, There is the non-responsive maintainer policy already. That policy isn't the easiest one to follow though. I understand that taking someones packages away should never be easy but maybe we could develop some metrics for the awolness of a maintainer and use that to possibly speed up the process. I know that seth worked on something similar based on commit frequency. What I could think of is: * Look at the FAS activity If a maintainer has multiple request for commit rights to his package which have not been answered in a long time that would increase his awolness counter. (This would mean that we need to encourage people to actually deny requests that they don't want to approve - currently it seems to be accepted that denying a request is rude and the more polite way to not approve a commit request is to just ignore it). * Check if he actually has a current certificate to interface with koji * Look at koji activity If a maintainer hasn't done any build in koji for three months or more that would increase his awolness counter. The awolness-counter would only be looked at when someone thinks about starting the awol procedure and it could be used to speed up the process - maybe get an non-responsive Maintainer procedure done in one week instead of four or five. I know that there is the Fast Track procedure but that is for when it may be needed to reassign a package quickly. When I was bit by gdal being in FTBFS for too long (and with it merkaartor which I maintain) I commented on the bugs and waited a while. When that didn't do anything I email Christian and also started work on a fixed package which rsc then built for rawhide using his provenpackager powers. I could have stopped there (and I nearly had done that) without starting the policy procedure - just because the process requires the one interested in getting things fix to do five or six things each a week apart. And looking at the number of awaitaing review maintainers there have been a few people before me who wanted to help get things fixed ... It can't be repeated often enough: We need maintainers for each and every package in the collection. To have packages and bug reports assigned to an inactive person A with provenpackager B doing random upgrades from time to time is a broken system. B ought to become the maintainer instead. And C and D and E in the community also ought to consider joining the package's team of maintainers, too. I agree. But we also need to make it easier for people to do so - if you look at https://admin.fedoraproject.org/pkgdb/acls/name/gdal (which is one of rezsos packages), it has 6 users with Awaiting Review on commit rights. It's not that people don't want to help out but we're making it too hard for them to do so. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy (was: Re: Can anyone contact Balint Christian (rezso)?)
On Fri, 30 Jul 2010 16:28:11 +0200 Sven Lankes s...@lank.es wrote: On Fri, Jul 30, 2010 at 03:28:42PM +0200, Michael Schwendt wrote: I think we should add some policy to address those unmaintained packages, There is the non-responsive maintainer policy already. That policy isn't the easiest one to follow though. I understand that taking someones packages away should never be easy but maybe we could develop some metrics for the awolness of a maintainer and use that to possibly speed up the process. I would love a better policy. It's hard to balance tho... between someone who is just busy and someone who is really missing. ;( I think one thing that would help is perhaps to form a group that looks for these people (possibly using what you are talking about below), tries to contact them and if that fails marks them as missing. I know that seth worked on something similar based on commit frequency. What I could think of is: * Look at the FAS activity If a maintainer has multiple request for commit rights to his package which have not been answered in a long time that would increase his awolness counter. (This would mean that we need to encourage people to actually deny requests that they don't want to approve - currently it seems to be accepted that denying a request is rude and the more polite way to not approve a commit request is to just ignore it). I'm not sure just not acting on a request there is a sign of awol. They could just be waiting for the person to prove themselves, or some other reason. But if there is no pkgdb activity at all, I think thats an indicator perhaps. * Check if he actually has a current certificate to interface with koji Good idea. * Look at koji activity Yep. If a maintainer hasn't done any build in koji for three months or more that would increase his awolness counter. yeah, or any git commits, etc. The awolness-counter would only be looked at when someone thinks about starting the awol procedure and it could be used to speed up the process Should we wait until someone starts the process? Wouldn't it be better to look at all the people over a X value here and at least contact them. Are you alive and still willing to be a maintainer? If you don't have time perhaps hand off your packages? Thanks? - maybe get an non-responsive Maintainer procedure done in one week instead of four or five. Yeah, added with all the info above and other stuff we can gather. People do go away for weeks at a time and are just on vacation, etc. I know that there is the Fast Track procedure but that is for when it may be needed to reassign a package quickly. When I was bit by gdal being in FTBFS for too long (and with it merkaartor which I maintain) I commented on the bugs and waited a while. When that didn't do anything I email Christian and also started work on a fixed package which rsc then built for rawhide using his provenpackager powers. That is a downside to provenpackagers. Hey would you fix this thing for me ok. Then we don't know that anyone is maintaining it. I could have stopped there (and I nearly had done that) without starting the policy procedure - just because the process requires the one interested in getting things fix to do five or six things each a week apart. And looking at the number of awaitaing review maintainers there have been a few people before me who wanted to help get things fixed ... Yeah, but then we don't really have a maintainer answering bug reports, etc. It can't be repeated often enough: We need maintainers for each and every package in the collection. To have packages and bug reports assigned to an inactive person A with provenpackager B doing random upgrades from time to time is a broken system. B ought to become the maintainer instead. And C and D and E in the community also ought to consider joining the package's team of maintainers, too. I agree. But we also need to make it easier for people to do so - if you look at https://admin.fedoraproject.org/pkgdb/acls/name/gdal (which is one of rezsos packages), it has 6 users with Awaiting Review on commit rights. It's not that people don't want to help out but we're making it too hard for them to do so. Yep. I would love a more comprehensive policy being proposed to fesco. Write one up? ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
