Fedora.NEXT Products and the fate of Spins

[Stephen John Smoogen]

On 29 January 2014 15:49, inode0 <inode0 at gmail.com> wrote:

> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard at gmail.com> wrote:
> > On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher <sgallagh at redhat.com>
> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Apologies for the slightly alarmist $SUBJECT, but I want to make sure
> >> that this gets read by the appropriate groups.
> >
> > [snip]
> >
> >
> >>
> >> 1) Are Spins useful as they currently exist? There are many problems
> >> that have been noted in the Spins process, most notably that it is
> >> very difficult to get a Spin approved and then has no ongoing
> >> maintenance requiring it to remain functional. We've had Spins at
> >> times go through entire Fedora release cycles without ever being
> >> functional.
> >>
> >
> > Putting on my rel-eng hat I can say that any spin that fails to
> > compose will be dropped.
> >
> > I believe we also encourage or even require the spin maintainers to
> > test their spin as functional.
> > (To work out if the spin succeeds to compose but fails to actually work)
> >
> > The idea is to encourage active spin process, inactive spins will auto
> > retire by policy if they fail.
> >
> > Another aspect I worry about is the mirroring stuff.
> > With the coming WGs I fear the rsync mirroring will grow very large,
> > and spins are an attractive piece of fat to cut.
>
> You probably didn't mean for that to sound so negative but a piece of
> fat to cut is how rel-eng thinks of spins?
>
> I recall being assured at the beginning that some interested company
> was willing to provide the necessary support for us to give this a
> fair try.
>
>
How long is a fair try? It would help to define that before people go on a
rant about doing it for a couple of years now.


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140129/6552c11a/attachment.html>