I have to respectfully disagree with much of Mark's vision. I do agree that short predictable
release cycles are good. Release cycles should be short enough that if something misses a
release window waiting until the next window is not a major problem. Allowing code to be
released when it is ready and not generating pressure to release something before it is ready.
Arguments that say we should do X now because another project is going to use the release we
are preparing are completely inappropriate. If code can not stand on it's own merits it
should not stand.
Much of what Mark has described is process oriented and ignores the developer who makes code
changes only because they have an itch. If you don't make room for itch scratching developers
you loose much of the vibrancy and vitality you otherwise would have had.
I find the idea of multiple distributions coordinating intentionally on a single release of a
product with the knowledge of the community of that product suspicions. This seems to say to
the software development projects out there: We are the gate between you and users tremble
before us.
However I slice it I can not see a project caring when a meta project will use them as a good
thing. It just feels like an excuse to be slopping either because you don't expect your
software to get used or because of extra pressure to include changes because your software
will get used.
Meta projects that have frequent regular releases of what ever is ready when they are building
a release do seem to be a good thing, as that removes the pressure from caring from other
projects. You know if you release something even if it doesn't get used now it will get used
soon enough that it doesn't matter.
Posted Jul 31, 2008 9:21 UTC (Thu) by jamesh (guest, #1159)
[Link]
The whole point of keeping a pristine trunk and doing development on branches is that you keep
the trunk in a state where it could theoretically be released at any time. Of course, this
does not remove the need for QA before doing a release.
As feature work is being done on branches, it does not affect the trunk until it is complete
and merged. If it is not ready for a release, then it doesn't get merged til after the
release (and this isn't such a bad thing because you know when that next release will occur).
OLS: Shuttleworth on free software development
Posted Jul 31, 2008 10:08 UTC (Thu) by NAR (subscriber, #1313)
[Link]
I might be wrong, but I guess nowadays most users do not download software from e.g.
sourceforge and use it - they get the software from the distribution. In other words: if e.g.
X.org releases a new version of X today, users will only start to use it when the next Fedora,
Ubuntu or SuSE is released with the new X. Also, if the current Fedora, Ubuntu or SuSE
includes three different versions of X, the maintainance load on the X developers is three
times bigger because they get bugs from three different releases (of course, the bugs may be
the same, but they still need to test the fixes). So I think it makes sense to harmonize
releases.
OLS: Shuttleworth on free software development
Posted Jul 31, 2008 22:08 UTC (Thu) by giraffedata (subscriber, #1954)
[Link]
if the current Fedora, Ubuntu or SuSE
includes three different versions of X, the maintainance load on the X developers is three
times bigger because they get bugs from three different releases
Don't they just largely ignore reports against releases other than current? I mean, a developer tries to apply a bug report to the current release, but if it isn't easy, he tells the reporter to reproduce it in current code. And if the developer creates a fix, he tests it and releases it in the current release. Any support for older releases shipped by packagers has to come from those packagers.
Now, where a project actually maintains 3 release streams (i.e. there is a current 1.x, a current 2.x, and a current 3.x), it's probably because it's in the project's best interest to have users of all three at once -- the 1.x is more stable than the 3.x, so you want people to use 1.x if they can and reduce the total bug handling burden.
OLS: Shuttleworth on free software development
Posted Aug 1, 2008 7:14 UTC (Fri) by NAR (subscriber, #1313)
[Link]
Don't they just largely ignore reports against releases other than current?
Probably, and that's pretty sad.
Any support for older releases shipped by packagers has to come from those packagers.
But I wonder that how many package maintainers are up to this task, especially with bigger software like OpenOffice...
OLS: Shuttleworth on free software development
Posted Aug 1, 2008 15:59 UTC (Fri) by giraffedata (subscriber, #1954)
[Link]
Any support for older releases shipped by packagers has to come from those packagers.
But I wonder that how many package maintainers are up to this task, especially with bigger software like OpenOffice...
Well, it's not the task you may be imagining. It's very little of debugging and writing code. Rather, it's tracking the fixes in the current release and backporting ones you need, and reproducing problems against the current release and reporting those upstream. So it's more of a user task than a developer task.
I think I may see Shuttleworth's point now. If upstream is going to stop maintaining Release N and start maintaining Release N+1, it's nice for downstream if it happens at the same time that downstream stops maintaining its package that includes Release N and starts maintaining one that includes N+1. That way, nobody has to maintain Release N.
If and only if all the upstream projects switch at the same time, it's possible for all the downstreams to pick that time to switch as well.
OLS: Shuttleworth on free software development
Posted Aug 7, 2008 18:48 UTC (Thu) by renox (subscriber, #23785)
[Link]
In theory you're right, in practice .. things may be different!
To fix an issue in zebra, I had to find myself the patch in quagga (a fork of zebra) and tell
the distribution (that we pay quite a lot for support) to integrate it.
Maybe other distribs are better, I don't know, but let's just say that I wasn't impressed by
this one.