Xfce Spin Beta - Thoughts, feedback requested.

Fri Apr 22 15:38:51 UTC 2011

On Fri, 2011-04-22 at 12:06 +0200, Christoph Wickert wrote:

> There are a few issues remaining, but we will get them fixed for final.
> Taka a look at the tracker bugs
> F15Target-xfce: https://bugzilla.redhat.com/show_bug.cgi?id=678916
> F15Blocker-xfce: https://bugzilla.redhat.com/show_bug.cgi?id=678917
> 
> As you see all of the issues you mention should be fixed already and I
> have no idea why they are not in the beta or how to get them in. In the
> past I just filed tag requests and rel-eng tagged the packages but now
> that we have the NTH and Blocker process and my tag reqzests are closed
> invalid. :(
> 
> CC'ing Adam Williamson, he might know more.
> 
> Adam, as you see it's not just the lxde-common package that has missed
> the LXDE Spin beta but also *a lot* of other packages for Xfce. Were you
> aware of these issues in the Go/Nogo meetings?

Yup. Go / No-Go meetings are far too late, though.

>  If not, what should we
> have done to bring them up to your attention? Our Xfce tracker bugs are
> already blocking F15-Target and F15-Blocker but on the other hand we are
> told that spins cannot block something. I find this very confusing, it
> doesn't seem to work out for the spins and in the end, things get less
> testing because they are not released in time.

So, here's the deal with how it works. The key point to keep in mind is
that bug reports are _central to the process_: keep bug reports in the
right state at all times and things should work out.

We don't review tag requests as tickets for rel-eng on a case by case
basis any more; that system was too haphazard and arbitrary. We use the
release blocker and NTH bug processes.

Once we freeze for any release (Alpha, Beta, GA) then only packages
which fix a bug accepted as a release blocker or NTH (nice-to-have) bug
will be taken through the freeze, into that release compose.

As you noted, Xfce cannot block the release per current policy - this is
not QA's determination to make, we just roll with whatever the policy
is. Currently, GNOME (in its capacity as the 'default desktop') and KDE
can block the release; no other spin or desktop can. So Xfce doesn't
need to worry about the blocker process, only the NTH process. Issues
that are 'blockers' for the Xfce spin are by definition NTH for the
project as a whole, so the Xfce blocker bugs should block the project
*NTH* bugs, not the project blocker bugs. (F15Blocker-xfce should block
F15-accepted, for instance).

Executive summary so far, if you want a fix taken through a freeze, then
you must propose a bug that it fixes as NTH - mark it as blocking
F15-accepted (final release), F15Beta-accepted (Beta), F15Alpha-accepted
(Alpha). Same names but 16 for F16, and so on.

What happens once a bug is proposed is that it gets reviewed at the next
blocker review meeting. These happen weekly on Fridays. If we (the
review team is QA plus releng plus whoever else happens along, if you
come to the meeting we'll take your views into account; usually we get a
consensus for each bug) accept the bug as NTH, it'll get 'AcceptedNTH'
added to its whiteboard field.

Once a bug is in this state, if you build a fix for it, that fix can go
through a freeze: but releng needs to know it exists. Again, we go via
the bug reports for this - so you need to make sure you mark the update
as fixing the bug in Bodhi, so the bug report gets automatically updated
as the fix is pushed and tested. If there's a bug marked as AcceptedNTH
but the bug report doesn't say anything about there being a package
around to fix it, nothing will happen.

If you *do* make sure the bug report has info about the fix, then the
build should get listed in the releng trac ticket for the upcoming
candidate build. For instance, here's the trac ticket for F15 Beta RC,
listing all the packages that needed to be pulled in:

https://fedorahosted.org/rel-eng/ticket/4538

So, again a broad summary of the process:

* Propose a bug as NTH
* Build a fix for it and make sure this info is available in the bug
* Make sure the fix gets karma (we usually won't take a fix without
karma)
* Optionally, come to the blocker review meeting to make sure it gets
accepted as NTH, and keep an eye on the trac ticket for the upcoming
candidate build to make sure the fix gets listed there - but these two
bits should happen even if you don't get involved

The criteria ('principles') for NTH bugs are here:

https://fedoraproject.org/wiki/QA:SOP_nth_bug_process

As noted, we consider any release criteria-breaking bug in a
non-blocking spin like Xfce to be automatically an NTH bug.

Note that we won't do a re-spin *solely* for NTH issues: so if we have,
say, an RC2 spin which fixes all known blockers, and then fixes arrive
for a couple of NTH issues, we won't do an RC3 spin to include the NTH
fixes. We only re-spin for blockers.

The Go/No-go meeting only decides whether to bless the current candidate
build for gold, or delay for a week; we would never delay for an NTH
issue (that's the definition of the difference between NTH and
blockers), so unless we happen to delay for some real blocker issues,
go/no-go meeting is already too late for any NTH fixes to happen.

For the above reasons, the TC builds are vital for non-blocking
desktops; you know that there will be at least one RC build, but you're
never guaranteed one more. So make sure to test the TC, mark any
critical bugs you find in it as NTH, and get fixes in before we start
spinning RCs, so you can be sure they'll make it in.

Hope that helped! Let me know if you have any questions.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net