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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
