Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:

> My fundamental argument is there's a bit of a
> disconnect between our release process - which is sort of aping the way
> a stable general-purpose OS would be released, but on fast-forward and
> with far fewer resources - and our actual goals for the project and the
> standards we really enforce. We don't _need_ the heavy, constant release
> cycle we currently employ in order to deliver the good things we already
> currently deliver.

Sorry, couldn't resist one more note on this; again with the emphasis on
'big picture' and 'historical perspective' that I like, I think it's
interesting to consider that the development schedule we use at present
is still more or less what Red Hat Linux was using, what, a decade ago?
I've been using Linux since around that time - 2000/2001 - and the 'six
month stable release cycle' was the norm even _then_. Yet back then
'Linux' was a far smaller world than it is now and far more static. In
recent releases the level of change has been, put into perspective,
frenetic. We seem to do massive rewrites on one fundamental chunk of
infrastructure after another. udev was considered a massive change back
in the day, which distros took years to adjust to; now we seem to toss
out bits of the bedrock on a weekly basis (hyperbole again, I know). We
seem to have been rewriting the whole cluster of systemd+udev
+udisks/DeviceKit+PolicyKit+dracut+plymouth+ConsoleKit - that whole ball
of wax - more or less constantly for several years (you may notice two
of the components in that list have been introduced and thrown away
within that space of time...one of them has been obsoleted *twice*), the
churn in that stack is crazy. We re-wrote the installer's storage code,
stopped for twenty seconds to take a breath, then introduced a new
bootloader and switched to GPT disk labels at the same time for an
encore. Now we're rewriting the entire installer UI...and we're planning
to switch to a revolutionary new filesystem whose userspace implications
have barely been mapped out...for the next release (I know this isn't an
official plan yet, but it's the stated intention of the btrfs devs). We
did the big change to kernel modesetting for graphics drivers. We
introduced PulseAudio. GNOME 3 and KDE 4 showed up. In the meantime
we've written and introduced an entire virtualization stack into the
distro, and added all kinds of other ambitious new features. And I'm
sure I'm not even scratching the surface. It kind of feels like for the
last five years we've been rewriting more or less the entire
distribution from top to bottom every few months (and this applies
outside of Fedora, albeit to a lesser extent, as well). It could be
memory playing tricks on me, but I'm pretty sure we didn't have anything
like that churn rate back when the six month release cycle became the de
facto 'industry standard' a decade or more ago.

This doesn't necessarily link into the 'rolling release model' argument
at all, it just seemed like an interesting perspective to keep in mind
in relation to the overall questions we're looking at here.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux