Fedora Board Recap 2008-FEB-12

Jeff Spaleta jspaleta at gmail.com
Fri Feb 15 18:59:19 UTC 2008

On Fri, Feb 15, 2008 at 9:25 AM, Josh Boyer <jwboyer at gmail.com> wrote:
>  Still wondering if there is some kind of hierarchy or priority for
>  spins.

There is no ordering or ranking...as of yet.  I'm not going to propose
that at the Board level until there is an expressed need for it.  If
people working on the spins.fp.org site presentation want to organize
things, we can talk about it. Right now, we're simply trying to fix
bottlenecks in the spin creation and blessing process.

>  >   * Need to determine the hosting requirements and limits
>  >   * How long will spins stay around?
>  I suggested EOL along with the base they are on.  Any thoughts on that?

'stay around' was more in the context of allowing spinners to do re-spins.
The big issue really is hosting.  Is it okay for us to bless a spin
and but tell the spin maintainer that we don't have the space to host
this on our stuff.  Is it okay for us to host a spin one release and
then not offer that spin hosting for the next release cycle, to make
room for something else?  I hope to never have to be in that
situation, but I'd rather have people know upfront, how we are going
to handle it, instead of pissing valuable contributors off later by
making time-sensitive judgments as to resource consumption.

>  This isn't quite true.  Spins are done against the repos that exists on
>  the day they are generated.  So if there are issues/bugs in the
>  base+updates repos on that day, there will be bugs in the spin.  For
>  example, the recent Xfce spin we sort of lucked out that it pulled in a
>  kernel with the security fixes for the vmsplice vulnerability.

The goal here is to lower the bar as much as possible and to prevent
the technical review from being off-base with what we need for a new
spin review.  We still need to be explicit about where the bar is.
Part of the problem right now is both releng and the spin creators
like Rahul are feeling out the technical vetting process pretty much
on their own. Neither side has a clear idea of what should be and
should not be a part of this.  So we go back, and based on the
experience so far trying to get spins through the process, and we
define specific goals (and non-goals) that the technical review is to
accomplish.  And we figure out what a spin creator needs to bring to
the table as part of that process.


More information about the fedora-advisory-board mailing list