[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Lack of update information



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]