Fedora Board Recap 2009-12-17 UTC 1700

[Matt Domsch]

On Sat, Dec 19, 2009 at 10:13:21PM -0600, inode0 wrote:
> On Sat, Dec 19, 2009 at 9:44 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
> > I'm fairly certain the board meetings aren't taped and for good reason.
> 
> If the only topic at this meeting was the updates/installs
> presentation I'm having a hard time imagining a good reason it
> couldn't have been done in public.

It certainly could have been, but in general we've been having one
public IRC meeting a month, and the other three are higher-bandwidth
phone calls with notes taken during the call.  This happened to make
the agenda for a phone call.  Given the tone, and repetitiveness of
the conversation, it could have been done on IRC too...

> Doing work out in the open is not always possible, it is almost
> never as convenient as the alternative, but I hope the board will
> continue to look for opportunities to give the community access.

I struggle with this.  From a logistics POV, we could do a wider phone
bridge, or bridge with limited voicing.  I think we've been waiting on
Fedora Talk to have that capability.  But I don't think listening in
on a 2-hour meandering conversation, either live or recorded later,
would really help in this instance.

Their proposal was public (it's in the wiki), and was certainly
discussed in various groups at FUDCon Toronto.  I don't know how much
more open that can be, without requiring all conversations about
anything to get moved onto the mailing lists.

I think the whiteboard proposal doesn't do enough to explain what
the pain points are, before it jumps into proposals for how to address
them.  Maybe the pain is obvious, but it's hard to motivate large
swaths of the project contributors to change their ways without being
able to articulate _why_ they should, and how life will be better
having done so.

I don't fault Jon and Christopher for bringing their idea to the
Board.  They are in many ways trying to help define the audience for
Fedora, which the Board has been struggling with for some time.  The
problem here (from my perspective) was recognizing that there are many
audiences to satisfy.  Furthermore, I'd like anyone to feel
comfortable bringing any concerns, ideas, etc. to the Board.  Yes, the
Board may well redirect (either before or after listening), but the
Board need not only converse on requests raised by another formal
committee (e.g. FESCo).

Jon and Christopher presented a plan which, to me, tried to collapse
several different audiences into one.  I think that the audience for
updates-released is significantly different than the audience for
rawhide.  In increasing levels of "pain I as a user am willing to put
up with", updates-released -> updates-testing -> Fedora++-devel (early
branching due to No Frozen Rawhide plans) -> rawhide.  Processes
(including level of QA) that let developers push updates into rawhide
necessarily should differ from pushing updates into updates-released.

Is rawhide in its current form perfect - no, far from it.  But
concrete steps _are_ being taken to address the most obvious pain
points: No Frozen Rawhide, including early branching for Fedora++;
AutoQA to test trees prior to being published.  Maybe even (gasp)
nightly repoclosure, and, dare I say it, automatic rebuilds of
packages when one of their dependencies change.

Is the updates-released process perfect?  Again, no, and steps are
being taken to address some of the more visible pain points here too.
The return of "the set of packages which thou shalt not break" is
welcome - now we need some help with AutoQA to check those more
thoroughly.  Getting additional people to use updates-testing, and
report bodhi karma and comments, either as a formal tester or not,
would help.  Batching updates into weekly chunks?  I'm not convinced
yet.  I can see how that might give a QA team a more testable target,
but I'm not convinced it helps our users a whole lot.

What I'd like to see out of this is that when people do wish to
suggest far-ranging changes to the Project, please put more rigor put
into articulating the problems, politely, but thoroughly, and proposed
solutions, in a consumable fashion.  Sure, this may cross internal
boundaries and responsibilities - I'd hope we're not so inflexible as
to allow such.  If you don't know where a piece or two belongs, the
Board can help with that redirection.

Thanks,
Matt