[Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1

James Laska jlaska at redhat.com
Wed Jul 13 19:17:59 UTC 2011

On Wed, 2011-07-13 at 11:52 -0700, Adam Williamson wrote:
> On Wed, 2011-07-13 at 13:22 -0500, Bruno Wolff III wrote:
> > On Wed, Jul 13, 2011 at 14:28:33 -0400,
> >   James Laska <jlaska at redhat.com> wrote:
> > > == Suggested Meeting Preparation ==
> > 
> > Is there a plan to steamline dealing with all of the systemd create a native
> > service bugs?
> Here's a plan: we reject them all.
> Since we started 'modernizing' the blocker process we've been consistent
> in saying that incomplete features are not release blockers, and I'm
> increasingly confident this is the correct way to handle it.

I hadn't yet worked through the specifics that you outlined, but I fully
expected us to review and accept/reject them as a whole.

> Rationale:
> # The release blocker system is intended to ensure the quality of the
> release, not the completeness of its features
> # Fedora works on a time-based release system: we do not consider it a
> requirement that features be complete in order to ship a release
> # There is a feature process which is separate from the release
> validation process, and managed by FESCo
> taking all of these together, I think the correct approach is that
> incomplete features are not considered to block releases, and that it's
> FESCo's responsibility to deal with incomplete / late features under the
> feature process, in whatever way they deem best so long as it's
> compatible with all freezes. This usually means that they either give
> the feature a pass and let the developer complete it a bit late, or drop
> the feature; they've never said 'hey, let's hold up the release for
> this' except in very specific circumstances (like systemd last time
> around). Since this seems to come up at least once a cycle, we should
> probably explicitly codify it into the release criteria.
> Thoughts welcome :)

Your ideas are consistent with how we've handled this before, I don't
think I could have articulated nearly as well though :)  My
understanding is that FESCO is the right place to discuss whether a
feature should block a release or not.

Translation ... I agree :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110713/3d4385dc/attachment-0001.bin 

More information about the test mailing list