On Mon, Mar 11, 2013 at 4:12 PM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > On Mon, Mar 11, 2013 at 12:43:28PM -0400, Tom Lane wrote: >> "Jared K. Smith" <jsmith@xxxxxxxxxxxxxxxxx> writes: >> > On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro >> > <mike.catanzaro@xxxxxxxxx> wrote: >> >> Perhaps the update policy should have a guideline on the minimum amount >> >> of information required in this description. E.g. "update to latest >> >> upstream version" might be a perfectly acceptable description for Fedora >> >> given the fast pace of updates, but I don't think users should ever be >> >> seeing "no update information available" and especially not "here is >> >> where you give an explanation of your update." (And I've seen this one >> >> multiple times within the past couple of weeks.) >> >> > I tend to agree here. That being said, most of my package updates are >> > something along the lines of "Update to upstream 2.5 release" -- would >> > you find that descriptive enough, or still lacking in detail? >> >> FWIW, I tend to say "update to upstream release XYZ" and give a URL for >> the upstream release notes for that version. This approach requires an >> upstream that's well enough organized to have such a webpage for every >> version, of course; but for my packages this seems to work fine. The >> upstream notes tend to have way more info than I could cram into an >> update description, anyway. > > It'd also be great if we didn't have to duplicate changelogs > everywhere. In libguestfs, the canonical source for a change is the > git log. If I'm unlucky I may end up duplicating this three or more > times: > > - in the RPM %changelog > > - in the Fedora git commit (fedpkg commit -c helps here, thanks!) > > - in the Bodhi update > > - all of the above in the backport to the stable branch > > Even if you argue that user changelogs should be different from > developer changelogs -- and I would agree -- there's still far too > much duplication needed. > > In short my point is: don't moan about bad update messages when the > problem is our software sucks. > > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel I tend to agree with this. Sometimes when you are updating multiple packages at a time, it's annoying, and I'm putting update to "latest upstream version" just because I have to put something there anyways. Regardless, I usually always try to include the bug numbers I'm fixing because bodhi will auto close bugs for me. I also put it in the rpm change log. I also from my own experiencing of burning myself always test stuff in rawhide and install said RPMs (for at least MATE and stuff I am the original owner of) and do a bit of basic testing before pushing it out to released versions of Fedora. I even do scratch builds on rawhide to make sure it builds on koji as well too before committing. So yes, while it may not be descriptive, if the update includes bug numbers that the update fixes that should be good enough, including in the spec file itself I was trained to put RHBZ #'s of why I changed/added/deleted/moved something to fix a bug. With other stuff it's a bit trickier, I'm hoping that the latest upstream version fixes whatever issue the bug reporter is having and it is up to them to test it and leave positive/negative karma on bodhi to let me know if i pushed out a bad update as well. That being said, I believe that it is okay to put that in the bodhi notes + the bug numbers unless there is some other reason to put something more specific, especially when you are pushing out 10-20 (times 2 for each Fedora release) updates at a time. Dan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
