Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 07:10:06PM -0400, Michael Gilbert wrote: On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote: On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote: Maybe an example will help get us on the same page. Russ seems to have the impression that my proposal is somehow a license to push unwanted changes at a maintainer. That is not true. Let's consider mlocate as a hypothetical: - The contributor wants a new upstream for better hurd support - He prepares an nmu of that new upstream (making sure to not modify the maintainer's build setup and packaging style) - He convinces a DD that this is worthwhile to sponsor, and that DD decides that he is willing to take the social risk involved if something goes wrong - The DD uploads the package to DELAYED/whatever we agree is long enough and sends an nmudiff to the mlocate bts - The maintainer gets the mail, cancels the upload, and says to the contributor for me hurd support is not enough to take the risk of a new upstream upload - In this case, the contributor would probably say ok that's fine, and not push it further - But if he really thought it was that important, he would take it to the Tech Committee, and in this case, the committee would most likely side with the maintainer's opinion In this scenario the contributor should have talked to the maintainer before requesting a sponsor. This would be something that his potential DD sponsors would have taken into consideration before agree to a sponsorship. Well OK, then the contributor should have talked to the maintainer before requesting a sponsor, and the sponsor should have verified that before uploading. So, yes, I've taken a bit of liberty in terms of assuming that a DD could be convinced that mlocate was in a state where this needs to happen when clearly its not. Since this is a hypothetical, I'm free to set constraints, so please assume mlocate were in a worse state than it really is above. I commented on the the described scenario, not on mlocate. But also for mlocate, I don't see any bug NMU intent in the bts, and Svante Signell has confirmed that bug 669368 was not an NMU intent. http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mlocate I'm not sure how all this would fit in the debate on Lucas' proposal about orphaning. I guess that mlocate is not the perfect example to evaluate Lucas' proposal with. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102082426.ga...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 01:58:28PM -0400, Michael Gilbert wrote: On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote: wine: http://bugs.debian.org/585409 (new upstream pushed via nmu) This is a good example where talking helped to gather all views on all aspects from all involved people. My impression is that finally the maintainer allowed new co-maintainers doing things differently. That does not really match Lucas' proposal which is about marking packages as orphaned so that they can be taken over by a new maintainer. It matches my proposal where interested contributors apply nmus as needed to improve the situation, then eventually become uploaders. I didn't say that the series of NMUs should be used as a model for a new procedure in dev-ref. I said that my impression is that finally the maintainer allowed new co-maintainers doing things differently. I understand that you meant to bring attention back to your proposal, so I looked it up here: http://lists.debian.org/debian-devel/2012/10/msg00524.html I already briefly commented on it here: http://lists.debian.org/debian-devel/2012/10/msg00562.html Other than that, I cannot support your proposal, because I really think that when a maintainer is not maintaining a package anymore that new contributors should get full package (co-)maintainership from the start, with consent from the (previous) maintainer or from the TC or after orphaning. Lucas' proposal currently only addresses how the package could be orphaned. An NMU is meant as an occasional help, not as a step in taking over maintenance. I agree however that a series of NMUs is often one of the signs that the maintainer is not maintaining the package anymore. python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu) This does not seem to be an example of the maintainer refuses to package any newer upstream. This seems to be just an NMU, not related to Lucas' proposal. As we were getting close to the freeze, python2.6 was in a poor situation where it was going to ship with 2.6.7 in wheezy, and thus lack a whole bunch of security updates. Julien Cristau made the decision that this would be unacceptable, and prepared a new upstream nmu resolving the inactivity. This is certainly a case of a maintainer acting in an unproductive manner. The previous 2.6.7 upload was made almost an entire year prior to that. I don't see a maintainer acting in an unproductive manner but rather a package that got temporarily less attention so occasional help from others via NMU was helpful. Now that I look at this example again I see Julien Cristau's upload as a one-time co-maintenance contribution with an NMU version. According to the changelog the newer upstream release was already prepared by the maintainer. http://packages.qa.debian.org/p/python2.6/news/20120624T103440Z.html So again, this does not seem to be an example of the maintainer refuses to package any newer upstream. This seems to be just an NMU, not related to Lucas' proposal about orphaning packages. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102095055.gb...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, 2012-11-01 at 10:51 +0100, Tollef Fog Heen wrote: ]] Michael Gilbert mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) many others I'm sure The suggested NMU that does random changes like changing the packaging to 3.0 (quilt) and adding an uploader? Is that even a serious suggestion? The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. For the record, this mail will also be Cc-ed to bug #669368 since the commented-on mail was also delivered there. I did not suggest an NMU, see the explanation in: https://lists.debian.org/debian-devel/2012/11/msg4.html Some stuff repeated here, for clarity: Well the submitted files was not an NMU, I would need a sponsor for that. It was a wish that the maintainer would complete the packaging, but that did not happen. The changelog entry was for installation at debian-ports. If the maintainer had adopted the changes, the changelog would have been written accordingly by him, of course. The package is built and installed at debian-ports for GNU/Hurd where a sponsor was available. FYI, this package is currently the only locate package available on GNU/Hurd, therefore its importance. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1351861975.29093.692.ca...@s1499.it.kth.se
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 07:16:56PM -0400, Michael Gilbert wrote: On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote: On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. Can you give a few examples, if this is a rather common case ? I asked examples from Svante Signell and got examples from Michael Gilbert. Let's have a look : wine: http://bugs.debian.org/585409 (new upstream pushed via nmu) This is a good example where talking helped to gather all views on all aspects from all involved people. My impression is that finally the maintainer allowed new co-maintainers doing things differently. That does not really match Lucas' proposal which is about marking packages as orphaned so that they can be taken over by a new maintainer. python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu) This does not seem to be an example of the maintainer refuses to package any newer upstream. This seems to be just an NMU, not related to Lucas' proposal. mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) Same here, this does not seem to be an example of the maintainer refuses to package any newer upstream, and the prepared NMU seems to be just that, not related to Lucas' proposal. (Also, the prepared NMU seems still not ready, in my opinion.) many others I'm sure Do we have examples of the rather common case Svante Signell described that are not yet solved ? Cases where we can evaluate Lucas' proposal with ? I doubt that we can find (many) such examples, because when the maintainer refuses to package any newer upstream then there is obviously a disagreement, and the proposed ITO procedure was meant to deal with obvious cases, not with disagreements/disputes. It's not that common to encounter maintainer's with this kind of unproductive attitude, but when it does happen it seems to occur rather often in important packages. Thus, we should really have a documented guideline for these cases. The go ahead and fix it via nmu is one solution that has been quite effective so far and seemingly uncontroversial to the maintainers that had been getting in the way. I think that Lucas' proposal is not meant to address cases where the maintainer has an unproductive attitude or is getting in the way, but rather meant for the obvious cases, where a consensus to mark the package as orphaned is reached easily. My thoughts on this debate at this point, not related Michael Gilbert's message I'm now replying to, is that I read many opinions and not many examples. I think that using examples of real packages in Debian could help to find common situations and to agree on recommended approaches to be documented in the dev-ref. This debate would make more sense to me when it is brought closer to reality, with real examples of packages in Debian. Real examples we can evaluate Lucas' proposal on. But I shouldn't tell other people to give examples without doing it myself. :-) So I hereby disclose my whitelist that I meant earlier: http://qa.debian.org/~bartm/wnpp-rfs-mentors/wnpp-whitelist.txt http://lists.debian.org/debian-devel/2012/10/msg00625.html I would like to allow current practice to be continued regardless of what is added in dev-ref. I also welcome additions to dev-ref that invite more people to help with getting more packages needing a new maintainer identified sooner, so that these packages can be salvaged by interested new contributors. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121101084855.gb26...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
]] Michael Gilbert mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) many others I'm sure The suggested NMU that does random changes like changing the packaging to 3.0 (quilt) and adding an uploader? Is that even a serious suggestion? The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5iltzvo@qurzaw.varnish-software.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, 2012-11-01 at 08:48 +, Bart Martens wrote: On Wed, Oct 31, 2012 at 07:16:56PM -0400, Michael Gilbert wrote: On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote: On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. Can you give a few examples, if this is a rather common case ? Good that somebody else than me gave the examples, so it is not only me. Comments and more examples below. I asked examples from Svante Signell and got examples from Michael Gilbert. Let's have a look : wine: http://bugs.debian.org/585409 (new upstream pushed via nmu) This is a good example where talking helped to gather all views on all aspects from all involved people. My impression is that finally the maintainer allowed new co-maintainers doing things differently. That does not really match Lucas' proposal which is about marking packages as orphaned so that they can be taken over by a new maintainer. I think the proposal should include also case like this, since one solution would be to open up for team maintenance of package. This would exclude problems in opinion between the maintainer and the bug submitter about which packages to keep updated with upstream releases. mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) Same here, this does not seem to be an example of the maintainer refuses to package any newer upstream, I think it is. and the prepared NMU seems to be just that, not related to Lucas' proposal. (Also, the prepared NMU seems still not ready, in my opinion.) Well the submitted files was not an NMU, I would need a sponsor for that. It was a wish that the maintainer would complete the packaging, but that did not happen. The changelog entry was for installation at debian-ports. If the maintainer had adopted the changes, the changelog would have been written accordingly by him, of course. The package is built and installed at debian-ports for GNU/Hurd where a sponsor was available. FYI, this package is currently the only locate package available on GNU/Hurd, therefore its importance. many others I'm sure Do we have examples of the rather common case Svante Signell described that are not yet solved ? Cases where we can evaluate Lucas' proposal with ? Below are examples in past time: emacs24: http://bugs.debian.org/647213 If the pre-releases had been packaged, emacs24 would be the default version for Wheezy, not emacs23. Unfortunately the packaging of emacs24 was made too late to be in time for the freeze. This is another example where more hands could have resolved the situation, read team maintenance again. logrotate: http://bugs.debian.org/613342 http://bugs.debian.org/633529 The new upstream was finally packaged after half a year delay, two releases later. In this case the update could have been much quicker, again with team maintenance or support from users/other maintainers to the maintainer. file: http://bugs.debian.org/612742 http://bugs.debian.org/619225 http://bugs.debian.org/cgi-bin/626340 The package uploaded was made four upstream releases later after seven months. With help from other people the upgrade could have happened much earlier. I doubt that we can find (many) such examples, because when the maintainer refuses to package any newer upstream then there is obviously a disagreement, and the proposed ITO procedure was meant to deal with obvious cases, not with disagreements/disputes. One example (not about upstream issues however): x86info: http://bugs.debian.org/468696 This is an example of maintainer attitude. This is also a package available at debian-ports. Not that the above bugs are somewhat GNU/Hurd related, but at the time of bug submissions Hurd was a potential release architecture for Wheezy. History shows that it is not, but it will (hopefully) be in Wheezy+1. I think that Lucas' proposal is not meant to address cases where the maintainer has an unproductive attitude or is getting in the way, but rather meant for the obvious cases, where a consensus to mark the package as orphaned is reached easily. Maybe the definition should be widened. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1351767608.29093.621.ca...@s1499.it.kth.se
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote: ]] Michael Gilbert mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) many others I'm sure The suggested NMU that does random changes like changing the packaging to 3.0 (quilt) and adding an uploader? Is that even a serious suggestion? Sure, the package as its prepared now, would not be a good candidate, and especially since it was prepared after the freeze. However, if the work had been started far earlier, someone could have helped guide the work in a direction that would have been suitable. The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. It may not have include changes interesting to you, but there was certainly interest to others in the hurd improvements, and I think we should really try to be accommodating to hurd porters as much as possible. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MO6TO6mqp4VAsc4EaOgfLQXNM5h=zshhjwunwd4ayx...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote: wine: http://bugs.debian.org/585409 (new upstream pushed via nmu) This is a good example where talking helped to gather all views on all aspects from all involved people. My impression is that finally the maintainer allowed new co-maintainers doing things differently. That does not really match Lucas' proposal which is about marking packages as orphaned so that they can be taken over by a new maintainer. It matches my proposal where interested contributors apply nmus as needed to improve the situation, then eventually become uploaders. python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu) This does not seem to be an example of the maintainer refuses to package any newer upstream. This seems to be just an NMU, not related to Lucas' proposal. As we were getting close to the freeze, python2.6 was in a poor situation where it was going to ship with 2.6.7 in wheezy, and thus lack a whole bunch of security updates. Julien Cristau made the decision that this would be unacceptable, and prepared a new upstream nmu resolving the inactivity. This is certainly a case of a maintainer acting in an unproductive manner. The previous 2.6.7 upload was made almost an entire year prior to that. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnituoyqk9yw27smjyue7dd75mhg9fgrr+nz8t0jby...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
]] Michael Gilbert On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote: [...] The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. It may not have include changes interesting to you, but there was certainly interest to others in the hurd improvements, and I think we should really try to be accommodating to hurd porters as much as possible. «For wheezy» is operative in my statement. hurd is not a wheezy release architecture, and it's actually not even part of Debian any longer any more than HPPA or AVR32 is. Making changes for such architectures, when we're approaching a freeze, is pretty high on my «stuff I'm not going to spend time on» list. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqy59lrf@xoog.err.no
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote: The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. It may not have include changes interesting to you, but there was certainly interest to others in the hurd improvements, and I think we should really try to be accommodating to hurd porters as much as possible. «For wheezy» is operative in my statement. hurd is not a wheezy release architecture, and it's actually not even part of Debian any longer any more than HPPA or AVR32 is. Making changes for such architectures, when we're approaching a freeze, is pretty high on my «stuff I'm not going to spend time on» list. That's where nmus help. Someone that does care and does have the time can go ahead and get the features interesting them (and likely many other users) to work. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOkBMNwXg1RZimYOLZnFfnGaJ1=gx4dhsvzwvkjxqm...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Michael Gilbert mgilb...@debian.org writes: On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote: «For wheezy» is operative in my statement. hurd is not a wheezy release architecture, and it's actually not even part of Debian any longer any more than HPPA or AVR32 is. Making changes for such architectures, when we're approaching a freeze, is pretty high on my «stuff I'm not going to spend time on» list. That's where nmus help. Someone that does care and does have the time can go ahead and get the features interesting them (and likely many other users) to work. That's only true if you're happy with all of the changes being reverted in the next maintainer upload. If you're not happy with that, then no, NMUs do not help with this. Rather, they are a passive-aggressive way of *forcing* a maintainer to do work to incorporate changes that they already decided they didn't want to incorporate. That may be appropriate if what's actually happening is that the package is orphaned, but when it's a disagreement over how the package should be maintained, it's more likely to just start a revert war, which doesn't make anyone better off. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqy5ktq8@windlord.stanford.edu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 3:29 PM, Russ Allbery r...@debian.org wrote: That's where nmus help. Someone that does care and does have the time can go ahead and get the features interesting them (and likely many other users) to work. That's only true if you're happy with all of the changes being reverted in the next maintainer upload. If you're not happy with that, then no, NMUs do not help with this. Rather, they are a passive-aggressive way of *forcing* a maintainer to do work to incorporate changes that they already decided they didn't want to incorporate. That may be appropriate if what's actually happening is that the package is orphaned, but when it's a disagreement over how the package should be maintained, it's more likely to just start a revert war, which doesn't make anyone better off. Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or whatever would be agreed on). The maintainer can cancel things that he doesn't like before they get uploaded. Given a cancelling, it is then a problem for the contributor approach in a way the maintainer approves, and if not and they continue to disagree with the maintainer, then a trip to the Tech Committee. Again, all of this is rather rare, and only done by a DD who knows the consequences of his/her actions and who we're already trusting with the power of nmu. We should try to get out of the way of capable people trying to make things better. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mn7pympqfzrfgwgh6imbxkwmajhsfuia6krucurqg2...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Michael Gilbert mgilb...@debian.org writes: Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or whatever would be agreed on). The maintainer can cancel things that he doesn't like before they get uploaded. You're still making the maintainer take explicit action to stop something that he already said they didn't want to happen. I don't see why you think this is going to make anything better. I believe nearly everyone is going to react badly, and possibly strongly, to that sort of action. That's just how humans work. We should try to get out of the way of capable people trying to make things better. If we do that by letting people take passive-aggressive action against other maintainers, we're going to create a social problem that's much worse than the problem of some technical issues going unaddressed. If we want to treat packages as more group-maintained than maintained by individuals (and there are valid arguments in favor of moving in that direction), we should do that explicitly and with some thought and discussion. That's not what NMUs are for, nor is it something that we should be doing in passive-aggressive ways. If that's what we are going to do, we should do it openly and clearly and with the proper technical support (such as, for example, pushing the package into a shared VCS so that the person making the changes can incorporate them into the same packaging that the maintainer will be using for the next maintainer upload). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip9pkrcn@windlord.stanford.edu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
]] Michael Gilbert On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote: The new upstream release did not include any particularly compelling changes for wheezy, which is why I did not update to the newer upstream version. It may not have include changes interesting to you, but there was certainly interest to others in the hurd improvements, and I think we should really try to be accommodating to hurd porters as much as possible. «For wheezy» is operative in my statement. hurd is not a wheezy release architecture, and it's actually not even part of Debian any longer any more than HPPA or AVR32 is. Making changes for such architectures, when we're approaching a freeze, is pretty high on my «stuff I'm not going to spend time on» list. That's where nmus help. I think you misunderstood me. Given there already existed a package in the archive, which was in good shape for the release, changing that package would be a bad idea. Every change carries risk with it, however small. Whether it's the maintainer or an NMUer making that change is less important. Someone that does care and does have the time can go ahead and get the features interesting them (and likely many other users) to work. I find it hard to classify a port that has a number of popcon submissions somewhere between alpha and sh4 as having «many users». -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip9p9hu7@xoog.err.no
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Michael Gilbert michael.s.gilb...@gmail.com writes: On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote: Michael Gilbert mgilb...@debian.org writes: Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or whatever would be agreed on). The maintainer can cancel things that he doesn't like before they get uploaded. You're still making the maintainer take explicit action to stop something that he already said they didn't want to happen. I don't see why you think this is going to make anything better. I believe nearly everyone is going to react badly, and possibly strongly, to that sort of action. That's just how humans work. For a time, this is how regular nmus were greeted, but as a project, we've gotten over that unwarranted stigma and recongnized nmus as valuable contributions that do a lot to help when the maintainer (for whatever reason) isn't getting around to fixing his/her own problems. This is absolutely not true when it's not a matter of the maintainer not having time and is instead a matter of the maintainer saying I do not want a new package uploaded with those changes at this time. So, anyway, I don't see how support of more liberal nmu with longer delays will cause nearly everyone to react badly. An NMU against the maintainer's explicit wishes will cause nearly everyone to react badly. We've already done it for wine and python2.6 with 0/2 badness, and 0% badness rate is not even close to some kind of percentage needed to qualify as nearly everyone. My understanding is that this was not the same situation. You weren't acting directly contrary to the maintainer's stated wishes; you were doing work that the maintainer wanted done, but didn't have time to do and wasn't sure on the quality when done by someone else. It's not the same sort of thing as having the maintainer respond to a patch with not now and someone else then uploading it anyway. If that's what we are going to do, we should do it openly and clearly and with the proper technical support (such as, for example, pushing the package into a shared VCS so that the person making the changes can incorporate them into the same packaging that the maintainer will be using for the next maintainer upload). That doesn't help in the unproductive maintainer case. They reject these kinds of collaborative efforts. Which is why we have governance procedures. I don't think we are going to get the social environment that we all want to have by replacing governance procedures with an invitation for any DD who cares about a problem to upload an NMU whether the maintainer likes it or not. I'm all in favor of people being less worried about doing NMUs when the maintainer is unresponsive for whatever reason, or for things that, as a project, we have a consensus around using NMUs for. (Long-delayed translation updates, for example, particularly when approaching a freeze.) But NMUs are not a mechanism to resolve disputes between the maintainer and someone else. Once the maintainer has responded and said no, an NMU is no longer the first tool to be reaching for. It may still be appropriate in some situations, but it's now much more likely to be perceived as an openly hostile act. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878valkq38@windlord.stanford.edu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote: You're still making the maintainer take explicit action to stop something that he already said they didn't want to happen. For a time, this is how regular nmus were greeted, but as a project, we've gotten over that unwarranted stigma and recongnized nmus as valuable contributions that do a lot to help when the maintainer (for whatever reason) isn't getting around to fixing his/her own problems. It seems to me that you and Russ are talking about different NMU contexts. Russ seems to be referring to a context where the maintainer is against some specific changes and had made that clear. In that case, NMU won't help going around the maintainer objection. An NMU in such a situation will very likely be badly received. You, on the other hand, seem to be referring to a context where the maintainer is not against some changes and, in fact, might even welcome them, but simply hadn't had time to deliver. In that case NMUs would in most case be welcome, and they *should* be welcome as long as they're done properly. (But, if I may, it looks like we're diverging quite a bit in this sub-thread, whereas there seems to be agreement on the timings, at last...) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 5:00 PM, Stefano Zacchiroli wrote: On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote: You're still making the maintainer take explicit action to stop something that he already said they didn't want to happen. For a time, this is how regular nmus were greeted, but as a project, we've gotten over that unwarranted stigma and recongnized nmus as valuable contributions that do a lot to help when the maintainer (for whatever reason) isn't getting around to fixing his/her own problems. It seems to me that you and Russ are talking about different NMU contexts. Russ seems to be referring to a context where the maintainer is against some specific changes and had made that clear. In that case, NMU won't help going around the maintainer objection. An NMU in such a situation will very likely be badly received. You, on the other hand, seem to be referring to a context where the maintainer is not against some changes and, in fact, might even welcome them, but simply hadn't had time to deliver. In that case NMUs would in most case be welcome, and they *should* be welcome as long as they're done properly. Maybe an example will help get us on the same page. Russ seems to have the impression that my proposal is somehow a license to push unwanted changes at a maintainer. That is not true. Let's consider mlocate as a hypothetical: - The contributor wants a new upstream for better hurd support - He prepares an nmu of that new upstream (making sure to not modify the maintainer's build setup and packaging style) - He convinces a DD that this is worthwhile to sponsor, and that DD decides that he is willing to take the social risk involved if something goes wrong - The DD uploads the package to DELAYED/whatever we agree is long enough and sends an nmudiff to the mlocate bts - The maintainer gets the mail, cancels the upload, and says to the contributor for me hurd support is not enough to take the risk of a new upstream upload - In this case, the contributor would probably say ok that's fine, and not push it further - But if he really thought it was that important, he would take it to the Tech Committee, and in this case, the committee would most likely side with the maintainer's opinion So, overall everyone had a chance to get their say. The maintainer had the most power (as long as they're checking their mail more often than whatever delay we agree is long enough). If the maintainer didn't have strong opinions on the upload, then there would have been no procedural ACK/NACK roadblocks, and the Tech Committee only got pulled if there were really strong feelings. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmsfe35tiyukttmjewhng1g34rlngiy98i9n6b4qi+...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote: Maybe an example will help get us on the same page. Russ seems to have the impression that my proposal is somehow a license to push unwanted changes at a maintainer. That is not true. Let's consider mlocate as a hypothetical: - The contributor wants a new upstream for better hurd support - He prepares an nmu of that new upstream (making sure to not modify the maintainer's build setup and packaging style) - He convinces a DD that this is worthwhile to sponsor, and that DD decides that he is willing to take the social risk involved if something goes wrong - The DD uploads the package to DELAYED/whatever we agree is long enough and sends an nmudiff to the mlocate bts - The maintainer gets the mail, cancels the upload, and says to the contributor for me hurd support is not enough to take the risk of a new upstream upload - In this case, the contributor would probably say ok that's fine, and not push it further - But if he really thought it was that important, he would take it to the Tech Committee, and in this case, the committee would most likely side with the maintainer's opinion In this scenario the contributor should have talked to the maintainer before requesting a sponsor. http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu | Have you clearly expressed your intention to NMU, at least in the BTS? It is | also a good idea to try to contact the maintainer by other means (private | email, IRC). If the maintainer is usually active and responsive, have you | tried to contact them? In general it should be considered preferable that | maintainers take care of an issue themselves and that they are given the chance | to review and correct your patch, because they can be expected to be more aware | of potential issues which an NMUer might miss. It is often a better use of | everyone's time if the maintainer is given an opportunity to upload a fix on | their own. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121101225959.ga7...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote: On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote: Maybe an example will help get us on the same page. Russ seems to have the impression that my proposal is somehow a license to push unwanted changes at a maintainer. That is not true. Let's consider mlocate as a hypothetical: - The contributor wants a new upstream for better hurd support - He prepares an nmu of that new upstream (making sure to not modify the maintainer's build setup and packaging style) - He convinces a DD that this is worthwhile to sponsor, and that DD decides that he is willing to take the social risk involved if something goes wrong - The DD uploads the package to DELAYED/whatever we agree is long enough and sends an nmudiff to the mlocate bts - The maintainer gets the mail, cancels the upload, and says to the contributor for me hurd support is not enough to take the risk of a new upstream upload - In this case, the contributor would probably say ok that's fine, and not push it further - But if he really thought it was that important, he would take it to the Tech Committee, and in this case, the committee would most likely side with the maintainer's opinion In this scenario the contributor should have talked to the maintainer before requesting a sponsor. This would be something that his potential DD sponsors would have taken into consideration before agree to a sponsorship. So, yes, I've taken a bit of liberty in terms of assuming that a DD could be convinced that mlocate was in a state where this needs to happen when clearly its not. Since this is a hypothetical, I'm free to set constraints, so please assume mlocate were in a worse state than it really is above. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MMy5bb2NZ8Bu=C5OPS82ww=prrwcpcyyho6wxddxe9...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Tue, Oct 30, 2012 at 02:30:20PM +, Ian Jackson wrote: Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. I keep on thinking that we are talking about different packages. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: - lagging *way* behind upstream (regarding time or version number) - leaving open bugs simply unanswered (=do not give any reasons for not working on a bug) - etc. I do not speak about feelings but measurable facts. So I don't think counting time-since-last-touched towards the notification period (even in the moral sense you're now doing) is reasonable. I should be more precise: It is not time-since-last-touched but rather time-with-reported-problem-but-no-reaction. I definitely expect a maintainer to at least respons to a bug report somehow like I'm willing to do something in time X but do not have time now bla bla. If you find several bugs on a package with no response (assuming reasonable reports which for instance also might affect a potential orphaner) I would perfectly include the time-since-last-issue-without-any-reaction into the waiting time and this is the time X I was talking about (and I always lived under the impression that we are talking about packages of this kind. Also this argument is a form of this has been waiting for ages so now it is urgent which I don't really agree with (unless there's an actual deadline of course). I would rather call it a this has been waiting for ages so you are obviosely not interested and no harm is done if I take action nowish. Unless we're having some heavyweight process with multiple pings etc. (which we IMO shouldn't) the way the maintainer might first discover that someone feels the package needs to be orphaned is by the ITO bug. The maintainer needs to have a good chance to object. Why should a maintainer who ignored several other bugs should be astonished about such kind of a bug? OK, if you want a chance for objection: Lets add to the procedure an upload to DELAYED/15 which gives another two weeks time to react. I definitely think that somebody who really is in the mood of salvaging a package and has some momentum should not be delayed a longer time than two weeks to start with some action. We are not talking about stealing packages right at the first day of a maintainers VAC, right? That's not the intent, of course. But if we invent a new process with objective criteria, it needs to be robust against malicious interpretation (or indeed careless action which follows the letter of the rules). I did not followed all the mails of this thread but I never had the impression that the drivers of a simple package salvaging process seemed to some extend careless. I respect my fellow maintainers high enough to simply assume that they do not do careless action and will deal with the rules sensible enough that no extra hurdles are needed. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031070545.gb32...@an3as.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 3:05 AM, Andreas Tille wrote: Unless we're having some heavyweight process with multiple pings etc. (which we IMO shouldn't) the way the maintainer might first discover that someone feels the package needs to be orphaned is by the ITO bug. The maintainer needs to have a good chance to object. Why should a maintainer who ignored several other bugs should be astonished about such kind of a bug? OK, if you want a chance for objection: Lets add to the procedure an upload to DELAYED/15 which gives another two weeks time to react. I definitely think that somebody who really is in the mood of salvaging a package and has some momentum should not be delayed a longer time than two weeks to start with some action. That is essentially my proposal then. Maybe we need a DELAYED/30 (or more) queue for orphaning uploads? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpoo1xvbfzymliwfpqems_j5so0wrg0lkubirf253h...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* Andreas Tille andr...@an3as.eu [121031 08:06]: Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. I keep on thinking that we are talking about different packages. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: - lagging *way* behind upstream (regarding time or version number) There were some cases in the past where the maintainer did not package new upstream version because they had some serious issues (or because they only wanted to follow stable releases in cases where stable and preview releases were hard to distinguish for a outsider) while someone else mistook this for a missing action. - leaving open bugs simply unanswered (=do not give any reasons for not working on a bug) Who of us never put some unimportant bug that would need some longer investigating in a row to make sure it is actually not a bug and forgot to post a little note of will look into this later. I do not speak about feelings but measurable facts. Many facts are not black and white, but in practise there is much of gray. Also this argument is a form of this has been waiting for ages so now it is urgent which I don't really agree with (unless there's an actual deadline of course). I would rather call it a this has been waiting for ages so you are obviosely not interested and no harm is done if I take action nowish. This assumes that it actually has been waiting for so long. Different people often see things from a different perspective. And the point of this waiting is exactly to make sure that this view is not missing. If it were so clear when a package is neglected and when not, we could just do without the whole waiting period and giving the maintainer chance to object and simply hijack the package directly. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031080420.gb11...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, 2012-10-31 at 09:04 +0100, Bernhard R. Link wrote: * Andreas Tille andr...@an3as.eu [121031 08:06]: Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. I keep on thinking that we are talking about different packages. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: - lagging *way* behind upstream (regarding time or version number) There were some cases in the past where the maintainer did not package new upstream version because they had some serious issues (or because they only wanted to follow stable releases in cases where stable and preview releases were hard to distinguish for a outsider) while someone else mistook this for a missing action. How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1351672360.363.10.ca...@hp.my.own.domain
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote: I keep on thinking that we are talking about different packages. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: - lagging *way* behind upstream (regarding time or version number) There were some cases in the past where the maintainer did not package new upstream version because they had some serious issues (or because they only wanted to follow stable releases in cases where stable and preview releases were hard to distinguish for a outsider) while someone else mistook this for a missing action. You simply can not mistake this as missing in action if the maintainer would state this in the bug log and I *expect* a maintainer to exactly do this in response to such a bug report. If you read my mail closely I was never talking about closing bugs but responding to bugs. - leaving open bugs simply unanswered (=do not give any reasons for not working on a bug) Who of us never put some unimportant bug that would need some longer investigating in a row to make sure it is actually not a bug and forgot to post a little note of will look into this later. Me. It is a question of respect to the bug reporter to at least respond to the issue. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031084237.gb2...@an3as.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. If the maintainer gives reasons to stick to the old version and is explaining these reason I do not see a case for a valid salvage process. If I were the maintainer in question I would offer team maintenance to the potential salvagers and would even sponsor their packages to experimental if they would care for the experimental branch. This is what I would call sensible and helpful behaviour. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031084811.gc2...@an3as.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
]] Svante Signell How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? That sounds like a hostile takeover, something I think we really want to avoid. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87390uvn6i@qurzaw.varnish-software.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Andreas Tille writes (Re: [PROPOSAL v2] Orphaning another maintainer's packages): On Tue, Oct 30, 2012 at 02:30:20PM +, Ian Jackson wrote: Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. I keep on thinking that we are talking about different packages. Yes. If a maintainer is simply feels that the packages didn't need any attention these are not packages which are for instance: [ examples of things which might be wrong ] The problem is that all of these things are subjective. The person doing the ITO may think one thing; the maintainer a different thing. The rules we are now writing need to be based on objective criteria. Since there is nothing in the process that actually demands any particular level of lack of maintenance, the criteria need to be based on something else - in this case, proper agreement or at least lack of active objection. OK, if you want a chance for objection: Lets add to the procedure an upload to DELAYED/15 which gives another two weeks time to react. I definitely think that somebody who really is in the mood of salvaging a package and has some momentum should not be delayed a longer time than two weeks to start with some action. That would satisfy me. It is also then reasonable for the process to allow (but not require) this upload to DELAYED/15 to even be a takeover with all the work and reorganisation that the intending new maintainer thinks is appropriate. The risk of course is that the old maintainer rejects the upload and the work is wasted - and no doubt some bad feeling. Whether to take that risk is a decision for the prospective new maintainer. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20625.8956.853070.414...@chiark.greenend.org.uk
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Svante Signell svante.sign...@telia.com writes: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? No, I think that's more of a Technical Committee issue, since that's an actual disagreement over how to maintain the package where someone wants to override the maintainer's decision. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip9q629c@windlord.stanford.edu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. Can you give a few examples, if this is a rather common case ? Sometimes there are good reasons to not package a newer upstream release, see for example bugs 672568 and 687690. Sometimes the maintainer is simply gone, see for example bug 671890. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031183400.ga17...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* Andreas Tille andr...@an3as.eu [121031 09:43]: On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote: Who of us never put some unimportant bug that would need some longer investigating in a row to make sure it is actually not a bug and forgot to post a little note of will look into this later. Me. Does this also include packages where you are listed as Uploader? ;- It is a question of respect to the bug reporter to at least respond to the issue. I do not disagree that it is something that should be done. But that does not mean it is never forgotten. (Or one discusses with the submitter privately and forgets to follow up in the bug report or or or). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121031194817.ga12...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote: On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote: How to solve the following problem: Assume a package with wishlist bugs filed lagging behind upstream and the maintainer refuses to package any newer upstream, not even into experimental. And in general there is an interest (from several people) in having the new upstream versions packaged. Can this package become salvaged in some way by the ITS/ITO procedure? I think this is a rather common case, a cautious maintainer and some more adventurous salvagers. Can you give a few examples, if this is a rather common case ? wine: http://bugs.debian.org/585409 (new upstream pushed via nmu) python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu) mlocate: http://bugs.debian.org/669368 (new upstream could have been pushed via nmu before the freeze, but it was prepared too late) many others I'm sure It's not that common to encounter maintainer's with this kind of unproductive attitude, but when it does happen it seems to occur rather often in important packages. Thus, we should really have a documented guideline for these cases. The go ahead and fix it via nmu is one solution that has been quite effective so far and seemingly uncontroversial to the maintainers that had been getting in the way. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNCgtiFWg9XC6ZJf9Pp+O67njyxf=xp7uyv6gody0z...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Hi, On 01.11.2012 00:16, Michael Gilbert wrote: It's not that common to encounter maintainer's with this kind of unproductive attitude, but when it does happen it seems to occur rather often in important packages. Thus, we should really have a documented guideline for these cases. The go ahead and fix it via nmu is one solution that has been quite effective so far and seemingly uncontroversial to the maintainers that had been getting in the way. Developer's Reference contains a guideline for this case. It is by no way forbidden to package new upstream versions or less important issues in NMUs. Point being is, NMUs should aim to make changes in spirit of the packager and in line with his packaging work. That's not measured by keeping the upstream version or by fixing RC bugs only, but by being gentle to the maintainer, keeping the design decisions made and only touch issues which you consider really beneficial and justify that you enter in someone else's domain. I keep repeating myself: People really shouldn't be afraid to NMU, we need more NMUs - genrally speaking - but it should be done in a nice and friendly way and by respecting design choices by others. A NMU is not about forcing someone else to obey your personal tastes and preferences. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Lucas Nussbaum writes ([PROPOSAL v2] Orphaning another maintainer's packages): - one week has passed since the ITO bug was submitted, and at least 3 DDs supported the orphaning (possibly including the submitter of the ITO bug, if it was a DD), while nobody objected. I think one week is far too short. I think Zack's proposed 15 days is still far too short. As so many people have sid, none of this is urgent. I think four weeks would be much better. A maintainer might reasonably go abroad for 2-3 weeks - we even have a VAC process for handling absences. (And we don't want to complicate this third-party orphan process with references to VACs.) Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20623.53877.252062.170...@chiark.greenend.org.uk
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote: Lucas Nussbaum writes ([PROPOSAL v2] Orphaning another maintainer's packages): - one week has passed since the ITO bug was submitted, and at least 3 DDs supported the orphaning (possibly including the submitter of the ITO bug, if it was a DD), while nobody objected. I think one week is far too short. I think Zack's proposed 15 days is still far too short. As so many people have sid, none of this is urgent. I think four weeks would be much better. A maintainer might reasonably go abroad for 2-3 weeks - we even have a VAC process for handling absences. (And we don't want to complicate this third-party orphan process with references to VACs.) I lived under the impression that we were talking about packages which were not touched for a *long* time (way longer than four weeks). So we had some long waiting time X + 15 additional days proposed by Zack. We are not talking about stealing packages right at the first day of a maintainers VAC, right? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030135212.ga10...@an3as.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Andreas Tille writes (Re: [PROPOSAL v2] Orphaning another maintainer's packages): On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote: I think four weeks would be much better. A maintainer might reasonably go abroad for 2-3 weeks - we even have a VAC process for handling absences. (And we don't want to complicate this third-party orphan process with references to VACs.) I lived under the impression that we were talking about packages which were not touched for a *long* time (way longer than four weeks). So we had some long waiting time X + 15 additional days proposed by Zack. Consider the case where a maintainer objects. In that case you're counting in the previous long waiting time a period which the orphaner probably thinks shows disinterest in the package, but during which the maintainer may well feel (for part of the time at least) that the package simply didn't need any attention. So I don't think counting time-since-last-touched towards the notification period (even in the moral sense you're now doing) is reasonable. Also this argument is a form of this has been waiting for ages so now it is urgent which I don't really agree with (unless there's an actual deadline of course). Unless we're having some heavyweight process with multiple pings etc. (which we IMO shouldn't) the way the maintainer might first discover that someone feels the package needs to be orphaned is by the ITO bug. The maintainer needs to have a good chance to object. We are not talking about stealing packages right at the first day of a maintainers VAC, right? That's not the intent, of course. But if we invent a new process with objective criteria, it needs to be robust against malicious interpretation (or indeed careless action which follows the letter of the rules). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20623.58492.876115.508...@chiark.greenend.org.uk
Re: [PROPOSAL v2] Orphaning another maintainer's packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think four weeks would be much better. A maintainer might reasonably go abroad for 2-3 weeks - we even have a VAC process for handling absences. (And we don't want to complicate this third-party orphan process with references to VACs.) Remember that we do not really have a VAC process for the ~50% of maintainers who are not DDs [1]. That group of maintainers have no real way of letting the rest of the project know that they are on VAC [2]. They also have an interest in and a proven ability to maintain packages and so may like to help out with other unmaintained packages ... after all, we they are encouraged time and time again to adopt packages rather than introduce new ones into the archive. But they cannot know if the maintainer is on VAC or not to engage in this process. I'm not suggesting that VAC status should be public information, but blanket statements that we know if maintainers are on VAC (or MIA or whatever) are wrong for 50% of our maintainers as are statements that potential salvagers have this information. cheers Stuart [1] http://lists.debian.org/jr6344$lkp$1...@dough.gmane.org [2] I would encourage them to let their sponsors know this since the sponsors are in the position of helping care for their packages anyway - -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCP7EgACgkQn+i4zXHF0ajEqACgvyXY9SvtOYjjh0RsaUrgO580 n7UAoNPA7ggz/QbjhHBaO4K3ZPdqsiXi =5Qyy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k6oq8f$22k$1...@ger.gmane.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Le mardi 30 octobre 2012 16:03:35, Stuart Prescott a écrit : I think four weeks would be much better. A maintainer might reasonably go abroad for 2-3 weeks - we even have a VAC process for handling absences. (And we don't want to complicate this third-party orphan process with references to VACs.) Remember that we do not really have a VAC process for the ~50% of maintainers who are not DDs [1]. That group of maintainers have no real way of letting the rest of the project know that they are on VAC [2]. They actually can send an email to debian-private to notify other DD that they are on VAC. They cannot subscribe to this mailing list but they can send mail to it. cheers Stuart Cheers, Thomas signature.asc Description: This is a digitally signed message part.
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Stuart Prescott writes (Re: [PROPOSAL v2] Orphaning another maintainer's packages): I'm not suggesting that VAC status should be public information, but blanket statements that we know if maintainers are on VAC (or MIA or whatever) are wrong for 50% of our maintainers as are statements that potential salvagers have this information. This is a good point. Another reason why the post-ITO waiting period should be much longer than two weeks. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20623.63037.387949.829...@chiark.greenend.org.uk
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Quoting Lucas Nussbaum (lu...@lucas-nussbaum.net): I think I agree with everybody, so here is a new version of the last step of the proposed procedure: I read the huge thread quickly during last days and I think your text well summarizes what seems to be the best consensus. That's great work, Lucas, much appreciated and it had to be said..:-) signature.asc Description: Digital signature
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sun, Oct 28, 2012 at 12:19 AM, Michael Gilbert mgilb...@debian.org wrote: On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote: maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. I think that this misses one of the reasons for the original proposal, which is to provide guidelines to the contributors who refrain from orphaning packages because they are not sure how to appreciate whether packages seem abandonned. Everybody who are confident in what they are doing can orphan anything any time. And they are fully responsible for their mistakes. The guidelines that are proposed to be added in the Developers reference are a formal process, which purpose is to help the orphaners to strongly reduce the chances that they make a mistake. If, as Bart has found, such mistakes are quite rare, then why worry so much? We don't need new formal processes for rarely occurring social problems. We need more people willing to help those that make social mistakes to learn and improve themselves. It's not that too many people are making mistakes. It's that too many people don't take any action out of fear of making the mistake in the first place. That's why we need a well defined process (or to at least codify the status quo more clearly). -- Andrew Starr-Bochicchio Soon to be a...@debian.org Just waiting on account creation! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal6k_axvhbxxe-w3_0zwjpx3pvn3yfvufbzasw8xrhieyot...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Andrew Starr-Bochicchio a.star...@gmail.com writes: Michael Gilbert mgilb...@debian.org wrote: If, as Bart has found, such mistakes are quite rare, then why worry so much? We don't need new formal processes for rarely occurring social problems. We need more people willing to help those that make social mistakes to learn and improve themselves. It's not that too many people are making mistakes. It's that too many people don't take any action out of fear of making the mistake in the first place. That's why we need a well defined process (or to at least codify the status quo more clearly). Yes, exactly. I don't want to be trusted to orphan packages on my own, and I've been a DD for years. It's too much pressure! And as a result, I basically never do it. One of the huge advantages of somewhat more formal systems is that they remove the feeling of personal responsibility and provide some sort of system that can deal with issues, which can make the whole thing feel much more comfortable for everyone involved. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcduh96z@windlord.stanford.edu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sun, Oct 28, 2012 at 12:07 PM, Russ Allbery wrote: If, as Bart has found, such mistakes are quite rare, then why worry so much? We don't need new formal processes for rarely occurring social problems. We need more people willing to help those that make social mistakes to learn and improve themselves. It's not that too many people are making mistakes. It's that too many people don't take any action out of fear of making the mistake in the first place. That's why we need a well defined process (or to at least codify the status quo more clearly). Yes, exactly. I don't want to be trusted to orphan packages on my own, and I've been a DD for years. It's too much pressure! And as a result, I basically never do it. One of the huge advantages of somewhat more formal systems is that they remove the feeling of personal responsibility and provide some sort of system that can deal with issues, which can make the whole thing feel much more comfortable for everyone involved. I think everyone is in agreement on that defined rules are bound to improve the situation. The question (at least with respect to non-maintainer orphaning) is, do we codify the tried and true bug report + wait 4*7*24*3600 system, or do we take a gamble with one of the new untested bureaucratic ones? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOJNWTDUwaQ1B=ZwCc_diJEN8GqcfLydv-B8=mu+3a...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote: ---8 4. When/if consensus has been reached, or if no objections have been raised, the package can be orphaned by retitling and reassigning the ITO bug accordingly. Here are some example situations where it is considered acceptable to move forward: - one month has passed since the ITO bug was submitted, and nobody objected to the orphaning; - one week has passed since the ITO bug was submitted, and at least 3 DDs supported the orphaning (possibly including the submitter of the ITO bug, if it was a DD), while nobody objected. ---8 For completeness, here is the full proposal. I've also addressed a few cosmetic comments. Hi Lucas, thanks a lot for this updated draft. I think is good and I'm generally supportive of it. A remaining concern of mine, however, is the second case. One week really seems too short. I understand that 3 DDs supporting the orphaning should give a good safeguard against hostile takeovers. But I don't see the need for such a short timeframe: if there's urgency, the interested DDs can use NMUs. And on the other hand I do feel the risk of maintainers coming back from VAC and finding packages where they've invested a lot of efforts orphaned, maybe because a group of DDs working closely together ended up sharing a (wrong) view on the maintainer intentions. That has a very negative social potential and I think we should try hard to avoid it. I propose to go for 15 days before proceeding in presence of ACKs. It matches the longest DELAYED/XX period we currently have. For that reason it seems to be culturally associated with a long delay we give to people to react. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Mon, 29 Oct 2012 03:07:16 Russ Allbery wrote: Andrew Starr-Bochicchio a.star...@gmail.com writes: It's not that too many people are making mistakes. It's that too many people don't take any action out of fear of making the mistake in the first place. That's why we need a well defined process (or to at least codify the status quo more clearly). Yes, exactly. I don't want to be trusted to orphan packages on my own, and I've been a DD for years. It's too much pressure! And as a result, I basically never do it. Perhaps your experience may confirm my observation: Except for orphaning as part of MIA procedure I can't recall situation when a particular package was orphaned by non-maintainer. It looks like such cases are extremely rare so as result prospective contributors are often reluctant to invest much time into improvement of de- facto unmaintained but not orphaned package. One of the huge advantages of somewhat more formal systems is that they remove the feeling of personal responsibility and provide some sort of system that can deal with issues, which can make the whole thing feel much more comfortable for everyone involved. Absolutely. Even a bit of guidelines will do very well. For example at the moment it is not obvious that adoption can begin with ITA bug to the package but this little hint can save time and improve visibility of adoption comparing to private email to maintainer if it remains unanswered. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210290958.21858.only...@member.fsf.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote: - there's some disagreement [...] More disagreement than I expected. here is a new version of the last step of the proposed procedure: For completeness, here is the full proposal. I've also addressed a few cosmetic comments. Comments? Thanks for your effort, Lucas. I don't object against this new text. However, I also had a look at the open wnpp bugs to get an idea of how packages are currently being orphaned or put up for adoption in practice. I started from all open RFA, O and ITA bugs. Then I excluded the wnpp bugs for which the bug submitter is one of the package maintainers. I also excluded the wnpp bugs for packages already having Debian QA Group as the maintainer, mostly for practical reasons, so my study is not complete on this part, but I guess that there's little discussion about these packages. Then I excluded the wnpp bugs for packages for which the maintainer has MIA status inactive, unresponsive, retiring, mia, needs-wat, retired or removed. I have read all remaining wnpp bugs. I noticed that quite some packages are being orphaned and put up for adoption without corresponding status in the MIA database. Sounds alarming, but in reality things go quite smooth. The bug submitters seem to be very reasonable. At this point I see no problem with the currently open O, RFA and ITA bugs. I also realized that I can repeat this study automatically and periodically, daily or so, to early detect suspicious new O, RFA and ITA bugs. It is not much work to review the suspicious ones and whitelist the good ones. The remaining ones can be cancelled or debated. So maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. Sounds revolutionary, but in reality this is more or less already happening. Thoughts ? Comments ? Am I overlooking something ? Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121027141925.gc27...@master.debian.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 10:19 AM, Bart Martens wrote: So maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. Sounds revolutionary, but in reality this is more or less already happening. Thoughts ? Comments ? Am I overlooking something ? For change of pace, I am fully supportive of this proposal. This process has been tried, demonstrated, and proven effective for a long time now. It is Debian common law, so let's codify it as devref law now, and get away from these new burdensome bureaucratic proposals. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mng-jxa3acdqc+szucs60gndhtwzlrusbe-_fcuywf...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sun, 28 Oct 2012 01:19:25 Bart Martens wrote: So maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. Yes please. This is common sense and most obvious thing to do. Sounds revolutionary, but in reality this is more or less already happening. To me it sounds very reasonable. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210280923.48889.only...@member.fsf.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Le Sat, Oct 27, 2012 at 02:19:25PM +, Bart Martens a écrit : Thanks for your effort, Lucas. I don't object against this new text. Many thanks and thumbs up to Lucas as well. maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. I think that this misses one of the reasons for the original proposal, which is to provide guidelines to the contributors who refrain from orphaning packages because they are not sure how to appreciate whether packages seem abandonned. Everybody who are confident in what they are doing can orphan anything any time. And they are fully responsible for their mistakes. The guidelines that are proposed to be added in the Developers reference are a formal process, which purpose is to help the orphaners to strongly reduce the chances that they make a mistake. In my understanding, the existence of such a process would not prevent people who know what they are doing to orphan packages when it makes sense. But for the non-exceptional cases, let's recomend to follow written recommendations who are clear to everyone. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121028005158.ga24...@falafel.plessy.net
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote: maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. I think that this misses one of the reasons for the original proposal, which is to provide guidelines to the contributors who refrain from orphaning packages because they are not sure how to appreciate whether packages seem abandonned. Everybody who are confident in what they are doing can orphan anything any time. And they are fully responsible for their mistakes. The guidelines that are proposed to be added in the Developers reference are a formal process, which purpose is to help the orphaners to strongly reduce the chances that they make a mistake. If, as Bart has found, such mistakes are quite rare, then why worry so much? We don't need new formal processes for rarely occurring social problems. We need more people willing to help those that make social mistakes to learn and improve themselves. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnvaqc-x21m6tegwzjxd6mhz9kghp4+wpcksxpm7o3...@mail.gmail.com
