Response to "Getting Fedora Out of the If-Then Loop"

Paul W. Frields stickster at
Fri Feb 19 23:28:04 UTC 2010

On Fri, Feb 19, 2010 at 01:39:21PM -0900, Jeff Spaleta wrote:
> On Fri, Feb 19, 2010 at 1:26 PM, Robyn Bergeron
> <robyn.bergeron at> wrote:
> > It seems like there is a definite disconnect on what needs to be done
> > as far as timing, scheduling, etc for the spins, at least from reading
> > this.  Fedora gets pumped out every 6 months because we operate on a
> > tight, well-defined schedule.  It seems like sitting down and defining
> > what a timeline might be for doing these things for a spin would be a
> > good idea, particularly if we can define how it would work in relation
> > to the overall Fedora schedule.
> >
> > Workflow is a good thing. Defining it and publishing it is even
> > better.  If others feel that this is a definite, ongoing problem, then
> > we should resolve it together, not point fingers at each other.

I agree.  It's very frustrating to see contributors who feel they are
not being valued make other contributors feel the same way.  In a lot
of cases the problems are miscommunication or misunderstanding, and
blowing that up into bad intentions is not helpful.

> Would it be advisable to have important Marketting,Design,etc..
> request deadlines on
> and associated release schedules like:
> as a one-stop overview that puts request deadlines in context with a
> release cycle?

Yes.  John Poelstra, the Fedora program manager, spends a substantial
amount of time maintaining team schedules.  Around release time (from
just before to just after) he asks various groups to revisit their
schedule, and add, delete, or modify items that are on those
schedules.  We can and should certainly take advantage of that
schedule to track all the items that a team expects to work on.  These
schedules do not exist for no reason.  They exist because they
represent a shared understanding of what a team plans to work on and
complete for a release.

I still get the impression, though, that Christoph feels the answer to
his particular issues are "other teams need to work harder."  Is
*expanding* the list of tasks for those teams really going to help
solve the problem?  Not unless we pick the right ones, and prioritize
properly.  Adding to a mountain of "undeliverable deliverables" is
demoralizing and just plain no fun.
> I'm also not sure there's an understood expectation on how long an
> initial spin approval process takes so in the case of LXDE spin
> specifically the entire process could have been started too late in
> the F13 release cycle to get support from other groups in a timely
> manner.

A number of spins, including the LXDE spin, are already approved from
previous releases, and didn't require any special treatment at least
from the Board's perspective.  I don't think that was really a factor.

In the specific case of marketing for F13, the team is planning to set
aside a specific place in the talking points for new spins.

Paul W. Frields                      
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717   -  -  -  -
          Where open source multiplies:

More information about the advisory-board mailing list