2009-06-20

RFC: New paradigm for Ubuntu release cycle

Would it be possible to break Ubuntu into two independent sections: 'Interface' and 'Infrastructure'?

Think about Interface, as everything the ordinary user 'wants' to be updated in the 6 month cycle (GUI, apps, kernel, etc), and Infrastructure as everything else that keeps the engines running, i.e., glibc, and the like.

I think it would be nice if Ubuntu could make 6 month releases be binary compatible with each other, and in order to do that, you must compile everything with the same library versions. I can see why we might want a newer kernel every now and then, but why do we really need to to upgrade glibc every 6 months? Do the applications really need all the new features all the time? Can there be a separation of some sort so that some packages be upgraded, and others preserved? I think it would benefit all, since using the same packages for two or three (or so) releases would decrease the support burden, security- and stability- wise.

It would also have many other side benefits: easier to backport packages, reduce storage space in mirrors, and reduce upgrade issues (since there will be less packages being upgraded). It would definitely be a plus in the corporate side, where ISVs would have a much more stable infrastructure to develop on, and much closer to the two most popular closed OS approaches.

One drawback would be that bugfixes would be harder to get propagated downstream, and longer maintenance cycles sometimes aren't easy to do, specially in open source community, where development is often a continual burst of unordered creativity. It would also not be necessarilly easy to decide where to draw the line (e.g., would poppler/cairo be interface, or infrastructure? and XUL? GTK?).

Still, I think this would be an improvement, and this post is intended to draw healthy discussions in mailing lists and ubuntu related fora.

No comments:

Post a Comment