long term support release

Jeff Spaleta jspaleta at gmail.com
Wed Jan 23 18:16:30 UTC 2008


On Jan 23, 2008 6:30 AM, David Mansfield <fedora at dm.cobite.com> wrote:
> Fair enough.  I wasn't aware of the commercial aspect of the Ubuntu LTS
> and that is important to understand.

>
> Just to be sure, though, your thesis argument is: community supported
> software can do many things (ie. invent a kernel, reverse engineer usb
> cameras etc), but community can not support an operating system for 2
> years?  I think that people are falling back on the 'fedora legacy
> failed' argument, but I don't think it applies.

I would not say 'cannot'. I would say 'unwilling to'. This community
is unwilling to devote enough effort to sustain an additional longer
term branch.  Every organization has its limits. One of the worst
things a successful volunteer organization can do is overreach well
past its available manpower and do too much with too little simply
because they see a need in the community and want to make an impact.
There are brick and mortar volunteer organization in my town right now
that are learning the lesson the hard way.

Watching a successful organization that is making a positive impact on
the sorrounding community implode because the people in it care too
much and don't know when to say 'we can't do this or that with the
resources we have' is pretty painful to watch.  I'll be damned if I
sit on the Fedora project board and let this sort of unsustainable
growth in responsibility doom the project.

Legacy was not a failure... it was a key part of the process of
defining what the limits are with the resources we have. Now that we
have gone through that, the people who have survived the process have
a much better idea of what it takes in terms of a resource commitment
to pull it off.

I have absolutely no problem with another attempt at community effort
as a follow-up to what Legacy did. I just don't think its where this
community of contributors wants to contribute. I think at a minimum
there are 3rd support specialists out there with a business interest
in a Fedora LTS, or perhaps niche hardware vendors in the embedded
space which could be persuaded to leverage Fedora as a development
platform. Lots of unexplored area.

But I love being wrong, perhaps the community can go it alone now.
Prove me wrong. if you seriously want it, then perhaps we can dig into
institutional knowledge concerning Legacy's resource constraints as a
starting point for you to starting putting the necessary resources
together to make a serious stab at doing this.  But it will take
non-trivial effort. Legacy was a non-trivial affair and I'm not going
to personal support an effort that isn't at least as organized and
equipped as Legacy was.

>
> I think that having one LTS release could be made to work.  Here is an
> additional proposal
>
> Proposal:
>
> After the LTS release, wait 1 year (instead of 6 months) for the next
> Fedora release.  This would allow for:
>
> a) 1 deeper dev cycle every x shallow dev cycles
> b) a longer time to let the LTS 'steep' and become mature, focusing core
> group attention on the current release instead of having them chomp at
> the bit for the next go.
> c) mitigate the 'many simultaneous releases to support' issue

I do not like this proposal. In fact I loath it. Why? because it
delibrately takes focus away from the 'shallow' dev cycles.  I do not
think it is in the best interest to focus more attention on one
release than another. Why?  Because the components that we integrate
all have their own timescales. We take a year out at one point and
something like our Gnome or KDE ends up suffering as a result because
that one component's development cycle isn't synced to our development
cycle with a heart murmur.  No, we must do all we can to hold the line
on consistent time based releases so that upstream development
projects can rely on us to be there and be ready to integrate their
new bits every 6 months. The vast and varied development schedules of
the upstream projects drives our need for consistency in release
schedules.

-jef




More information about the devel mailing list