Re: Release management problems

On Fri, 2014-02-07 at 10:44 -0500, Pavel Simerda wrote:
----- Original Message -----
From: "Bastien Nocera" <hadess hadess net>
To: networkmanager-list gnome org
Sent: Friday, February 7, 2014 9:24:16 AM
Subject: Release management problems


We're running into trouble with the recent "Team" support in GNOME, as
there's no backing NetworkManager release with the necessary team

It wouldn't be that much of a problem if Fedora didn't ship git
snapshots of the "next" NetworkManager version. Why ship git snapshots
in Fedora that are apparently not good enough for full releases? Could
upstream not do with testing on more than Fedora?

Sounds like a request for the Fedora NetworkManager package rather
than upstream. As I understand it, the Fedora maintainers (while being
NM upstream developers as well) want to keep up with the current
upstream development and at the same time the current upstream
development is so much ahead of the latest upstream release.

But it's good enough to go in Fedora stable releases, but not as
releases for all distributions to use? I don't understand that.

 That could improve when the 0.9.10 release is ready.

We already had the same problem 6 months ago with 0.9.8.

 You, if I understand correctly, would prefer to only include upstream
NetworkManager final releases to Fedora just to help
gnome-control-center developers keep their software compatible with
the latest NM release.

I would prefer releases to be made for all distributions, or even
better, something that syncs up with GNOME releases.

I wonder whether such a rationale is a generally accepted one in
Fedora. There's NetworkManager developer documentation for the
released version to keep using only features existing in that release.
I guess there are also non-Fedora Gnome developers who could easily do
the pre-release gnome-control-center testing to ensure it can be
compiled and used on a system with a released version of

As mentioned in the mail to Dan, something like GLIB_VERSION_MAX_ALLOWED
would be useful to avoid this sort of problems, at least from the "does
it compile" stand-point. I don't expect NM to grow the same sort of
"shield" for its D-Bus APIs that we might be using, but for the
front-ends to degrade gracefully should it happen.


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