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
