Re: More unhelpful update descriptions
On 6/29/13, T.C. Hollingsworth tchollingswo...@gmail.com Perhaps the real fix here would be to just remove that placeholder text (and double-check that the bodhi CLI rejects updates with blank descriptions)? Personally I just find it really annoying to have to backspace that out and fill in proper information every time I use `fedpkg update`. It would make a lot more sense to me if it were just blank and screamed bloody murder if it's not filled out. Nobody had anything bad (or good) to say about this, so I went ahead and sent a patch to fedpkg that does this: https://fedorahosted.org/fedpkg/ticket/7 Also, I wrote a bodhi patch that rejects updates with the placeholder text, in case fedpkg doesn't get fixed for awhile and so it still gets rejected even with older fedpkgs: https://fedorahosted.org/bodhi/ticket/730 -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 07/10/2013 07:53 PM, Ben Boeckel wrote: On Wed, 03 Jul, 2013 at 04:35:58 GMT, Alex G. wrote: We shouldn't be surprised that update descriptions are crap. They are just an annoyance for a lot of us, especially since we've put all that information in a bunch of other places. Where else would information like the information in this update[1] belong? It doesn't make sense in the spec changelog or the fedora-git changelog. This also isn't from the upstream changelog since it's jumping a version and some of the intermediates are really of little consequence to users. I'm all for tooling, but it won't do everything for you; there's still work involved. You're forgetting the human factor which is, well, forgetting. Or hitting the wrong key by mistake. It's preferable to default to the changelog (spec or git or whatever), than to have a completely unrelated place-holder message. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, 03 Jul, 2013 at 04:35:58 GMT, Alex G. wrote: We shouldn't be surprised that update descriptions are crap. They are just an annoyance for a lot of us, especially since we've put all that information in a bunch of other places. Where else would information like the information in this update[1] belong? It doesn't make sense in the spec changelog or the fedora-git changelog. This also isn't from the upstream changelog since it's jumping a version and some of the intermediates are really of little consequence to users. I'm all for tooling, but it won't do everything for you; there's still work involved. --Ben [1]https://admin.fedoraproject.org/updates/FEDORA-2013-9760/vifm-0.7.5-1.fc19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Tue, Jul 02, 2013 at 09:39:47PM -0700, Adam Williamson wrote: most updates get submitted with the default +3 auto-push, even though it's perhaps not appropriate for all updates. So can we please get a sane default value then that is good for most updates and can be adjusted for special cases (and later per-package)? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-04 2:56, Till Maas wrote: On Tue, Jul 02, 2013 at 09:39:47PM -0700, Adam Williamson wrote: most updates get submitted with the default +3 auto-push, even though it's perhaps not appropriate for all updates. So can we please get a sane default value then that is good for most updates and can be adjusted for special cases (and later per-package)? It would be interesting to make the default 1 or 2 for non-critpath and 3 for critpath... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Thu, Jul 04, 2013 at 02:51:46PM -0700, Adam Williamson wrote: It would be interesting to make the default 1 or 2 for non-critpath and 3 for critpath... +1 Let's do it! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Thu, 2013-07-04 at 18:55 -0400, Matthew Miller wrote: On Thu, Jul 04, 2013 at 02:51:46PM -0700, Adam Williamson wrote: It would be interesting to make the default 1 or 2 for non-critpath and 3 for critpath... +1 Let's do it! Untested, but this should work: http://bochecha.fedorapeople.org/tmp/0001-Set-the-default-stable_karma-to-1.patch -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer m...@zarb.org wrote: Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to Could be, but if the still broken bugs are going to be closed, when the update becomes stable, doesn't really help, or? Given that this is enabled in the update. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Le mercredi 03 juillet 2013 à 09:54 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer m...@zarb.org wrote: Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to Could be, but if the still broken bugs are going to be closed, when the update becomes stable, doesn't really help, or? Given that this is enabled in the update. Then we could decide on : - better process, ie if you happen to notice a bug is not fixed by update, please reopen it - better tooling, ie a way to say do not close this bug to bodhi. Either a message in bodhi, or something on bugzilla side. -- Michael Scherer -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 3 July 2013 08:47, Michael Scherer m...@zarb.org wrote: Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit : On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote: On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to Quoting: If you find an update does not fix a bug it claims to fix, this is not usually a case where you should file negative karma. Only file negative karma if that is the *only* change in the update. If an update claims to fix five bugs, but only fixes four of them, it is not helpful to post negative karma as this may result in the update being rejected, which does not help those suffering from the bug that wasn't fixed, and hurts those suffering from the bugs that are fixed. Tooling issues aside (and it is undesireable that bugs should get marked fixed if they haven't been) I think this rule is wrong under a strict reading. If an update claims to fix two bugs and fixes neither then neither is the *only* change (highlighting is on the guidelines page), yet obviously the rationale for this rule does not apply in that case. Pedantry aside, there is another case: where the update is meant to fix a bug and the maintainer has tried to do this by pulling in an upstream update that might not otherwise have been picked up (e.g. a git hash which has added a feature in the process of fixing the bug). The upstream update might be part of the change, but it was not the purpose of the change. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote: Richard W.M. Jones wrote: %changelog -f changelog_file %changelog -g git_repo And, I suppose: %changelog -s Subversion_repo %changelog -c CVS_repo %changelog -m Monotone_repo %changelog -h Mercurial_repo %changelog -a Arch_repo %changelog -b Bazaar_repo No. Just implementing -f (local file) solves 80% of cases. Git most of the rest. No one cares about other version control systems. %release_notes -f release_notes_file And what would that mean? Should that entire web page be copied into the update announcement? Including stylesheets and images? Or should the update announcement only contain a link to the release notes? No, -f refers to a local file in the package, as it does for all other RPM -f options. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, 2013-07-03 at 09:32 +0200, drago01 wrote: This is also a perfect example of useless does not fix bug x karma. If it is not *worse* then the previous package there is no reason to give it negative karma. Yes, that is a problem too. Particularly so with selinux updates. But getting back to the current concern, the here is where update has now made it to 3 karma and is going to go out to thousands of users. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 07/03/2013 03:12 PM, Richard W.M. Jones wrote: On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote: Richard W.M. Jones wrote: %changelog -f changelog_file %changelog -g git_repo And, I suppose: %changelog -s Subversion_repo %changelog -c CVS_repo %changelog -m Monotone_repo %changelog -h Mercurial_repo %changelog -a Arch_repo %changelog -b Bazaar_repo No. Just implementing -f (local file) solves 80% of cases. Git most of the rest. No one cares about other version control systems. You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for this. At least Mageia and Mandriva have been pulling their rpm changelogs from their dist-vcs for years, see eg https://wiki.mageia.org/en/Packaging_guidelines#Changelogs - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 03, 2013 at 06:21:51PM +0300, Panu Matilainen wrote: On 07/03/2013 03:12 PM, Richard W.M. Jones wrote: On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote: Richard W.M. Jones wrote: %changelog -f changelog_file %changelog -g git_repo And, I suppose: %changelog -s Subversion_repo %changelog -c CVS_repo %changelog -m Monotone_repo %changelog -h Mercurial_repo %changelog -a Arch_repo %changelog -b Bazaar_repo No. Just implementing -f (local file) solves 80% of cases. Git most of the rest. No one cares about other version control systems. You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for this. At least Mageia and Mandriva have been pulling their rpm changelogs from their dist-vcs for years, see eg https://wiki.mageia.org/en/Packaging_guidelines#Changelogs SuSE too ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Am 03.07.2013 09:54, schrieb Johannes Lips: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? Since 2007 or so? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Am 03.07.2013 18:21, schrieb Matthew Miller: On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? Since 2007 or so? what sense makes this? a new upstream-release does not implicitly close any bug on the other hand it makes hardly sense to hold back a update not fixing all bugreports - this all makes no sense for me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, 03 Jul 2013 19:38:00 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 03.07.2013 18:21, schrieb Matthew Miller: On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? Since 2007 or so? what sense makes this? a new upstream-release does not implicitly close any bug on the other hand it makes hardly sense to hold back a update not fixing all bugreports - this all makes no sense for me I think there's a misunderstanding here. Bodhi doesn't do anything at all with bugs that are not attached to an update. How could it? The bugs that are attached to an update are supposed to be fixed by that update. If they are not, you should -1 karma the update and if possible note in the bug that it's not fixed and help provide any info to the maintainer in bug. If the update has some bugs attached, but doesn't fix a bug that is NOT attached, you should NOT -1 karma for that bug not being fixed. It's not expected that it would be. You could note in that bug that the update doesn't fix it, but the maintainer probibly knows that or they would have also attached that bug to the update. Bodhi will (by default, but override able) close any bugs attached to an update when the update goes stable. If you find such a closed but that was not really fixed, reopen it or note to the maintainer in the bug and they can do so. Is that more clear? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Am 03.07.2013 19:54, schrieb Kevin Fenzi: On Wed, 03 Jul 2013 19:38:00 +0200 Reindl Harald h.rei...@thelounge.net wrote: a new upstream-release does not implicitly close any bug on the other hand it makes hardly sense to hold back a update not fixing all bugreports - this all makes no sense for me I think there's a misunderstanding here. Bodhi doesn't do anything at all with bugs that are not attached to an update. How could it? The bugs that are attached to an update are supposed to be fixed by that update. If they are not, you should -1 karma the update and if possible note in the bug that it's not fixed and help provide any info to the maintainer in bug. If the update has some bugs attached, but doesn't fix a bug that is NOT attached, you should NOT -1 karma for that bug not being fixed. It's not expected that it would be. You could note in that bug that the update doesn't fix it, but the maintainer probibly knows that or they would have also attached that bug to the update. Bodhi will (by default, but override able) close any bugs attached to an update when the update goes stable. If you find such a closed but that was not really fixed, reopen it or note to the maintainer in the bug and they can do so. Is that more clear? this makes much more sense thanks! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, Jul 3, 2013 at 7:54 PM, Kevin Fenzi ke...@scrye.com wrote: On Wed, 03 Jul 2013 19:38:00 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 03.07.2013 18:21, schrieb Matthew Miller: On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? Since 2007 or so? what sense makes this? a new upstream-release does not implicitly close any bug on the other hand it makes hardly sense to hold back a update not fixing all bugreports - this all makes no sense for me I think there's a misunderstanding here. Bodhi doesn't do anything at all with bugs that are not attached to an update. How could it? The bugs that are attached to an update are supposed to be fixed by that update. If they are not, you should -1 karma the update and if possible note in the bug that it's not fixed and help provide any info to the maintainer in bug. If the update has some bugs attached, but doesn't fix a bug that is NOT attached, you should NOT -1 karma for that bug not being fixed. It's not expected that it would be. You could note in that bug that the update doesn't fix it, but the maintainer probibly knows that or they would have also attached that bug to the update. No only if this is the only bug there. And even then -1 is questionable ... you should just not that in the bug. -1 means pushing this update is harmful not fixing a bug is not. It might have 5 bug fixes where one of the fix does not fix the problem. What do we gain by not pushing it? -1 for does not fix a bug that is present in the current release is in 99.99% of the cases nonsense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-03 0:54, Johannes Lips wrote: If it doesn't fix the bugs, the update should fix, it is appropriate to give negative karma. Otherwise the bugs would be closed, when it becomes stable, but won't be fixed. That's not what the guidelines say : https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to [2] Could be, but if the still broken bugs are going to be closed, when the update becomes stable, doesn't really help, or? Given that this is enabled in the update. That is a bureaucratic detail that can be fixed. Priority #1 should *always* be pushing out better software: it is wrongheaded to avoid pushing out better software because it would cause a minor inconvenience in our bug tracking system. We should prioritize pushing out the update if it's better than the previous update, and we can deal with re-opening incorrectly closed bugs. If an update *only* claims to fix one bug, and doesn't actually fix it, it is appropriate to give it a -1. But if it claims to fix 10 bugs, fixes 9, but doesn't fix the tenth (and doesn't make anything else worse in a major way, of course) then we really want to push that update out, because it makes things better for people. We can deal with the tenth bug later. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-03 1:11, Michael Scherer wrote: Then we could decide on : - better process, ie if you happen to notice a bug is not fixed by update, please reopen it - better tooling, ie a way to say do not close this bug to bodhi. Either a message in bodhi, or something on bugzilla side. The maintainer can already do this; they can edit the update and remove that bug from the list of 'bugs fixed by this update'. It would be good if, when a maintainer becomes aware an update definitely doesn't fix a bug they thought it did, they could do this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-03 2:28, Ian Malone wrote: Tooling issues aside (and it is undesireable that bugs should get marked fixed if they haven't been) I think this rule is wrong under a strict reading. If an update claims to fix two bugs and fixes neither then neither is the *only* change (highlighting is on the guidelines page), yet obviously the rationale for this rule does not apply in that case. I was kinda hoping people would be able to draw the obvious interpretation there. That page (like just about everything I write...) is too long already, I really don't want to make it any longer. Pedantry aside, there is another case: where the update is meant to fix a bug and the maintainer has tried to do this by pulling in an upstream update that might not otherwise have been picked up (e.g. a git hash which has added a feature in the process of fixing the bug). The upstream update might be part of the change, but it was not the purpose of the change. I'm not sure what conclusion you're drawing here? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-03 8:21, Panu Matilainen wrote: On 07/03/2013 03:12 PM, Richard W.M. Jones wrote: On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote: Richard W.M. Jones wrote: %changelog -f changelog_file %changelog -g git_repo And, I suppose: %changelog -s Subversion_repo %changelog -c CVS_repo %changelog -m Monotone_repo %changelog -h Mercurial_repo %changelog -a Arch_repo %changelog -b Bazaar_repo No. Just implementing -f (local file) solves 80% of cases. Git most of the rest. No one cares about other version control systems. You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for this. At least Mageia and Mandriva have been pulling their rpm changelogs from their dist-vcs for years, see eg https://wiki.mageia.org/en/Packaging_guidelines#Changelogs Right. I think *this* is actually rather more practical than trying to auto-generate update descriptions. I see much more difference between an update description and a package changelog than between a package changelog and a package SCM commit log. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-03 10:54, Kevin Fenzi wrote: On Wed, 03 Jul 2013 19:38:00 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 03.07.2013 18:21, schrieb Matthew Miller: On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote: Could be, but if the still broken bugs are going to be closed, when the update becomes stable since when do bugs get magically closed? Since 2007 or so? what sense makes this? a new upstream-release does not implicitly close any bug on the other hand it makes hardly sense to hold back a update not fixing all bugreports - this all makes no sense for me I think there's a misunderstanding here. Bodhi doesn't do anything at all with bugs that are not attached to an update. How could it? The bugs that are attached to an update are supposed to be fixed by that update. If they are not, you should -1 karma the update and if possible note in the bug that it's not fixed and help provide any info to the maintainer in bug. As discussed up thread, this is not the current policy and I'd really prefer people don't do this. -1 is a Serious Thing, not to be used lightly. If an update claims to fix multiple bugs and *does* fix some of them and doesn't make anything worse, it should be +1ed, not -1ed. If that leads to some bugs that weren't actually fixed being closed, we can re-open them. We should not delay useful fixes going out due to bureaucratic details. (The update submitter can edit the not-fixed bugs out of the update before it goes stable to avoid them being closed, if s/he is paying sufficient attention.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, 03 Jul 2013 12:55:11 -0700 Adam Williamson awill...@redhat.com wrote: As discussed up thread, this is not the current policy and I'd really prefer people don't do this. -1 is a Serious Thing, not to be used lightly. Sorry, you are right. If an update claims to fix multiple bugs and *does* fix some of them and doesn't make anything worse, it should be +1ed, not -1ed. If that leads to some bugs that weren't actually fixed being closed, we can re-open them. We should not delay useful fixes going out due to bureaucratic details. I think the key part here is the 'doesn't make anything worse'. Ie, 10 bugs on a update, 9 of them are fixed, but the one that isn't causes data loss that wasn't present before this update, etc. (The update submitter can edit the not-fixed bugs out of the update before it goes stable to avoid them being closed, if s/he is paying sufficient attention.) Yeah, I agree... just trying to answer too many emails at once. ;( I'd add that you could note _on the bug_ or in a comment on the update (with +0) that whatever bug you see attached to the update that isn't fixed isn't fixed, so the maintainer knows and can remove it from the update or evaluate how bad it is and decide what they want to do. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 3 July 2013 20:48, Adam Williamson awill...@redhat.com wrote: On 2013-07-03 2:28, Ian Malone wrote: Tooling issues aside (and it is undesireable that bugs should get marked fixed if they haven't been) I think this rule is wrong under a strict reading. If an update claims to fix two bugs and fixes neither then neither is the *only* change (highlighting is on the guidelines page), yet obviously the rationale for this rule does not apply in that case. I was kinda hoping people would be able to draw the obvious interpretation there. That page (like just about everything I write...) is too long already, I really don't want to make it any longer. I think the intent is pretty clear, but the wording is slightly contradictory. It could probably be tidied up without making it longer, but exactly how depends on this: Pedantry aside, there is another case: where the update is meant to fix a bug and the maintainer has tried to do this by pulling in an upstream update that might not otherwise have been picked up (e.g. a git hash which has added a feature in the process of fixing the bug). The upstream update might be part of the change, but it was not the purpose of the change. I'm not sure what conclusion you're drawing here? Well in such a case (and I've been in one, quite a while ago), there's a bug (in that case a kernel bug). The maintainer is trying to fix it and produces an update. It doesn't fix the problem, it is technically a newer version that might not have been packaged otherwise. There is a cost to having this pushed out and everyone updating for no benefit. Or maybe more concretely this (picked at random, I'm sure it probably fixes what it's meant to): https://admin.fedoraproject.org/updates/libdrm-2.4.46-1.fc19 (In this case there's no BZ, so it might not have been reported in Fedora.) This pulls an upstream update to fix a bug. In such cases it's probably known that the upstream update does fix the issue. But if it turns out it doesn't when tested then maybe something has gone wrong with the update or the bug wasn't really fixed upstream. It looks pretty clear here since it's listed as a bugfix and a single issue, if you were testing it then you would give it a -1 if it failed to fix qxl cursor bugs. However, if this was kernel 3.9.7 (which doesn't seem to have been packaged, went 3.9.6 - 3.9.8) which had been built as a bugfix for a single bug which it didn't fix should it be -1ed? I'm not really arguing either way, I generally only test packages on bugs I'm subscribed to, but I suspect cases like often rely on some alternate-channel communication between the tester and the maintainer, whether through bugzilla or mailing lists. (Of course in the multiple bugs case I'd just report it on the BZ entry that the update hasn't made an improvement.) -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Wed, 2013-07-03 at 16:33 +0100, Richard W.M. Jones wrote: SuSE too ... Rich. But they reformat everything by hand. For a representative example, compare: https://git.gnome.org/browse/evolution/tree/NEWS with https://build.opensuse.org/package/view_file/openSUSE:Factory/evolution?expand=1file=evolution.changes And every single update has a high-quality description of what specifically has been fixed in that update, completely separate from the RPM log. Aside: the SUSE .changes file is included in the .spec by a macro (% changelog). This makes the .specs themselves about 10x smaller than Fedora .specs, and accordingly much easier to scroll through and work with. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon 01 Jul 2013 05:54:37 PM EDT, Dan Mashal wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan is it possible for not the maintainer to be able to edit the update text of updates? I'm thinking, say, a member of the documentation team? regards, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Hi On Tue, Jul 2, 2013 at 9:42 AM, Ryan Lerch wrote: is it possible for not the maintainer to be able to edit the update text of updates? I'm thinking, say, a member of the documentation team? No but feel free to file a RFE against bodhi https://fedorahosted.org/bodhi/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Hi,
What about the following idea autogenerate update descriptions for most
cases:
* If %{release} is 1, it's an upstream version update. By storing the url
to the upstream changelog (possibly appropriately parametrized with a
%{version} placeholder), bodhi would generate a description such as
This update updates %{name} to version %{version}, for a list of changes,
please consult $url.
* If the bugs field is non-empty in the update-description, bodhi would
generate a description such as
This update fixes the following bugs:
- $bugnr - $bugdescr
- ...
(This text would be appended to the upstream-update text if %{release} is 1)
* If %{release} is 1 and $bugs is empty, the update might be a simple
rebuild because of soname bumps, mass rebuilds, etc. In this cases, the rpm
changelog entries are probably the most informative descriptions, and bodhi
would just copy these for the update description.
Thoughts?
Best,
Sandro
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 01, 2013 at 11:41:48PM +0200, Björn Persson wrote: Richard W.M. Jones wrote: As I think I said pretty clearly, there are two streams of documentation: the detailed changelogs and the release notes (which summarise changes in a human-readable form for a whole release). These should already exist, upstream. No need for them to be duplicated, *if* we had better tooling. Perhaps you would like to write an RFC specifying the Source Code, Changelogs and Release Notes Publishing Protocol and submit it to the IETF, so that there will be a sane way to automatically find and parse those changelogs and release notes? Or do you expect Bodhi to magically find and understand upstream release notes in a gazillion random locations and an unbounded number of formats? Or what exactly do you want the better tooling to do? There's another thread from 1 year ago about this too: https://lists.fedoraproject.org/pipermail/devel/2012-May/thread.html#167184 In brief: %changelog -f changelog_file %changelog -g git_repo %release_notes -f release_notes_file The packager has to do two things (point RPM at the upstream changelog and the release notes), once, and the other tools should work from those forever more. You could extend this later so it parses out specific version information from the release notes, but the above covers about 80% of it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s Subversion_repo
%changelog -c CVS_repo
%changelog -m Monotone_repo
%changelog -h Mercurial_repo
%changelog -a Arch_repo
%changelog -b Bazaar_repo
... and so on, right? And every time someone comes up with a new version
control system, RPM would grow support for a new protocol and a new
changelog format? OK, but what format should it read when the -f option
is used? I'm not aware of a formal standard format for hand-written
changelogs.
What should RPM do if it encounters a parse error in the upstream
changelog? Should it fail to build the package?
%release_notes -f release_notes_file
And what would that mean? Should that entire web page be copied into the
update announcement? Including stylesheets and images? Or should the
update announcement only contain a link to the release notes?
The packager has to do two things (point RPM at the upstream changelog
and the release notes), once, and the other tools should work from
those forever more.
So you expect upstream to keep their release notes in an ever-growing
document at a static URL? Or do you expect them to adhere to a strict
pattern so that you can insert %{version} in the URL? How common are
those approaches? Some projects do release announcements in a blog-like
style without any particular pattern for the URLs.
You could extend this later so it parses out specific version
information from the release notes, but the above covers about 80% of
it.
What language should it parse then? I'm not aware of a formal standard
format for release notes. All you can assume is that it will be some
kind of vaguely HTML-like tag soup. It may even be valid HTML, but HTML
doesn't contain anything that would help you extract the release notes
for a specific version.
Björn Persson
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote: There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan Thanks for pointing it out. I've filed more negative karma against this update, but it needs even more to prevent it from going out. In the interests of avoiding some sort of update description war, let's reserve negative karma only for updates with the placeholder description. Regardless of all else we've discussed, I think (or hope) we all agree that the placeholder text is unacceptable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote: There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan I went through updates-testing looking for placeholder text (and will never be doing that again, it's not fun). Of the 422 updates currently in F19 testing, 12 have the placeholder text as a description: https://admin.fedoraproject.org/updates/FEDORA-2013-12227/youtube-dl-2013.07.02-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12197/skrooge-1.7.1-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12191/libmwaw-0.1.10-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12148/perl-Tapper-4.1.1-2.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11891/mingw-libusbx-1.0.15-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11820/bacula-5.2.13-12.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11668/dvd +rw-tools-7.1-13.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-9454/openstack-quantum-2013.1.1-5.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-7077/salt-api-0.8.1-0.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-6012/dnf-0.3.3-3.git91ba5e0.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-6947/vboot-utils-20130222gite6cf2c2-3.fc19 This one: https://admin.fedoraproject.org/updates/FEDORA-2013-7094/liblangtag-0.5.0-1.fc19 probably should also not be released Some of these have been sitting in testing since April, so a bit of extra delay in resubmitting these updates should be tolerable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 07/01/2013 01:25 PM, Adam Williamson wrote: On 2013-07-01 1:28, Richard W.M. Jones wrote: Since this topic comes up every few months, and no one's pointed out the obvious answer yet, I'll say it: * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * You appear to be missing the contention made by me and others that the update description is not and should not be a simple repetition of any other content. It is not the RPM changelog. It is not the git commit log. It is not the upstream changelog. You can't change human nature: people may forget, people may be uninspired at the moment, etc. Rather than correct(micromanage) the behaviour of masses, it is much easier to accept the behaviour of masses. People do not like to have to deal with RPM changelogs, Fedora SCM (git) commit messages, update descriptions, etc, each with a different set of rules. It is boring and error prone. We shouldn't be surprised that update descriptions are crap. They are just an annoyance for a lot of us, especially since we've put all that information in a bunch of other places. +2 to better tooling Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-02 21:32, Michael Catanzaro wrote: On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote: There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan I went through updates-testing looking for placeholder text (and will never be doing that again, it's not fun). Of the 422 updates currently in F19 testing, 12 have the placeholder text as a description: https://admin.fedoraproject.org/updates/FEDORA-2013-12227/youtube-dl-2013.07.02-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12197/skrooge-1.7.1-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12191/libmwaw-0.1.10-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-12148/perl-Tapper-4.1.1-2.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11891/mingw-libusbx-1.0.15-1.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11820/bacula-5.2.13-12.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-11668/dvd +rw-tools-7.1-13.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-9454/openstack-quantum-2013.1.1-5.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-7077/salt-api-0.8.1-0.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-6012/dnf-0.3.3-3.git91ba5e0.fc19 https://admin.fedoraproject.org/updates/FEDORA-2013-6947/vboot-utils-20130222gite6cf2c2-3.fc19 This one: https://admin.fedoraproject.org/updates/FEDORA-2013-7094/liblangtag-0.5.0-1.fc19 probably should also not be released Some of these have been sitting in testing since April, so a bit of extra delay in resubmitting these updates should be tolerable. I do sometimes wonder if we should have an auto-push for updates that sit in testing for *months*. It's not a dumping ground; if you explicitly don't want an update to go stable for some reason you should probably un-push it until it's ready... By this point it seems to be the case that, realistically, we are never going to reach the auto-push threshold on some updates. And most updates get submitted with the default +3 auto-push, even though it's perhaps not appropriate for all updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 07/01/2013 02:43 PM, Johannes Lips wrote: Richard W.M. Jones wrote: Since this topic comes up every few months, and no one's pointed out the obvious answer yet, I'll say it: * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * Wouldn't it make sense to perhaps apply different rules or policies for different types of packages? I mean we could focus on those applications a regular user sees, like all the Office, Internet and Multimedia apps. And make the rules for libs and all that stuff, normally only devs are interested in, less strict. So we always write update comments with the respective target audience, making them less technical for all the userspace applications and so on. On the other hand, bodhi probably can't distinguish between those two types of packages, or? More rules? Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
* Richard W.M. Jones [01/07/2013 09:28] : * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * Note that you have to describe your update a grand total of once. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote: * Richard W.M. Jones [01/07/2013 09:28] : * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * Note that you have to describe your update a grand total of once. Wrong. It's tiring to have to repeat this, so I'll just point to the last time this came up: https://lists.fedoraproject.org/pipermail/devel/2013-March/thread.html#179655 Especially: https://lists.fedoraproject.org/pipermail/devel/2013-March/179783.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 1, 2013 at 6:44 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote: * Richard W.M. Jones [01/07/2013 09:28] : * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * Note that you have to describe your update a grand total of once. Wrong. It's tiring to have to repeat this, so I'll just point to the last time this came up: https://lists.fedoraproject.org/pipermail/devel/2013-March/thread.html#179655 Especially: https://lists.fedoraproject.org/pipermail/devel/2013-March/179783.html +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 06/29/2013 05:12 PM, T.C. Hollingsworth wrote: I do agree that the RPM changelog is completely useless in the case of most of my packages, and if there is something interesting there it would benefit from a slightly longer description in the update summary rather than some magical automatic inclusion of the RPM changelog. changelogs should contain CVEs of backported security patches RPM changelog is the most accessible record on an installed system. Many environments require accountability for security patching---admins must be able to respond whether they are patched against specific exploits usually given by their CVE number. They can either show that 'we have version 5.5.13 which fixes this bug', or else that the fix was backported---and an RPM changelog listing security fixes by CVE numbers is a very convenient way of proving that. It seems to be a widely used practice, but it is not a formal requirement. I opened a RFE for that to happen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-07-01 1:28, Richard W.M. Jones wrote: Since this topic comes up every few months, and no one's pointed out the obvious answer yet, I'll say it: * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * You appear to be missing the contention made by me and others that the update description is not and should not be a simple repetition of any other content. It is not the RPM changelog. It is not the git commit log. It is not the upstream changelog. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote: You appear to be missing the contention made by me and others that the update description is not and should not be a simple repetition of any other content. It is not the RPM changelog. It is not the git commit log. It is not the upstream changelog. And as far as the tooling is concerned... this is the matter of writing just one extra sentence, so even if we did have awesome technology to write the update description for you from the RPM changelog, and even if it was considered acceptable to present that to users, it's not like that would save a ton of time and effort. I absolutely think there should be at least some minimal level of quality to what we present to users in the default graphical update interface signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Richard W.M. Jones wrote: Since this topic comes up every few months, and no one's pointed out the obvious answer yet, I'll say it: * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * Wouldn't it make sense to perhaps apply different rules or policies for different types of packages? I mean we could focus on those applications a regular user sees, like all the Office, Internet and Multimedia apps. And make the rules for libs and all that stuff, normally only devs are interested in, less strict. So we always write update comments with the respective target audience, making them less technical for all the userspace applications and so on. On the other hand, bodhi probably can't distinguish between those two types of packages, or? Johanens Rich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 01, 2013 at 11:25:51AM -0700, Adam Williamson wrote: On 2013-07-01 1:28, Richard W.M. Jones wrote: Since this topic comes up every few months, and no one's pointed out the obvious answer yet, I'll say it: * Instead of making up more rules, make the tooling better so we don't have to repeat update descriptions in multiple places. * You appear to be missing the contention made by me and others that the update description is not and should not be a simple repetition of any other content. It is not the RPM changelog. It is not the git commit log. It is not the upstream changelog. As I think I said pretty clearly, there are two streams of documentation: the detailed changelogs and the release notes (which summarise changes in a human-readable form for a whole release). These should already exist, upstream. No need for them to be duplicated, *if* we had better tooling. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Richard W.M. Jones wrote: As I think I said pretty clearly, there are two streams of documentation: the detailed changelogs and the release notes (which summarise changes in a human-readable form for a whole release). These should already exist, upstream. No need for them to be duplicated, *if* we had better tooling. Perhaps you would like to write an RFC specifying the Source Code, Changelogs and Release Notes Publishing Protocol and submit it to the IETF, so that there will be a sane way to automatically find and parse those changelogs and release notes? Or do you expect Bodhi to magically find and understand upstream release notes in a gazillion random locations and an unbounded number of formats? Or what exactly do you want the better tooling to do? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 1, 2013 at 2:41 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Perhaps you would like to write an RFC specifying the Source Code, Changelogs and Release Notes Publishing Protocol and submit it to the IETF, so that there will be a sane way to automatically find and parse those changelogs and release notes? Or do you expect Bodhi to magically find and understand upstream release notes in a gazillion random locations and an unbounded number of formats? Or what exactly do you want the better tooling to do? I'm pretty sure there is a Bodhi 2.0 in the works, as noted by the list of talks for Flock, hopefully this will take care of that. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
Le lundi 01 juillet 2013 à 14:01 -0500, Michael Catanzaro a écrit : On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote: You appear to be missing the contention made by me and others that the update description is not and should not be a simple repetition of any other content. It is not the RPM changelog. It is not the git commit log. It is not the upstream changelog. And as far as the tooling is concerned... this is the matter of writing just one extra sentence, so even if we did have awesome technology to write the update description for you from the RPM changelog, and even if it was considered acceptable to present that to users, it's not like that would save a ton of time and effort. Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt Pierre-Yves -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote: Not sure if it makes any sense but maybe could we have something like freeze tag changes until desc is better. I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like not pushed to stable until desc is better I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 2:44 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. This one seems to happen for every selinux update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Fri, Jun 28, 2013 at 17:52:16 -0700, Adam Williamson awill...@redhat.com wrote: I've suggested before that Bodhi should reject any update with an empty description or with the placeholder text as the description. That would be really helpful. I think it does now. I forgot to add a note when rushing one of the spin-kickstarts updates and bodhi didn't work and reminded me to add the note. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Fri, Jun 28, 2013 at 07:44:22PM -0500, Michael Catanzaro wrote: We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. If the update fixes a bug which is properly mentioned in the bugs field, why does this fact need to be mentioned again in the update notes? It should be obvious that an update fixing a bug is worth pushing out. Also instead of writing policy, better make Bodhi allow to easier write good update notes, e.g. by using/including the upstream, RPM or GIT changelog, so it can be easily used if it already contains the necessary information. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote: On Fri, Jun 28, 2013 at 17:52:16 -0700, Adam Williamson awill...@redhat.com wrote: I've suggested before that Bodhi should reject any update with an empty description or with the placeholder text as the description. That would be really helpful. I think it does now. I forgot to add a note when rushing one of the spin-kickstarts updates and bodhi didn't work and reminded me to add the note. But just yesterday I got an update with the placeholder text. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, 2013-06-29 at 16:08 +0200, Till Maas wrote: If the update fixes a bug which is properly mentioned in the bugs field, why does this fact need to be mentioned again in the update notes? It should be obvious that an update fixing a bug is worth pushing out. Also instead of writing policy, better make Bodhi allow to easier write good update notes, e.g. by using/including the upstream, RPM or GIT changelog, so it can be easily used if it already contains the necessary information. Regards Till Since a PackageKit update a month or two ago, if the description field is left blank then PackageKit will show the top of the RPM changelog after the message The developer logs will be shown as no update information is available or something along those lines. (Previously it just used to say No update information available.) So the functionality for that is in place signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 09:39:01 -0500, Michael Catanzaro mike.catanz...@gmail.com wrote: On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote: On Fri, Jun 28, 2013 at 17:52:16 -0700, Adam Williamson awill...@redhat.com wrote: I've suggested before that Bodhi should reject any update with an empty description or with the placeholder text as the description. That would be really helpful. I think it does now. I forgot to add a note when rushing one of the spin-kickstarts updates and bodhi didn't work and reminded me to add the note. But just yesterday I got an update with the placeholder text. I don't normally turn javascript on. Maybe that makes a difference. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Fri, 28 Jun 2013 19:44:22 -0500, Michael Catanzaro wrote: There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. Somewhat glad you've opened a thread about it. Not sure it can be fixed within bodhi. Whatever bodhi may implement to force people to enter Details, some people will cheat. Here's a hero: https://admin.fedoraproject.org/updates/FEDORA-2013-8239/libwpd-0.9.8-1.fc19 | You do not need to know what changed. https://admin.fedoraproject.org/updates/FEDORA-2013-8247/libmspub-0.0.6-1.fc19 | Fixes some bugs. Or maybe not. https://admin.fedoraproject.org/updates/libodfgen-0.0.1-1.fc19 | !!!IMPORTANT! UPDATE IMMEDIATELY!1! This update adds a new package to Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-8444/libcdr-0.0.14-1.fc19 | This libcdr update updates the libcdr. https://admin.fedoraproject.org/updates/FEDORA-2013-7489/libreoffice-4.0.3.3-1.fc19 | This is the latest shiniest LibreOffice. It is perfect--if you | experience any problem, it is on your side. This update was brought | to you by the Fedora LibreOffice team. https://admin.fedoraproject.org/updates/FEDORA-2013-7392/libmwaw-0.1.8-1.fc19 | Seriously, if I tell you what this update does, where is the surprise? https://admin.fedoraproject.org/updates/FEDORA-2013-7101/liblangtag-0.5.1-1.fc19 | I do have to write something here, do I? https://admin.fedoraproject.org/updates/FEDORA-2013-6969/libwpg-0.2.2-1.fc18 | I am bored... What if I submitted an update for something or other? https://admin.fedoraproject.org/updates/FEDORA-2013-7013/libwps-0.2.8-1.fc18 | This is one of the strong, silent updates. There are many more. Some are almost funny. I just hope we agree on how to present Updates to the user community. No further comment. -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.6-301.fc19.x86_64 loadavg: 0.07 0.03 0.05 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-06-29 7:08, Till Maas wrote: On Fri, Jun 28, 2013 at 07:44:22PM -0500, Michael Catanzaro wrote: We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. If the update fixes a bug which is properly mentioned in the bugs field, why does this fact need to be mentioned again in the update notes? It should be obvious that an update fixing a bug is worth pushing out. Also instead of writing policy, better make Bodhi allow to easier write good update notes, e.g. by using/including the upstream, RPM or GIT changelog, so it can be easily used if it already contains the necessary information. The upstream, RPM or git changelog is never a good update description. An update description should be a very clear high-level description of what the update does. The audience is a normal end-user who has 300 updates to apply and wants to know what they do. This person is not going to spend six hours reading changelogs. This update simply fixes the bugs listed is an okay description - it tells the reader what they need to know and re-assures them that the update doesn't do anything *else*. Of course, if it does, you need to explain that: This update includes a new upstream release which fixes the bugs listed. You can find other changes in the upstream description at http://www.blahblah.foo;. I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-06-29 10:04, Michael Schwendt wrote: There are many more. Some are almost funny. I just hope we agree on how to present Updates to the user community. No further comment. OK, I propose a new rule: if you want to do a joke update description, it has to be as funny as Spot's. If you can't make it as funny as one of spot's, you damn well write a proper serious one. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 1:07 PM, Adam Williamson awill...@redhat.com wrote: I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. Well, this is what I do for nodejs updates. I figure since that's good enough for all the people who install .EXEs and .DMGs then it's good enough for people installing Fedora RPMs too, right? Otherwise all I could think of to put there would be: This fixes some random bugs. Visit http://nodejs.org/path/to/changelog/ to see what they are. I think just including the list of fixes from upstream instead of forcing them to go to a link to see the same list of ~3 fixes is a lot nicer. But, the changelogs I put there are pretty short and sweet [1] (as befitting the stable branch of a programming language interpreter). Perhaps you are thinking of ridiculously long git changelogs or something? I do agree that the RPM changelog is completely useless in the case of most of my packages, and if there is something interesting there it would benefit from a slightly longer description in the update summary rather than some magical automatic inclusion of the RPM changelog. -T.C. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-11337/libuv-0.10.11-1.fc19,nodejs-0.10.12-1.fc19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 8:10 AM, Bruno Wolff III br...@wolff.to wrote: On Sat, Jun 29, 2013 at 09:39:01 -0500, Michael Catanzaro mike.catanz...@gmail.com wrote: On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote: I think it does now. I forgot to add a note when rushing one of the spin-kickstarts updates and bodhi didn't work and reminded me to add the note. But just yesterday I got an update with the placeholder text. I don't normally turn javascript on. Maybe that makes a difference. I think the difference here is the web interface vs. `fedpkg update`. Both will probably yell at you if the field is just blank, and that's the default for the web interface, but `fedpkg update` includes some placeholder text which it will happily pass on through if you don't change it. Perhaps the real fix here would be to just remove that placeholder text (and double-check that the bodhi CLI rejects updates with blank descriptions)? Personally I just find it really annoying to have to backspace that out and fill in proper information every time I use `fedpkg update`. It would make a lot more sense to me if it were just blank and screamed bloody murder if it's not filled out. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote: The upstream, RPM or git changelog is never a good update description. An update description should be a very clear high-level description of what the update does. The audience is a normal end-user who has 300 updates to apply and wants to know what they do. This person is not going to spend six hours reading changelogs. This update simply fixes the bugs listed is an okay description - it tells the reader what they need to know and re-assures them that the update doesn't do anything *else*. Of course, if it does, you need to explain that: This update includes a new upstream release which fixes the bugs listed. You can find other changes in the upstream description at http://www.blahblah.foo;. For this update description, no human intervention is required, because it can be created automatically. If the person reading the notice wants to know what the update does, there is no way around reading changelogs, because they contain this information. If he or she just wants some comforting words, then the GUI or update framework can generate them just automatically. I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. I only read update changelogs if I want to provide karma and am wondering if there is anything special that I should test, therefore I do not see any value at all in the update description. Maybe more examples of good update description would help. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-06-29 14:20, Till Maas wrote: On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote: The upstream, RPM or git changelog is never a good update description. An update description should be a very clear high-level description of what the update does. The audience is a normal end-user who has 300 updates to apply and wants to know what they do. This person is not going to spend six hours reading changelogs. This update simply fixes the bugs listed is an okay description - it tells the reader what they need to know and re-assures them that the update doesn't do anything *else*. Of course, if it does, you need to explain that: This update includes a new upstream release which fixes the bugs listed. You can find other changes in the upstream description at http://www.blahblah.foo;. For this update description, no human intervention is required, because it can be created automatically. If the person reading the notice wants to know what the update does, there is no way around reading changelogs, because they contain this information. If he or she just wants some comforting words, then the GUI or update framework can generate them just automatically. I was intentionally covering two of the simplest kinds of updates, for a *lazy* maintainer. I'd consider those bare minimums. I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. I only read update changelogs if I want to provide karma and am wondering if there is anything special that I should test, therefore I do not see any value at all in the update description. Maybe more examples of good update description would help. Here's the kind of update descriptions I usually write. I don't know if anyone *else* considers them good, of course :) https://admin.fedoraproject.org/updates/FEDORA-2013-11724/liveusb-creator-3.11.8-3.fc19 : This update adds a dependency on usermode-gtk to make the application launch correctly from system menus. https://admin.fedoraproject.org/updates/FEDORA-2013-11688/bijiben-3.8.3-1.fc19 : This update gives Bijiben an icon which is more clearly related to its function, and makes its name in the menu system simply 'Notes', which again makes its function much clearer. https://admin.fedoraproject.org/updates/FEDORA-2013-11530/congruity-17-2.fc19,concordance-1.0-1.fc19,libconcord-1.0-2.fc19 : This update provides the latest versions of the libconcord, concordance and congruity packages that together provide support for Logitech Harmony remote controls. This update fixes many bugs and provides support for many remotes introduced in the last few years. The congruity package now includes an 'mhgui' tool for configuring remotes that only work through the new Silverlight-based myharmony.com site. https://admin.fedoraproject.org/updates/FEDORA-2013-11463/fedora-release-19-2 : This update applies all the usual changes when going from pre-release to release: updates-testing repository is disabled, repo metadata is set to expire after seven days, etc. It is required for the final release of Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-11265/roundcubemail-0.9.2-1.fc19 : This update provides the latest upstream version of roundcube, a minor release with various bug fixes. It appears to require no database or configuration update from version 0.9.0, should simply be a drop-in. See http://trac.roundcube.net/wiki/Changelog for the full changelog. Note that the License field on the package has been updated to be more accurate: see https://lists.fedoraproject.org/pipermail/devel/2013-June/184197.html for full details. https://admin.fedoraproject.org/updates/FEDORA-2013-10293/system-config-keyboard-1.3.1-14.fc19 : With many thanks to Vratislav Podzimek, who wrote the fix, this update fixes system-config-keyboard to read and write the keyboard layout configuration via systemd-localed - and so makes it actually work again. Previously, it would set the layout for the current X session but it would not write the configuration correctly, so the change would not survive a reboot. Note that system-config-keyboard reads and sets the system-wide keyboard layout. If you are using GNOME, your user session has its own keyboard layout configuration that overrides the system-wide configuration and can be set through the GNOME control center. If you are using KDE, you can choose to either use the system-wide configuration or use a KDE-specific configuration in the control center. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 30/06/13 03:15, Adam Williamson wrote: On 2013-06-29 14:20, Till Maas wrote: On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote: The upstream, RPM or git changelog is never a good update description. An update description should be a very clear high-level description of what the update does. The audience is a normal end-user who has 300 updates to apply and wants to know what they do. This person is not going to spend six hours reading changelogs. This update simply fixes the bugs listed is an okay description - it tells the reader what they need to know and re-assures them that the update doesn't do anything *else*. Of course, if it does, you need to explain that: This update includes a new upstream release which fixes the bugs listed. You can find other changes in the upstream description at http://www.blahblah.foo;. For this update description, no human intervention is required, because it can be created automatically. If the person reading the notice wants to know what the update does, there is no way around reading changelogs, because they contain this information. If he or she just wants some comforting words, then the GUI or update framework can generate them just automatically. I was intentionally covering two of the simplest kinds of updates, for a *lazy* maintainer. I'd consider those bare minimums. I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. I only read update changelogs if I want to provide karma and am wondering if there is anything special that I should test, therefore I do not see any value at all in the update description. Maybe more examples of good update description would help. Here's the kind of update descriptions I usually write. I don't know if anyone *else* considers them good, of course :) https://admin.fedoraproject.org/updates/FEDORA-2013-11724/liveusb-creator-3.11.8-3.fc19 : This update adds a dependency on usermode-gtk to make the application launch correctly from system menus. https://admin.fedoraproject.org/updates/FEDORA-2013-11688/bijiben-3.8.3-1.fc19 : This update gives Bijiben an icon which is more clearly related to its function, and makes its name in the menu system simply 'Notes', which again makes its function much clearer. https://admin.fedoraproject.org/updates/FEDORA-2013-11530/congruity-17-2.fc19,concordance-1.0-1.fc19,libconcord-1.0-2.fc19 : This update provides the latest versions of the libconcord, concordance and congruity packages that together provide support for Logitech Harmony remote controls. This update fixes many bugs and provides support for many remotes introduced in the last few years. The congruity package now includes an 'mhgui' tool for configuring remotes that only work through the new Silverlight-based myharmony.com site. https://admin.fedoraproject.org/updates/FEDORA-2013-11463/fedora-release-19-2 : This update applies all the usual changes when going from pre-release to release: updates-testing repository is disabled, repo metadata is set to expire after seven days, etc. It is required for the final release of Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-11265/roundcubemail-0.9.2-1.fc19 : This update provides the latest upstream version of roundcube, a minor release with various bug fixes. It appears to require no database or configuration update from version 0.9.0, should simply be a drop-in. See http://trac.roundcube.net/wiki/Changelog for the full changelog. Note that the License field on the package has been updated to be more accurate: see https://lists.fedoraproject.org/pipermail/devel/2013-June/184197.html for full details. https://admin.fedoraproject.org/updates/FEDORA-2013-10293/system-config-keyboard-1.3.1-14.fc19 : With many thanks to Vratislav Podzimek, who wrote the fix, this update fixes system-config-keyboard to read and write the keyboard layout configuration via systemd-localed - and so makes it actually work again. Previously, it would set the layout for the current X session but it would not write the configuration correctly, so the change would not survive a reboot. Note that system-config-keyboard reads and sets the system-wide keyboard layout. If you are using GNOME, your user session has its own keyboard layout configuration that overrides the system-wide configuration and can be set through the GNOME control center. If you are using KDE, you can choose to either use the system-wide configuration or use a KDE-specific configuration in the control center. Adam, I've been trying to put more time into improving my own update messages, so thanks for these examples! It's important to put yourself in the shoes of the user. Does the user have enough information to: 1) determine the nature of the changes? 2) determine how major the changes are? 3) make a relatively
More unhelpful update descriptions
There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. Now the first one is obviously a one-off mistake, but had the update been checked over just once it would have been caught. The placeholder one is a big recurring problem, though: it seems to show up at least every week or so, which is not OK. And once, about two months ago -- I really should have complained then and not now -- an update was pushed where the text displayed in PackageKit was something along the lines of why do I have to describe my update here when I've already filled out the RPM changelog. I wish it was a joke, but something like that was actually pushed as the description of a F18 update presented to every user who glances over the updates We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. Happy Friday, Michael Catanzaro [1] https://lists.fedoraproject.org/pipermail/devel/2013-March/179655.html signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-06-28 17:44, Michael Catanzaro wrote: There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. Now the first one is obviously a one-off mistake, but had the update been checked over just once it would have been caught. The placeholder one is a big recurring problem, though: it seems to show up at least every week or so, which is not OK. And once, about two months ago -- I really should have complained then and not now -- an update was pushed where the text displayed in PackageKit was something along the lines of why do I have to describe my update here when I've already filled out the RPM changelog. I wish it was a joke, but something like that was actually pushed as the description of a F18 update presented to every user who glances over the updates We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. I've suggested before that Bodhi should reject any update with an empty description or with the placeholder text as the description. That would be really helpful. Frankly I would suggest filing negative karma on the why do I have to... description you mentioned. I agree that it's simply not acceptable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - On 03/14/2013 05:02 PM, Rahul Sundaram wrote: On 03/14/2013 04:33 PM, Przemek Klosowski wrote: I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. When patches are backported, typically the changelog would cover the reason for doing so but not necessarily when a new update fixes a bunch of issues and security issue happens to be one of them. In some cases, there is no CVE id assigned for the problem either but if you want to request that packaging guidelines recommend this in the general case, file it at https://fedorahosted.org/fpc/ OK, let's see whether others like it too: https://fedorahosted.org/fpc/ticket/267 It's really not as easy as it sounds like as it depends also on how upstream's deal with CVEs and believe me (as I was a part of WebKit upstream security team) - it's a mess. So by requiring such information, users could expect it it's an authoritative source they can trust - but it will never be. For patches or minor update with known CVE, I always include it. For the rest, not sure there's even chance to know what's within the tarball. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Debarshi Ray wrote: It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. We cannot push new versions of a library when the users of the library are not ready for it yet (especially one of our release-blocking desktops). So maybe we should just ship code right from the Git masters of all upstreams? No. I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Yes, of course! It's common QA knowledge that small isolated changes can be tested much better than a huge batch of unrelated changes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Debarshi Ray wrote: It is a bit strange that we freeze before the release, and then move on to a Rawhide like environment where anything can be pushed by anybody at any point in time. And the answer to that is to find a way to drop or relax the release freezes. (I'd suggest to have Bodhi distinguish between 3 targets instead of 2 in pre-release freeze periods: testing, stable (0-day updates) and freeze_override. Then stable would be open for pushes just like after the release, and freeze_override would be controlled as stable is now (and updates pending approval for freeze_override would automatically get pushed to stable in the meantime).) That would help solving a lot of problems, including but not limited to upgrade path issues around release day. We have been working around this by semi-formally co-ordinating all GNOME updates to stable releases. We're doing the same for KDE updates, but for a simple reason: upstream releases the packages at the same time and users are expected to use matching versions, so it wouldn't make sense to split things. Updating a coherent stack that is released by upstream as such in one batch makes a lot of sense, of course. But IMHO, that approach doesn't make much (if any) sense if the upstream releases are not coordinated. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Jaroslav Reznik wrote: Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. That's a result of the karma system. Most people have just given up trying to push updates to Fn-1 because they never get any karma. The people enthousiastic about giving karma are all running Fn or even Fn+1 (Branched). Even for (sets of) packages which do get tested (e.g. the KDE 4.10.1 update group), one has to send mail to mailing lists to remind people to give karma. Many maintainers are fed up of having to beg for karma each time and so just give up supporting the release. This is the same phenomenon that killed Fedora Legacy. We need to get rid of karma and put power (and trust!) back into the hands of the maintainers, and Fn-1 will florish again! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 05:02 PM, Rahul Sundaram wrote: On 03/14/2013 04:33 PM, Przemek Klosowski wrote: I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. When patches are backported, typically the changelog would cover the reason for doing so but not necessarily when a new update fixes a bunch of issues and security issue happens to be one of them. In some cases, there is no CVE id assigned for the problem either but if you want to request that packaging guidelines recommend this in the general case, file it at https://fedorahosted.org/fpc/ OK, let's see whether others like it too: https://fedorahosted.org/fpc/ticket/267 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 14/03/13 02:43 AM, Jaroslav Reznik wrote: That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. I've argued somewhat down this line before, but you're taking it _way_ too far. I've been running my entire domain on Fn-1 for three years and it works fine, and I get all the appropriate security updates. It is a thing that works, please don't dismiss it. I snipped the rest of your mail, but I think you're being way too negative. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, Mar 14, 2013 at 2:43 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. So maybe we should just ship code right from the Git masters of all upstreams? I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpH76gJyleNb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Wed, 2013-03-13 at 14:26 -0600, Kevin Fenzi wrote: On Wed, 13 Mar 2013 20:20:01 + Debarshi Ray rishi...@lostca.se wrote: ...snip... I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Spot had a plan related to this. basically bundle up monthly updates to all critpath (non security) stuff, QA it, and then push it out as a bundle. I see one problem with this approach: we're bound to have some update slipping into stable which breaks something that isn't caught in testing. If we do something like that, there needs to be a fast lane for updates fixing such broken updates so people don't have to wait a month for the fix. Unless... People using yum/other tools directly could keep doing whatever they currently do. ...this means that these bundles mean something additional to the normal repositories. I don't know about Spot's plan you mentioned, where can I find information about it? Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, Mar 14, 2013 at 11:53 AM, Debarshi Ray rishi...@lostca.se wrote: RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. First even if broken is a pretty extreme interpretation of First. First working is much better - and it fits with the purpose of a distribution, to make sure that the various pieces are integrated together (and to help upstream make it happen if necessary). I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Separate updates to individual packages have don't set up so high expectations. An update to a package implies that 1) (optionally) upstream released it and is happy with the quality, and 2) a Fedora packager has used it and is happy with the quality of a package. A update bundle implies the weight of the whole project behind the bundle. Where are the people signing up to do the extra work to achieve this higher level of quality? As it is, many individual packages don't get any testing; if nothing changes, the individual packages still won't get any testing, and the bundle won't be tested any more than the individual packages either. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Dne 14.3.2013 10:43, Jaroslav Reznik napsal(a): - Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav It seems to be that you contradict to what update policy suggest [1]. Let me quote: we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time. I read it in short as no updates except bugfixes. So if Fn-1 is almost dead, it is by Fedora policy, not by non-willingness. For me, it is fine to do one update to Fn+1 every half year and then just get bugfixes. And I believe it is pretty sensible. Vít [1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Wed, 2013-03-13 at 22:49 +0100, Kevin Kofler wrote: So did I, and I think his proposal is an awful idea. (Unfortunately, question time at DevConf is always very short, so I didn't get to voice my disapproval in the talk.) We are not Window$ (think patch Tuesday) nor RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! I also don't think such huge batches can realistically be tested. Kevin Kofler Well this is a really easy one to solve; update bundling probably isn't necessary. Already PackageKit has a setting to control how often it checks for updates: hourly, daily (default), or weekly. Just add a monthly option, and change the default to something more sane than daily (weekly sounds like a better default than daily or monthly?); people who want faster updates can still get them (not the case if you start holding updates). That should be really simple. Alternatively, add a new setting for security updates so that those come daily by default while other updates are weekly (or monthly or annually or whatever) by default; not sure how much work that would be, but PackageKit already distinguishes between security and nonsecurity updates. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote: How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan I think you'd find plenty of support for that idea iff GNOME switched to 8 months as well. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thursday, March 14, 2013 10:24 PM, Michael Catanzaro wrote: On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote: How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan I think you'd find plenty of support for that idea iff GNOME switched to 8 months as well. I think his suggestion was to keep releasing every 6 months (as we do now, loosely synchronized with the GNOME schedule), but support each release only 8 months instead of 13. I, for one, would be very much in favour of that. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/12/2013 09:42 PM, Rahul Sundaram wrote: On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 11:34 AM, Przemek Klosowski wrote: Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? I wouldn't say it is for packaging *only* and CVE info is not consistently listed in the changelog anyway and a good replacement might be to just search CVE id in https://admin.fedoraproject.org/updates Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 14/03/13 08:34 AM, Przemek Klosowski wrote: On 03/12/2013 09:42 PM, Rahul Sundaram wrote: On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? I don't think you can rely on it anyway. I'd expect the CVE to show up in the changelog any time a package update was rolled specifically to backport one or a group of CVE fixes as patches - as that's effectively a packaging change - but not necessarily if an upstream point release included some CVE fixes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 11:47 AM, Rahul Sundaram wrote: On 03/14/2013 11:34 AM, Przemek Klosowski wrote: Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? I wouldn't say it is for packaging *only* and CVE info is not consistently listed in the changelog anyway and a good replacement might be to just search CVE id in https://admin.fedoraproject.org/updates I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. The bodhi search is cool, thanks for pointing out that it can search by CVE. The downside is that it only seems to have recent data: many well-known CVEs don't show up. I had an impression that 2011 and later CVEs are covered but previous ones are not. I recognize this is not Fedora's problem but I'd argue that the entire RPM ecosystem is better off when important security info resided right there with the package. Fedora can tell people to just upgrade to the latest, but that may not be the best thing for other more long-term-support RPM-based systems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 04:33 PM, Przemek Klosowski wrote: I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. When patches are backported, typically the changelog would cover the reason for doing so but not necessarily when a new update fixes a bunch of issues and security issue happens to be one of them. In some cases, there is no CVE id assigned for the problem either but if you want to request that packaging guidelines recommend this in the general case, file it at https://fedorahosted.org/fpc/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
First even if broken is a pretty extreme interpretation of First. First working is much better - and it fits with the purpose of a distribution, to make sure that the various pieces are integrated together (and to help upstream make it happen if necessary). There is no way you can test a constantly changing pool of software packages. As a tester or developer you test a combination X, but you have no way of knowing that an end-user will get the same combination because some other packager somewhere else has pushed an update to another package which might completely invalidate your test. Then again different mirrors in different parts of the world can be syncing at different rates or at different points of time. Which means that different people are being fed randomly different sets of packages. How do I know that the webkitgtk3 that was pushed works with the version of libsoup or gtk3 that is in the repository? I can't because a new libsoup or gtk3 package might have been built while my webkitgtk3 package was still building. Hence this combination of libsoup, gtk3 and webkitgtk3 that we feed the user is totally untested Rawhide quality code. This is why we have freezes. So that we can let things settle down. So that we are reasonably sure that all testers and developers are testing the same set of packages. So that we have sufficient time for testing the whole system. So that we are sure that all users are fed the same set of packages that we tested. It is a bit strange that we freeze before the release, and then move on to a Rawhide like environment where anything can be pushed by anybody at any point in time. We have been working around this by semi-formally co-ordinating all GNOME updates to stable releases. Like all workarounds it is not ideal. We still get bitten by random packager pushing random update that broke a stable distro, or by an update to a package much lower down the stack (say gnutls) that ended up breaking things elsewhere (say telepathy-gabble). Happy hacking, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpHl_HLeElQH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
I see one problem with this approach: we're bound to have some update slipping into stable which breaks something that isn't caught in testing. If we do something like that, there needs to be a fast lane for updates fixing such broken updates so people don't have to wait a month for the fix. Unless... Yes, ofcourse. To me the idea is loosely analogous to having freezes before a release, and there is always the possibility of freeze breaks, exceptions and what not. I don't know about Spot's plan you mentioned, where can I find information about it? https://www.youtube.com/watch?v=xCE4dBCowRk Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpqK6FBAxruy.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
From: Rahul Sundaram methe...@gmail.com On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. I see both sides of this argument. When I have my admin hat on, I really don't want to have to consult bodhi, which requires a net connection when I could simply do an 'rpm -q --changelog foo'. However, with my dev hat on, I can see the argument the other way. In my local packaging, my rpm changelogs are a mixture. If V is bumped the changelog describes the diffs between the new V and the old V. If R is bumped, the changelog most likely describes something that changed in the spec only. That's me and what I feel is proper (for local packaging) though. However, I would strongly suggest that if Fedora policy is to have the rpm changelog only cover R changes and not V changes, let's please amend this bit to make it much more explicit and clear to the reader, perhaps even providing the bodhi URL: man rpm(8) PACKAGE QUERY OPTIONS: --changelog Display change information for the package. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - On 03/12/2013 10:18 PM, Michael Catanzaro wrote: Again, I'm disappointed in seeing that placeholder text in stable updates. Clearly that plan failed---it'd be nice if Bodhi could become smart enough to reject updates with the placeholder description. I have filed a request on your behalf https://fedorahosted.org/bodhi/ticket/718 Thanks! And definitely +1. Jaroslav Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, 2013-03-11 at 18:20 -0700, Adam Williamson wrote: The discussion seems to have branched out a bit, but going back to Michael's original mail, he's clearly onto something. It should not be too hard for Bodhi to reject: * Entirely empty update descriptions * An update description which is simply the placeholder text and I can't see any reason why we shouldn't just do that. Luke, could we make it so? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net This sounds good. It seems like there's some contention as to the proper level of detail in update descriptions, and that's fine, but I think we all agree that these two cases are not acceptable. Thanks! Michael Catanzaro signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, 2013-03-12 at 22:29 -0400, Rahul Sundaram wrote: On 03/12/2013 10:18 PM, Michael Catanzaro wrote: Again, I'm disappointed in seeing that placeholder text in stable updates. Clearly that plan failed---it'd be nice if Bodhi could become smart enough to reject updates with the placeholder description. I have filed a request on your behalf https://fedorahosted.org/bodhi/ticket/718 Rahul OK; so many messages on this list that's it's hard to follow everything in the proper order. Thanks Rahul! signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. A meaningful update message makes sense if we want each user to read them through. And if you want each user to do so, then you better write a %changelog that is much more understandable than the upstream ChangeLog because every random user will not be able to make sense of the jargon. I am sure most developers won't be able to understand, unless they are initimately familiar with the project. So you will have to spend significant time writing the text. I would suggest that we keep updates to a minimum, that we audit them so that random version bumps don't get pushed to stable releases, and we ship them in time based batches (eg., monthly or bi-monthly, etc.). Once we do that we will be able to ensure that they are of sufficient quality. At that point one will not want to read the %changelog for each package to satisfy herself of the need to update it. You get batches of well tested updates at specified intervals of time, and you just apply them without getting annoyed or being suspicious. I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpDG2M3g0vCO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Wed, 13 Mar 2013 20:20:01 + Debarshi Ray rishi...@lostca.se wrote: ...snip... I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Spot had a plan related to this. basically bundle up monthly updates to all critpath (non security) stuff, QA it, and then push it out as a bundle. People using yum/other tools directly could keep doing whatever they currently do. Other folks who don't care about updates so much could just apply them monthly, and have some assurance that they didn't break things. As part of that plan there could be a release notes for the monthly update bundle that was shorter and more useful than the changelog of a bunch of things. Security updates would of course keep flowing all the time. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Spot had a plan related to this. basically bundle up monthly updates to all critpath (non security) stuff, QA it, and then push it out as a bundle. Yes, I attended his talk at devconf.cz where he mentioned this. :-) I had often mentioned this in person to others, and was really glad that Spot brought it up. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgp9hv8jZ9UcY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Debarshi Ray wrote: Yes, I attended his talk at devconf.cz where he mentioned this. :-) So did I, and I think his proposal is an awful idea. (Unfortunately, question time at DevConf is always very short, so I didn't get to voice my disapproval in the talk.) We are not Window$ (think patch Tuesday) nor RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! I also don't think such huge batches can realistically be tested. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, Mar 11, 2013 at 10:37 PM, Rahul Sundaram methe...@gmail.com wrote: On 03/12/2013 01:30 AM, Dan Mashal wrote: Semantics. Providing a link is helpful to users isn't semantics. You as a package maintainer would be aware of where to look for reviewing the changes before pushing an update. Users don't since it is different for different projects and is not necessarily obvious or even easily searchable. Just take that few seconds of additional effort and provide the link. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Right because you do that for every single update you push? Honestly, I'm done arguing my point. Other people in this thread have made arguments for it, other people including yourself have made arguments against it. This is turning into a what should the default desktop be discussion. So I'm dropping off. This is a SHOULD not a MUST. If you have packaged for a while, you'd get that. From your previous emails it doesn't seem you are. Hopefully, this one makes my point more clearly. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
