Negative karma for missing update descriptions?

[Ankur Sinha]

On Thu, 2013-07-04 at 14:45 -0700, Adam Williamson wrote:
> On 2013-07-04 6:36, Ankur Sinha wrote:
> > Hi,
<snippity>
> 
> This is the result of a currently-active thread on devel@:
> 
> https://lists.fedoraproject.org/pipermail/devel/2013-June/184641.html
> https://lists.fedoraproject.org/pipermail/devel/2013-July/184687.html
> 
> Full disclosure: I actually endorsed -1 votes on updates with faulty 
> (empty, or placeholder) descriptions in that thread. Now I'm thinking 
> that might have been going a bit far, but do bear in mind these 
> descriptions are displayed in our update tools, under the assumption 
> they'll actually be sane. When they aren't, it does look pretty damn 
> unprofessional.

I agree that missing update descriptions looks bad in our update tools
but I still don't think the update merits negative karma. An update
which fixes bugs that it claims to fix should get to stable ASAP. One
negative karma because of a missing description can hold up an update
for hours/days, who knows? It needs to be corrected before the update is
pushed IMO. Here's a brain fart:

Request bodhi upstream to include update "Templates". (For example,
infra has templates in trac). 

So, for a new package update, a default "The %{name} package has been
added to the Fedora repositories. Review request: Bug#%{rhbzbug}" will
be present in the text area. The maintainer can choose to enhance the
description or leave it be. (%name and %rhbzbug will be expanded to
their values, of course.)

For a bug fix, we do something similar. A default description on the
lines of "This update to the %{name} package should fix the listed bugs.
Thank you for reporting these bugs." could be in the text area by
default. If the maintainer wishes to enhance it, good, otherwise, at
least a minimum message is available. 

(Something similar for bugs that are enhancements can be used)

I have no idea how easy or difficult it is to implement this, but I can
open a ticket with infra and at least get their take on it. 

This:
* ensures that a minimum, professional update description is always
present.
* takes some of the load off maintainers who dislike re-documenting what
bugs were fixed.

Comments?
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20130705/59c776bb/attachment.sig>