Re: Wiki typo on immutable page
Thanks for the fix; there's another one I posted to ubuntu-devel-discuss that you may have missed: "Alternatively, you can disable DRI support in your xorg.conf (see below)." This makes sense in the context (it's talking about crashes caused by 3D screensavers), but the example lower down the page shows how to disable DPMS, not DRI. Since disabling DRI is probably impractical for most users these days (since most default desktops require graphics acceleration), maybe simply remove this sentence? -- 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
Wiki typo on immutable page https://wiki.ubuntu.com/X/Troubleshooting/Freeze
Where it says: "(See MainlineBuilds for installation directions", there is a missing close parenthesis, and only "MainlineBuilds" should be hyperlinked, not the entire contents of the parentheses. -- 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
Where to report bugs in immutable wiki pages? Plus, one such report
I can't find anything on the wiki about where to report errors in immutable pages. The one I'm thinking of is in: https://wiki.ubuntu.com/X/Troubleshooting/Freeze where it says: "Alternatively, you can disable DRI support in your xorg.conf (see below)." This makes sense in the context (it's talking about crashes caused by 3D screensavers), but the example lower down the page shows how to disable DPMS, not DRI. Since disabling DRI is probably impractical for most users these days (since most default desktops require graphics acceleration), maybe simply remove this sentence? -- 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
"Long time no see" auto-text could be improved
I just received, for the n-th time, the following apparently automatic update from a bug report I'd filed: Thanks for the report, it has been some time without any response or feedback in this bug report and we are wondering if this is still an issue for you with the latest release of Ubuntu the Natty Narwhal, May you please test with that version and comment back if you're still having or not the issue? I find this wording rather irritating, because the bit that says "without any response or feedback" implies that I should have done something and didn't. Since the bug in question is not tagged as requiring any sort of info or feedback, that's not the case. Can I suggest that the wording be changed to something like this: Thanks for your bug report; sorry we have not been able to look at it for a while. It's possible that the bug has been fixed; could you please check whether this bug still affects you with the latest Ubuntu release (INSERT_NAME_HERE) and add an appropriate comment to this bug report? By helping us weed out out-of-date bug reports, you can help us spend more time fixing bugs! -- 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
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: Sync Request process questions
On 14 December 2010 19:50, Scott Kitterman wrote: > c. I doesn't need a sync, it needs a merge. It looks like you got caught up > a bit in Ubuntu specific terminology. See > https://wiki.ubuntu.com/UbuntuDevelopment/Merging Ah, I was pointed to the wrong page. Thanks. I would further suggest a simple link from near the top of the other. A merge is after all just a special case of a sync. Thanks! -- 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
Sync Request process questions
Hi, I recently filed an Ubuntu bug making a sync request: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/689025 I got what looks like a cut-and-paste response pointing me to: https://wiki.ubuntu.com/SyncRequestProcess It reads: Please update your bug so it follows the requirements for sync requests: https://wiki.ubuntu.com/SyncRequestProcess Please be aware that the Natty would automatically sync the version from Debian Squeeze if there were no Ubuntu specific changes in the package. The most important thing is therefore to check whether these changes are still needed. I have nothing against cut-and-paste responses per se, they are a useful way to save developer time in common situations. However, I have two problems with this one: 1. Unlike many other excellent automatic responses, this one does not thank me for my bug report. It implies that for anything to be done for my bug report, I have to go and follow the instructions on the page pointed to. But why should I? I have reported the bug, I have not indicated that I am anything other than an ordinary user, why on earth would you think I have the time or indeed the skills needed to triage my own bug report against the criteria on this page? As it happens, I have both the time and the skills, but I still choose not to work on Ubuntu itself; I choose to spend my effort upstream (for example, I helped to make some improvements to sudo recently), and downstream (in this case, reporting this bug). In summary, this automatic response looks rather ungrateful. 2. I went and had a look at the policy page on sync requests, and as the response to my bug report indicates, it mentions more than once that to justify a sync request, it should be proven that Ubuntu-specific changes are no longer needed in the new Debian version of the package. But the trouble is, there are situations such as the present in which they are still needed, and for a good reason: there are differences in policy between Ubuntu and Debian. So, the changes will need to be forward-ported. I can see nothing explicit in the page about this case, though common sense tells me that the Ubuntu-specific patches would need to be triaged. The implications from this are unfortunate: a. We will do nothing unless you prove in detail that the package can be synced to Debian. This implication could be removed by simply making the automatic response to a sync request a little more friendly: "Thank you for your sync request. We'll try to get around to it, but you can help us immensely by following the procedure on this page: ..." b. When there are Ubuntu changes to a Debian package that need to remain in a new version, we won't bother syncing the new version. This is clearly false: there are many packages which are updated, even though Ubuntu-specific changes need to be forward-ported. This implication can be removed by adding instructions to the sync request wiki page on what to do in this circumstance. I hope these suggestions are useful: after getting the initial reply to my bug report I was cross (because my bug report was apparently not valued) and hopeless (because it looked as though unless I did lots of work this package would not be synced), whereas I do not think this is the true picture. Also, I have had no other contact from any Ubuntu developer, even though I posted again to the bug report to explain why I had asked for the package sync, and therefore explain the value of my report. (There is clearly some value in users reporting why it is a good idea to sync a certain package, as it shows both reasons and demand for the newer version, which helps Ubuntu developers to choose which packages to spend time syncing, when the syncing is not automatic.) Overall, so far I feel I have largely wasted my time on this report, which is dispiriting. I feel moved to join and write to ubuntu-devel-discuss because this is not the first time I've had such an experience. I have four main problems with Ubuntu bug reports: 1. They get mechanised. I get cut and paste instructions (not a bad thing in itself), and if I don't do exactly what they say, nothing progresses (which is bad, because it reduces the interaction to a mechanical, programmed one). Often, there is a better way to proceed than simply to follow a standard process. 2. They get overwhelmed by clueless users. I don't know how to fix this, sorry. I suspect it is a necessary price of Ubuntu's greater friendliness to newbies relative to Debian, and of course newbies have to be encouraged, educated, and turned into the next wave of experts. I have this problem less with Debian, and indeed, when it is the right thing to do, I report bugs direct to the Debian BTS. 3. Trying to answer the question "Do I report a bug to Ubuntu, Debian or upstream?" itself costs a lot of time (especially when the answer is that I should report it in two places). I may be missing ways to streamline the process, but it seems it could still use further work. Perhap
