Re: Busy work
On Fri, 2011-02-04 at 18:46 +, Chris Coulson wrote: On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote: it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Including a patch often doesn't help anyway. That just leads to can you make a debdiff rather than a patch? Make a debdiff, and it turns out you should have made a PPA. Make a PPA, and there are further steps. After a while you realize it's a lot less work to maintain your own copy of the package source locally than to keep trying to find the magic steps to get the fix into Ubuntu. I don't really consider a debdiff to be a necessary requirement for sponsoring a bug, especially if it is just dropping in a patch touching upstream code. What matters is that the patch is correct and of the required quality. It's not difficult for sponsors to create a package using a patch that a contributor has attached to a bug report (after all, the extra work is normally just creating a changelog entry, which isn't particularly hard). I hope your experience isn't the norm. If we are driving away contributors and turning away good patches because somebody hasn't provided a debdiff, then this makes me both sad and angry. Chris, Seems you are among the few odd-ones-out among the sponsors! (/me takes note for future ;p) What Akkana mentions is what happens even today. If there is no debdiff, sponsors just comment: bug report has no debdiff to sponsor here, unsubscribing sponsors. Pls resubscribe when there is a debdiff. (similar for the merges with no changelog entries) Some sponsors even get angry when subscribed for a patch. ;-) Some sponsors subscribe the Review team to make the patch - debdiff, and ask to be resubscribed later. But review team effort is not sufficient. One problem often faced is, after the patch-diff work is done, it is not sufficient enough for the patch to be uploaded, Because the patch needs to be sent upstream for their review and sponsors again unsubscribe from the bug. (yes, the reviewer should know these should go upstream! but it is more of a bug in our tools/workflow) The problem is, we are allowing patches to be attached for such packages. We have the bugs open in lp and since Ubuntu is the distro they use, they attach the patch on lp and wonder why we wait and dont just upload. Very few new folks realize that Ubuntu is more of package work than actual app/package development. IMO, Kubuntu folks have a better workflow. If it is not a bug caused by Ubuntu changes, they just close the lp bug and continue discussion on the upstream bugs. Which makes it a bit clearer where the patch/discussion needs to go. I'm not suggesting that we suddenly switch our entire workflow, but Maybe not allow patches to be uploaded for packages not hosted on lp or notify when patch is being attached and only allow to attach when they choose to ignore the notification? Not sure what the ideal solution is but whatever it is, we need to make sure that we dont accumulate patches in lp and drive away potential contributors. -- Cheers, Vish I'm quite new to this whole process, but if patches are frowned on in lp, then why are these accepted?!? Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Busy work
On Fri, 2011-02-04 at 18:46 +, Chris Coulson wrote: On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote: it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Including a patch often doesn't help anyway. That just leads to can you make a debdiff rather than a patch? Make a debdiff, and it turns out you should have made a PPA. Make a PPA, and there are further steps. After a while you realize it's a lot less work to maintain your own copy of the package source locally than to keep trying to find the magic steps to get the fix into Ubuntu. I don't really consider a debdiff to be a necessary requirement for sponsoring a bug, especially if it is just dropping in a patch touching upstream code. What matters is that the patch is correct and of the required quality. It's not difficult for sponsors to create a package using a patch that a contributor has attached to a bug report (after all, the extra work is normally just creating a changelog entry, which isn't particularly hard). I hope your experience isn't the norm. If we are driving away contributors and turning away good patches because somebody hasn't provided a debdiff, then this makes me both sad and angry. Chris, Seems you are among the few odd-ones-out among the sponsors! (/me takes note for future ;p) What Akkana mentions is what happens even today. If there is no debdiff, sponsors just comment: bug report has no debdiff to sponsor here, unsubscribing sponsors. Pls resubscribe when there is a debdiff. (similar for the merges with no changelog entries) Some sponsors even get angry when subscribed for a patch. ;-) Some sponsors subscribe the Review team to make the patch - debdiff, and ask to be resubscribed later. But review team effort is not sufficient. One problem often faced is, after the patch-diff work is done, it is not sufficient enough for the patch to be uploaded, Because the patch needs to be sent upstream for their review and sponsors again unsubscribe from the bug. (yes, the reviewer should know these should go upstream! but it is more of a bug in our tools/workflow) The problem is, we are allowing patches to be attached for such packages. We have the bugs open in lp and since Ubuntu is the distro they use, they attach the patch on lp and wonder why we wait and dont just upload. Very few new folks realize that Ubuntu is more of package work than actual app/package development. IMO, Kubuntu folks have a better workflow. If it is not a bug caused by Ubuntu changes, they just close the lp bug and continue discussion on the upstream bugs. Which makes it a bit clearer where the patch/discussion needs to go. I'm not suggesting that we suddenly switch our entire workflow, but Maybe not allow patches to be uploaded for packages not hosted on lp or notify when patch is being attached and only allow to attach when they choose to ignore the notification? Not sure what the ideal solution is but whatever it is, we need to make sure that we dont accumulate patches in lp and drive away potential contributors. -- Cheers, Vish -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Busy work
Just now, I got a notification about a bug I filed two and a half years ago: https://bugs.launchpad.net/ubuntu/+source/pmount/+bug/237361 It's a trivial man page formatting bug. In the last two and a half years, it has twice received the attentions of Ubuntu developers. Once, two months after I filed it; once, just now. Each time the developer changed some tags. Now, I don't want to downplay the importance of correct tagging of bugs, but, as I said, this is a trivial documentation bug. How about just fixing it? I see this happen again and again. It's sad, because it is not a good use of Ubuntu dev time, and the bug often takes ages to get fixed. I do try, these days, to file such bugs in Debian, where turnaround time tends to be shorter, but, most importantly, busywork is vastly reduced. So, my plea is: when developers have taken the time to look at a bug, it would be great if they would also consider whether it would not be quicker to fix it than simply re-tag it, and then let months or years elapse before they or another developer comes along and spends the time needed to understand the bug report. When code is involved, I understand completely that it will indeed typically take more time, and often, greater expertise, to fix a bug. (Again, Debian wins by having maintainers personally responsible for packages whose code they often get to know reasonably well, and hence are able to spend much less time fixing bugs. Again, I try to use that greater efficiency wherever I can.) But documentation bugs are low-risk fixes, and one is much less likely to get them wrong, so they can usually be fixed quickly. Is there somewhere this could be pointed out to developers? In this case, anyone with an inkling about man page formatting can see the solution; it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Another excellent alternative would be for the Ubuntu developer simply to have forwarded the bug upstream, since it's just the sort of bug report that upstream developers like (easy, user-visible) and like to fix (easy edit, sense of achievement). In penance for writing this email, I will now do just that. -- http://rrt.sc3d.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Busy work
On Fri, Feb 04, 2011 at 12:44:55PM +, Reuben Thomas wrote: Just now, I got a notification about a bug I filed two and a half years ago: https://bugs.launchpad.net/ubuntu/+source/pmount/+bug/237361 It's a trivial man page formatting bug. In the last two and a half years, it has twice received the attentions of Ubuntu developers. Once, two months after I filed it; once, just now. Each time the developer changed some tags. Now, I don't want to downplay the importance of correct tagging of bugs, but, as I said, this is a trivial documentation bug. How about just fixing it? I see this happen again and again. It's sad, because it is not a good use of Ubuntu dev time, and the bug often takes ages to get fixed. I appreciate your frustration and I'm sorry that we don't have time to handle every bug report to everyone's satisfaction. Having said that it you are making an assumption that the people changing tags on this bug report are developers. The Ubuntu community includes more than just developers, there are also bug triagers, documentation writers, translaters and artists just to name a few. Its entirely possible that the person tagging your bug was not a developer and may not be a position to just fix it. -- Brian Murray Ubuntu Bug Master signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Busy work
Reuben Thomas writes: In the last two and a half years, it has twice received the attentions of Ubuntu developers. Once, two months after I filed it; once, just now. Each time the developer changed some tags. [ ... ] it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Including a patch often doesn't help anyway. That just leads to can you make a debdiff rather than a patch? Make a debdiff, and it turns out you should have made a PPA. Make a PPA, and there are further steps. After a while you realize it's a lot less work to maintain your own copy of the package source locally than to keep trying to find the magic steps to get the fix into Ubuntu. (For instance, bugs 553415, which did finally get checked in after a lot of work on many people's parts, and 370735, which is still crashing on startup a year and a half after a patch was posted ... and yes, I should probably learn how to make a debdiff, but I got discouraged seeing how that didn't help in other bugs.) It would help a lot to have a guide -- one that's easy to find, maybe linked from launchpad bug pages so bug reporters can find it -- with a clear explanation of the steps needed. Then have developers actually accept patches that follow those steps. Same with the SRU process: https://wiki.ubuntu.com/StableReleaseUpdates is confusing because steps 1-3 can be done by anyone, then you hit step 4 and ... wait, upload how? is this guide meant only for developers? Also, step 3 says to make a patch, but in at least in bug 553415 it was necessary to make a PPA and get people testing the patch. That's perfectly reasonable -- but it would be great if the guide explained the real steps a bug reporter should go through. ...Akkana -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Busy work
On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote: it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Including a patch often doesn't help anyway. That just leads to can you make a debdiff rather than a patch? Make a debdiff, and it turns out you should have made a PPA. Make a PPA, and there are further steps. After a while you realize it's a lot less work to maintain your own copy of the package source locally than to keep trying to find the magic steps to get the fix into Ubuntu. I don't really consider a debdiff to be a necessary requirement for sponsoring a bug, especially if it is just dropping in a patch touching upstream code. What matters is that the patch is correct and of the required quality. It's not difficult for sponsors to create a package using a patch that a contributor has attached to a bug report (after all, the extra work is normally just creating a changelog entry, which isn't particularly hard). I hope your experience isn't the norm. If we are driving away contributors and turning away good patches because somebody hasn't provided a debdiff, then this makes me both sad and angry. Regards Chris signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Busy work
On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote: Reuben Thomas writes: In the last two and a half years, it has twice received the attentions of Ubuntu developers. Once, two months after I filed it; once, just now. Each time the developer changed some tags. [ ... ] it's 30s of editing. Arguably, my bad for not providing a patch; but again, I thought that would be a waste of time, because it would take longer for me to produce a patch, be sure that it was clean, and applied to the latest version of the package, and then for the developer to apply it, than for the developer simply to edit the man page themselves and produce a package patch. Including a patch often doesn't help anyway. That just leads to can you make a debdiff rather than a patch? Make a debdiff, and it turns out you should have made a PPA. Make a PPA, and there are further steps. Ultimately, the sponsorship and patch review process was broken for a while because of the cadence required of Ubuntu developers to participate. Before, they were asked to spend 1 hour per week sponsoring. This allowed only shallow review, so a user would see exactly that.. a 5 minute oh that patch looks ok, but can you put it in a debdiff? Then the next sponsor would see the debdiff and try it and say it failed here, can you fix problem X and the upload it to a PPA for building?. With the recent change to a patch pilot, you should see a more in-depth review. The developer is working for 4 hours straight on sponsoring patches. So while the spectrum of sponsorship won't be very wide, you should see that a developer has the time to look closely at the patch, and possibly even put it into a debdiff and fix the bug. So I'd say, give patch pilot a chance before damning the old process. After a while you realize it's a lot less work to maintain your own copy of the package source locally than to keep trying to find the magic steps to get the fix into Ubuntu. Its easy to fix a problem for yourself because you have the source, and you have your use case. Its not always easy to fix it in a generic way that will work for most use cases. (For instance, bugs 553415, which did finally get checked in after a lot of work on many people's parts, and 370735, which is still crashing on startup a year and a half after a patch was posted ... and yes, I should probably learn how to make a debdiff, but I got discouraged seeing how that didn't help in other bugs.) It would help a lot to have a guide -- one that's easy to find, maybe linked from launchpad bug pages so bug reporters can find it -- with a clear explanation of the steps needed. Then have developers actually accept patches that follow those steps. This does a fairly good job, maybe we need to make it easier to find? https://wiki.ubuntu.com/SponsorshipProcess Same with the SRU process: https://wiki.ubuntu.com/StableReleaseUpdates is confusing because steps 1-3 can be done by anyone, then you hit step 4 and ... wait, upload how? is this guide meant only for developers? From the linked page, step 4: ...If you can't upload to the archive yourself, get a sponsor, attach a debdiff to the bug and subscribe ubuntu-sponsors, as usual. There is no need to wait before uploading. get a sponsor links to.. https://wiki.ubuntu.com/SponsorshipProcess Also, step 3 says to make a patch, but in at least in bug 553415 it was necessary to make a PPA and get people testing the patch. That's perfectly reasonable -- but it would be great if the guide explained the real steps a bug reporter should go through. SRU's need to be tested widely. Sometimes the simple verification step isn't enough, the sponsor wants things to be even easier to test. In the case above, the fix had a large potential for regression, so it may have harmed testers using the -proposed archive, hence the need for a PPA. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
