Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

Posted Apr 21, 2009 23:11 UTC (Tue) by gbutler69 (guest, #54063)
In reply to: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) by iabervon
Parent article: Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

It's not clear to me how a DVCSS eases these problems for the development of a distribution with Hundres, if not thousands, of independently developed software applications, libraries, and infrastructure, of which, the Kernel is just one part.

I think the challenges are somewhat different and not so easily addressed as your comment would seem to indicate.

Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

Posted Apr 22, 2009 0:31 UTC (Wed) by iabervon (subscriber, #722) [Link] (3 responses)

I was primarily thinking of the development model for each of the individual projects (e.g., GNOME or KDE, or even parts of them), not a distribution, which is a very different sort of project.

But I think that the same fundamental point applies. Ubuntu could decide, today, that Upstart will entirely replace /etc/init.d in April 2010. Package owners could start working on the 10.04 versions of their packages today, and Upstart developers could start looking for problems and conflicts between these packages. Packages that actually have no problems at all could use Upstart in 9.10, but most packages probably would have problems and the 9.10 versions would use the old-style init scripts.

Or possibly Ubuntu wouldn't have a good idea of when a complete system would be able to use exclusively Upstart, so they'd have an Upstart topic branch that's not destined for any particular release. As stuff gets converted and tested, more and more packages get checked off. But until they're all checked off, every release uses the compatibility code for the old style. When everything's checked off, the topic gets merged into the mainline, and the next release drops the old style.

It's not strictly a matter of using a DVCS, but it's a matter of being able to branch and merge effectively.

(I actually have no idea how Upstart is going, but the same principle applies to anything that takes a lot of distribution developer time.)

Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

Posted Apr 22, 2009 1:27 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (2 responses)

A separate feature branch for upstart?

Now, that translates to a separate packages pool and a separate installation CD. Quite easy to manage, indeed. It doesn't scale.

Furthermore, how do you test upgrading between versions? The more branches you have, the many more testing scenarios you now have.

Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

Posted Apr 22, 2009 2:45 UTC (Wed) by iabervon (subscriber, #722) [Link]

This wouldn't be a general-availability branch, with an installation CD and official package pool and so forth. It would exist exclusively for developing and testing upstart (and packages' upstart scripts), and only be in the version control system. Once it matured to a release candidate state (i.e., it could work as is, but needs testing), it would be merged into the mainline, and only then would there be any (numbered, releasable) version that included its changes.

To be excessively pedantic, every single developer (with any version control system) has their own branch whenever they have uncommitted changes in their working directory. There's a version of the system that has different content from any other version, that diverges from the official main branch. It just doesn't have any infrastructure behind it, and exists only briefly (until the developer gets it committed/merged into the main branch). My point is that it could have a little more infrastructure (a meet point for multiple developers to share related work) and stay in this state for a long time (since it won't get lost with multiple people working on it and the shared location), and this would allow work on some topic to last longer than a release cycle when necessary.

Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons)

Posted Apr 22, 2009 8:05 UTC (Wed) by epa (subscriber, #39769) [Link]

Now, that translates to a separate packages pool and a separate installation CD.

Yeah, why not? If this is difficult to manage now (as in the days of CVS, branches of a single project were difficult to manage) then tools can be written to make it easy. The 'upstart' branch or any other feature branch wouldn't be an official release of the distribution, so it would not be necessary to push packages to mirror sites or offer a guaranteed upgrade path.