At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.
For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well.
So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzB... and then I'll pick up the build for the mega update.
Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot.
Thanks,
Richard.
On Mon, Mar 26, 2012 at 11:52 AM, Richard Hughes hughsient@gmail.com wrote:
At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.
For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well.
So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzB... and then I'll pick up the build for the mega update.
Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot.
It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix.
Peter
On 26 March 2012 11:58, Peter Robinson pbrobinson@gmail.com wrote:
It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix.
Yes, this is a valid critisism. I'm hoping to write a tool to automatically update GNOME builds in a stable release and in rawhide (that watches ftp-release list), rather than having to do it all manually.
Richard.
On Mon, Mar 26, 2012 at 12:49:32PM +0100, Richard Hughes wrote:
On 26 March 2012 11:58, Peter Robinson pbrobinson@gmail.com wrote:
It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix.
Yes, this is a valid critisism. I'm hoping to write a tool to automatically update GNOME builds in a stable release and in rawhide (that watches ftp-release list), rather than having to do it all manually.
If you want ideas: http://svnweb.mageia.org/soft/mga-gnome/trunk/mga-gnome?view=markup Though note that Mageia packages per .so library version, so any bumps = breakage (on purpose, goes in another package)
Also, if you need more information on ftp.gnome.org or in ftp-release-list: http://git.gnome.org/browse/sysadmin-bin/tree/ftpadmin Still want: - One (preferably json) file on ftp.gnome.org containing all latest versions of all modules. Problem is that master.gnome.org uses NFS and bit worried about how to update such a file nicely. - An RSS feed again (apparently there is some django module which makes this easy; needs to be available for RHEL6/EPEL6).
On Mon, 2012-03-26 at 11:58 +0100, Peter Robinson wrote:
.
It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix.
The trick is to not build for rawhide ever, until after the stable release is out, and instead rely on inheritance. Since building everything twice is just a terrible waste of effort, and makes this whole mass building thing even more of a torture. But, of course, this only works if you get on the right track when doing the first build after the fork - unfortunately, our forking setup makes it not easy to avoid doing at least one accidental F18 build before you notice the new branch...
On Mon, Mar 26, 2012 at 10:07:45 -0400, Matthias Clasen mclasen@redhat.com wrote:
The trick is to not build for rawhide ever, until after the stable release is out, and instead rely on inheritance. Since building everything twice is just a terrible waste of effort, and makes this whole mass building thing even more of a torture. But, of course, this only works if you get on the right track when doing the first build after the fork - unfortunately, our forking setup makes it not easy to avoid doing at least one accidental F18 build before you notice the new branch...
If we really want to rely on this process, I think we should reconsider having rawhide inherit from the previous release's (currently f17) updates.
Currently it can take a while for fixes that are just in f17-updates-testing to make it to rawhide. This is particular bad around freezes.
Another thing to note about not doing builds for rawhide, is that we don't get early testing of build issues for things that are in rawhide but not in branched.
Matthias Clasen wrote:
The trick is to not build for rawhide ever, until after the stable release is out, and instead rely on inheritance. Since building everything twice is just a terrible waste of effort, and makes this whole mass building thing even more of a torture. But, of course, this only works if you get on the right track when doing the first build after the fork - unfortunately, our forking setup makes it not easy to avoid doing at least one accidental F18 build before you notice the new branch...
I don't recommend relying on this, because underlying libraries can have different sonames in Rawhide than in the release. IMHO it's better to always build for Rawhide separately, even when not strictly necessary.
Kevin Kofler
Richard Hughes wrote:
At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.
the kde-sig has similar pain-points doing mass updates. Having a list of pkgs to build (seems done on google docs in your case already, good), and having your own koji tag/target does seem to simplify matters a bunch. Then it's relatively easy to compose a bodhi update from the output from: koji list-tagged --latest f16-gnome for example.
-- rex
Rex Dieter wrote:
the kde-sig has similar pain-points doing mass updates. Having a list of pkgs to build (seems done on google docs in your case already, good), and having your own koji tag/target does seem to simplify matters a bunch. Then it's relatively easy to compose a bodhi update from the output from: koji list-tagged --latest f16-gnome for example.
Let's also mention our mass-update script: https://fedorahosted.org/kde-settings/browser/scripts which may or may not be of interest.
Kevin Kofler
On 26 March 2012 20:31, Kevin Kofler kevin.kofler@chello.at wrote:
Let's also mention our mass-update script: https://fedorahosted.org/kde-settings/browser/scripts which may or may not be of interest.
Very much of interest, thanks. I spent a couple of hours and wrote mclazy, i.e. "I'm lazy and I'm trying to help mclasen".
I've hosted it here: https://gitorious.org/mclazy/mclazy/trees/master and it's really just a simple python script. Patches very welcome, but go easy on the python newbie!
It's currently automatically building about 20 GNOME packages that we've missed on the spreadsheet.
Richard
On Mon, 2012-03-26 at 11:52 +0100, Richard Hughes wrote:
At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.
For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well.
So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzB... and then I'll pick up the build for the mega update.
Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot.
Thanks a lot for this, Richard. It'll make QAing the updates much more manageable.
-
Adam Williamson -
Bruno Wolff III -
Kevin Kofler -
Matthias Clasen -
Olav Vitters -
Peter Robinson -
Rex Dieter -
Richard Hughes