On Tue, 2010-05-18 at 14:08 -0400, James Laska wrote:
> Apologies ... I should have started out with a "Thank you" for
> initiating this thread and sharing your ideas.
Oh, I figured that was implied, given that we've chatted on IRC about
this in the past (: (I also thank you for your feedback on the idea)
>
> On Tue, 2010-05-18 at 10:37 -0700, Jesse Keating wrote:
> > On Tue, 2010-05-18 at 11:54 -0400, James Laska wrote:
> > >
> > > I like the idea of having multiple flags, however am concerned that it
> > > is a significant documentation/training challenge.
> > >
> > > Is there benefit in rolling this out in phases? Part#1 would involve
> > > adding only a 'blocker' flag to allow for improved query and 3 blocker
> > > request states (requested, accepted, rejected). Part#2 would add the
> > > team specific blockers (devel, releng and qa) and an automated mechanism
> > > to approve/reject 'blocker' requests based on these new flags.
> >
> > In my opinion, the training would be fairly light, and doing it in
> > phases wouldn't necessarily help here.
>
> > The biggest change is that when a user or developer considers something
> > to be a blocker, they set the flag to ? instead of adding the
> > F??{Alpha,Beta,Blocker} blocking bug. That's going to happen even if we
> > do it in phases. After that, the relatively small communities of releng
> > and QA need to know how to cast their vote for blocker or not via flags.
> > Since we're relatively small, it should be easy to train us. The
> > maintainer or bug owner themselves will also have to confirm it's a
> > blocker in their opinion, I suppose that's the second biggest change.
> > The final biggest item would be using the right query to discover the
> > current list of approved blockers, and that would have to happen in the
> > first phase as well.
> >
> > Doing it in phases removes one of the biggest advantages to me, the ease
> > of doing this work in an asynchronous mode.
>
> Agreed. I'm just sharing my experiences going through this same
> workflow definition where it took many releases to flesh out. So I'm
> hopeful it could be defined and documented in a 2 month span, I'm just
> not optimistic.
That's a fair point, there is a lot of ground to cover, but that's what
we're good at right? Rapid change? (:
>
> Just so you don't think I'm Mr. Gloom'n'Doom, I'm not rooting against
> success here. I'm just trying to be realistic and hopeful we can avoid
> maintaining+executing a half-implemented process that doesn't meet the
> stated definition of success.
I agree. If this goes forward into a full blown proposal, it will have
to have some concrete deliverables and deadlines, that if not met, we
don't go forward until the next development cycle.
>
> Maybe the next step is spelling out the proposed changes on the wiki?
I've asked Dennis Gilmore to explore with the bugzilla admin what our
options and capabilities are, so that we can better form the wiki
proposal.
>
> > My goal is to reduce the
> > amount of time we spend in those meetings, and to increase clarity for
> > maintainers and testers as to which bugs are actually blockers. A 50%
> > reduction in goals in order to do it in phases doesn't sit well with me
> > (:
>
> No objections with your stated objective, I agree and share some of that
> goal. We have made some great strides in adding transparency to the
> blocker meetings and doing our best to apply the release criteria in an
> objective and consistent manner. As intended, doing so has correctly
> highlight some of these rough spots in the process. This seems like a
> natural flow along those lines, and qualifies as "good" problems to
> have :)
>
> How do the following goals sound?
>
> 1. Document blocker bug escalation procedures
> A. I think this is a no brainer, but we'll need the process
> documented in SOP form on the wiki
> B. Do we still need to distinguish between "MUST HAVE" and
> "NICE TO HAVE" (which I have been treating F13Blocker
> and F13Target as, respectively)
> 2. Reduce meeting time spent reviewing proposed blocker bugs
> 3. Increase asynchronous/out_of_meeting blocker bug approval
>
> Anything else?
I'm still not sure I want to tackle B at this time. This will likely be
larger set of items than the block the release set. I've moved our
development cycle in a direction that allows maintainers and testers to
decide what goes in based on karma rather than a releng/qa decision.
This works up until we get to an RC state and stop pushing "stable"
updates into the tree, and instead start pushing into the 0-day update
set. During that small window, where we might have a re-compose, then
yes there is a set of issues that we'd take, even if we wouldn't block
the release over them. Managing that set for the small window is
important, but perhaps we can go one more release doing that by hand
with IRC chat and the like, while we focus this release on nailing down
how we manage the actual blockers.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
