GUADEC: Work in the pipeline for GNOME

Posted Aug 25, 2012 0:55 UTC (Sat) by jengelh (guest, #33263)
In reply to: GUADEC: Work in the pipeline for GNOME by walters
Parent article: GUADEC: Work in the pipeline for GNOME

>both of them by default look for upgrades

Of course they will — they have no other means. However, "upgrade" is a misnomer, it should really be called "preferred version".

Developers tag their packages such that a tool can decide which among two is more preferred. If gtk-2.27 somehow is more preferred than gtk-2.28 due to a bug, you, as a {upstream and/or distro-level} developer, have to indicate the preference to the tool, *somehow*. Whether that happens by means of Epoch prefixes, amount of lolcats shipped alongside the package, or manual intervention by the end-user (pinning), the choice is irrelevant.

And ostree, the way you describe it, looks a lot like pinning by the end-user. A local "master" branch in a git clone is similarly pinned — you have to manually run pull/merge to change it.

GUADEC: Work in the pipeline for GNOME

Posted Aug 25, 2012 16:42 UTC (Sat) by walters (subscriber, #7396) [Link] (1 responses)

Mmm...there are two fundamental differences versus a user pinning packages on their own machine.

1) You always have the previous working system to boot into. If NetworkManager breaks, you may set up a pin locally for the old version, but that doesn't do you a lot of good if you don't have networking to download it =)

2) The release manager has the option to push arbitrary versions at any time - the closest analogy I can think of would be if someone made a Debian package containing pins. Say it was like "known-good-versions.deb", that dropped a file into /etc/apt.conf.d/known-good-versions.conf.

Basically I think reverting back to older known good versions should be a nearly-constant operation in the development tree. It should be easy for both users and release managers.

If you look at how Mozilla makes Firefox, they "back out" changesets often. Just run "git log --grep=Back" in mozilla-central. Here's an example.

GUADEC: Work in the pipeline for GNOME

Posted Aug 28, 2012 20:13 UTC (Tue) by guillemj (subscriber, #49706) [Link]

> 1) You always have the previous working system to boot into. If NetworkManager breaks, you may set up a pin locally for the old version, but that doesn't do you a lot of good if you don't have networking to download it =)

That's why front-ends like apt store previously downloaded packages and keep them in a cache on disk (I'm guessing yum might behave in a similar way).

> 2) The release manager has the option to push arbitrary versions at any time - the closest analogy I can think of would be if someone made a Debian package containing pins. Say it was like "known-good-versions.deb", that dropped a file into /etc/apt.conf.d/known-good-versions.conf.

In Debian, this role is taken by the testing distribution.

> Basically I think reverting back to older known good versions should be a nearly-constant operation in the development tree. It should be easy for both users and release managers.

Sure, but that does not really require downgrading, one can always prepare a new package that backs out a specific change, in the same way you'd do with a project on a git repository, going always forward (like your mozilla example). It does require someone to bisect the problematic code though, but that needs to be done anyway at some point. Either that or the user can revert to a previous local version.