I couldn’t find any ggz related MIRs on the wiki, so I’m presuming that it was done internally.

Either way, it’s in main now so hopefully it shouldn’t be blocking gnome-games being upgraded.

This SRU policy reminds me somewhat Microsofts hotmail service, in a weird way. To get your e-mail delivered (package upgrade included) instead of completely ignored and sent to a black hole, you need to file a bunch of applications (SRU’s) to various programs and then just maybe the servers response of “status=sent” will actually match reality. Imagine GMail, Yahoo mail (Fedora, SUSE, Gentoo, Foresight, etc) and so on having the same policy – as you already put it – it doesn’t scale. Sorry for the analogy, Ubuntu folks, but that’s what it reminds me of.

I don’t think we should start getting unfriendly before ubuntu has had a chance to react. Our distributions are out friends and we should seek to resolve these issues in a friendly manner first.

I understand ubuntu’s position. They want a nice formal QA process for updates to ensure they don’t accidentally break their users installs (again). It’s a perfectly reasonable thing to do. If I was them I would love to have that too.
The problems with the current process as I see it (with regard to gnome):
- they don’t actually have the time for it
- we also don’t have the time for it
- there is no trust
- they chose the wrong place to put it

The first two are obvious. They just don’t have enough man power for such a process. So they expect us to come running when something needs to be done. Problem is that we don’t have the time to tend to every distros special needs. I doubt anything is going to change with these points any time soon…

The last two is where we can change things. Currently ubuntu has no trust in the quality of our bug fixes. They are afraid that a fix will introduce a new bug. That’s a valid concern. If there is reason to believe that the bugfixes that come out of gnome are not trustworthy then we have something to work on. If this is a problem for ubuntu then it will also concern all our other distributions. We need to stop doing the QA work at the distributions and get it into the release process of gnome instead. We are all low on man power so let’s cooperate on catching the issues before they leave gnome.

Currently our “QA” is relying on individual maintainers to test that the bug fixes are good before they ship them. Also we encourage maintainers to run distcheck so that various tests will be run too. Maybe we need stricter rules here?

Can we set up our infrastructure to automatically run distcheck and not release unless it runs without problems? Can we set demands for (ideally 100%) resonable_number% code coverage in these test? Can we demand that dogtail/LDTP tests be setup? Let’s set up static analysis and make sure no new problems are introduced (what’s the deal with coverity btw?) Lastly we could spit out a livecd/vw-ware image (hi rPath) and have real users test the fixes for a day or two before we release.
This is all a lot of work but if that is what the distros want then we should provide – with their help. Something like this would require commitment from the distros. Tests are not going to write themselves and we need people to do the tedious real user testing. In the end though this should be a win for all.

If this is still not enough to convince ubuntu that the fix is good then you e.g. do the 2 weeks in -proposed to do extra testing. Another idea would be to add something like a “bugfixes” channel. Deactivate it by default and allow users to activate it on a per application basis. This way we can tell users in bugzilla to go to synaptic and activate “bugfixes” for gnome-games. This way only the users that are affected by the bug will get the fix (and the potential for new regressions…)

If you want to keep the current system you could convince (me at least) to grade the fixes in the release notes like:
[p1] don’t crash on start up (bug xxxxxxx)
[p2] make some_functionality actually work (bug xxxxxxx)
[p5] move some_button one pixel to the right (bug xxxxxxx)

then you can scan the release notes yourself and fill out your SRU’s for the fixes that are above whatever threshold you find reasonable. We just need to formalize what each grade means then. Like p1 == frequent crasher, etc.

Either way let’s talk about it and try to resolve it together. In the end I just want to be able to deliver fixes for the problems that users come with to our bugtracker.

I’m now running stable Debian on all of my machine.

we don’t necessarily have to discuss the “unless you are running ubuntu” addition in gnome bugsquad, you can add your own local stock responses like i do (just poke me for the greasemonkey script) already for some special cases. if you feel like getting unfriendlier, just do it.

I understand that there is a difference between what we want. We want you to ship our finest newest releases and you want to ensure that your distribution remains stable. What we need is to get to a point where you trust our bugfix releases enough to just test them a while and then ship them. If this is too scary for you them something is broken and we should work on making that not scary. A process like this seems ideal to me:
1) new gnome bugfix release
2) ubuntu ships to testing team (update-proposed)
3) no regression reports for 2 weeks
4) ship to all

The current way of driving this by SRU’s and lauchpad bug reports is tedious and for the case of gnome-games at least have proven itself not to work out.

I’m not saying that the way I propose can be used for everything but it does give a good idea that things are not blowing up. High profile apps may need more careful testing and for kernel, X, etc where hardware plays a role you would need a much broader testing. But for those of us that make bugfix releases we need this kind of process. We can’t run around filing SRU/bugs for each distro. It does not scale. We need you to look at the stuff we provide. Not the other way around.

A lot of the stuff that was fixed for 2.20.2 and 2.20.3 was bugs reported directly to our bugzilla (a lot of crashers from ubuntu too). There are no bug reports in launchpad for those. Tell me how we get these fixes into gutsy asap?