Lack of update information

[Denis Leroy]

Kevin Kofler wrote:
> Denis Leroy wrote:
>> Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
>> while ago. How would you summarize it to Bodhi ?
> 
> Ugh, doesn't upstream provide a more user-readable list of changes? IMHO
> they should get that complaint...

They do actually, they provide the NEWS files which is a bit shorter 
(although this one is unusually long, they're typically 3 to 4 
bullet-point long) :

* CellRendererPixbuf: Added the icon-name and follow-state
   properties, noticed by Mathias Hasselmann.
   (Murray Cumming)
* Printer::enumerate_printers(): Fix a refcounting problem found by Tor 
Krill.
   (Armin Burgmeier)
* Gdk::Window: Added an invalidate() that takes no rect
   parameter because it can be NULL in C.
   (Murray Cumming)
* Cleaned up gtk includes to use only toplevel headers, as may be 
required by
   a future GTK+ version.
   (Przemysław Grzegorczyk) Bug #564006
* Container: Use GType instead of GtkType for the  child_type_vfunc() 
return type
   This should allow soure code to use gtkmm if it declares 
GTK_DISABLE_DEPRECATED.
   (Murray Cumming) Bug #562893 (Dénes Faluvégi)
* Documentation:
   TreeModel: set_value_impl() documentation: Mention row_changed(),
   not set_row_changed(). Bug #562505 (Bohumir Zamecnik)
* HandleBox: Restore the child-attached property, which was lost at some 
point
   during 2.14.
* LinkButton: Resore the visited property definition, which was lost at 
some
   point during 2.14.
   (Murray Cumming)
* CellView, ComboBox, EntryCompletion, IconView: Added unset_model().
   (Alexander Shaduri) Bug #555268



> And it's true that it's particularly hard to summarize bugfixes in a library
> (like that printer signal proxy fix) without knowing a concrete application
> bug they fix.
> 
> In any case, try this:
> 
> Update to the latest upstream release, 2.15.0, which fixes the use of some
> deprecated APIs and header files (which caused programs using gtkmm with
> GTK_DISABLE_DEPRECATED to fail to build) and a bug in the printer signal
> proxy which could cause application crashes (the printer object was being
> unreferenced at an inappropriate place), adds some new APIs which may be
> required to compile new gtkmm-using software:
> * GtkHandleBox::child-attached (signal) and GtkLinkButton::visited
> (property), which were accidentally missing in 2.14.x
> * unset_model() methods for GtkCellView, GtkComboBox, GtkEntryCompletion,
> GtkIconView and GtkTreeView
> * a parameterless version of GtkWindow::invalidate()
> * GtkCellRendererPixbuf::icon-name and GtkCellRendererPixbuf::follow-state
> (properties)
> and includes some minor documentation fixes.
> 
> But I'll admit this took me several minutes to write.

Good job :-) But this whole exercise is futile. We DO ALREADY ship both 
the ChangeLog and the NEWS files in the documentation directory, either 
with the library or development package. How is repeating or summarizing 
these internal changes *on Bodhi* useful to anyone ?

- If you're a gtkmm developper, you will not read the Bodhi information 
as you probably already know about the update already, you'll go 
straight to the NEWS or ChangeLog file shipped with the RPM (or on the 
GNOME FTP site) to see if any of the changes impact your work.

- If you're not a gtkmm developper, the information above is impossible 
to understand and not useful at all. At best you want to know if the 
update is a bugfix update, or what ? not a bugfix update ? new features 
? how is that useful ? If a library update maybe fixes an occasional 
crash in an application that uses it, how can you tell that the problem 
was fixed by "Printer::enumerate_printers(): Fix a refcounting problem" 
? As a Fedora user, how is that information going to affect your 
decision making ? Are you going to decline a package update if the 
summary doesn't include some key words ? (I call BS on anyone answering 
yes to that).

So the concept of summarizing the ChangeLog for Bodhi imposes a heavy 
burden on packagers for little added value.

Don't get me wrong, I'm not saying the "Notes" field in Bodhi is 
useless. First, linking Bodhi updates with bugzilla entries is extremely 
useful to start with. And if you're pushing a user-visible application, 
I'd want to know if this adds some interesting new features to it, no 
doubt. But it'd be easier to have a Bodhi field where one can paste a 
URL pointing to the "News" or "Changes" section of the upstream webiste, 
or linking with the Gnome FTP NEWS file...

-denis