Release Critical Bugs (was: Xfce 4.6 RC1 going to be released this weekend)

Cody A.W. Somerville cody-somerville at ubuntu.com
Sun Jan 25 18:58:37 CET 2009


On Sun, Jan 25, 2009 at 8:35 AM, Jannis Pohlmann <jannis at xfce.org> wrote:
<snip>

> Now, everyone knows that a bug-free release is unrealistic. Most of the
> components haven't really changed since November and for those who have
> been running it since beta2 it worked really well.
> Of course more testing would be cool, but personally, I'm slowly getting
> tired of discussing the schedule again and again. Whenever we decide on a
> new schedule and try to stick to that, someone raises concerns. Why not
> worry less, let the beast off the rope and see how this turns out? I
> think it's time to finally end this struggle. Even if 4.6 will not end
> up to be the most stable Xfce release ever, it is in a faily good shape
> today and everyone is going to be happy as soon as 4.6.0 hits the
> servers.
>
> I know we'll have to clean up a few things and fix a few bugs after the
> release anyway, so releasing 4.6.1 maybe a month after 4.6.0 should be
> fine. I'll also have a lot more time after FOSDEM than I have right
> now, so I'll help where I can.


I agree with you 100% Jannis. However, on a bit of a tangent, there should
be some wiggle room to allow for stop-ship, release critical bugs to be
fixed. Is there a process in place for a developer to make such a request to
the release manager?

In Ubuntu, we define a release critical bug as a bug that has a high impact
on the overall usability of a release or any changes that are made during
the development cycle for pragmatic reasons which are intended to be
reverted before the release. We also require that the bug have someone
assigned to fix it before accepting it as release critical. Basically,
someone proposes it and our release manager either agrees or disagrees.

In Debian, however, they have much more specific criterion which can be
found at http://release.debian.org/lenny/rc_policy.txt

Maybe the above information can be used to develop Xfce4's own release
critical criterion and processes. :)


>
>
>  - Jannis
>

Cheers,

-- 
Cody A.W. Somerville
Software Systems Release Engineer
Custom Engineering Solutions Group
Canonical OEM Services
Cell: 506-449-5899
Email: cody.somerville at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20090125/37bb7a9a/attachment.html>


More information about the Xfce4-dev mailing list