"A day without sunshine is like a day without orange juice.
Are we breathing in the same rhythm?
discuss timing and release schedules, and development cycles. Aaron talks
about trunk/ and freezes therein should follow a natural lifecycle. This assumes that
the whole KDE community lives and breathes as one individual, synchronised and all.
So a development-and-release-cycle forces all developers into one rhythm. Everyone
has to follow this one release rhythm. It's a good idea, but I think we should also
make the lives of those easier that choose another breathing ryhthm.
There are a couple of things to consider here. The most obvious being that we need this
flexibility anyway. We rely on certain release mechanisms and interface stability
policies in other projects as well. (We partly solve this problem by providing abstraction
layers, think phonon and solid). Now the interesting case is that Phonon, which is new in
Qt's 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle
in Qt, and a 6 months one in KDE. So one could argue that it's a smart idea to breathe
in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
What if we never froze trunk? Others (such as, incidentally
Qt) have no freezes in trunk/ and it seems to be a popular and well-working development
style for some. When a release enters a freeze, a branch is created that will
be stabilised towards the release. trunk/ at the same time stays open for feature
additions. The Golden Rule is "You don't break trunk/ (this is what branches are for)".
(For those not too intimate with development schedules of KDE: trunk/ is frozen
roughly 2 months in advance of a release (supposedly every 6 months). After the
actual release, trunk/ is opened again for new features. Features that take longer
than the allotted time be developed in a branch and moved into trunk/ "when
they're ready, but not during freeze".)
This does not solve the initial problem I think, which I think is "different parts
of KDE have different heartbeats". Neither Tom nor Aaron have really
questioned the way we currently deal with SVN before
releases, so I'll put on my shiny pink asbestos suit and do it.
The obvious downside of this "It's always summer in trunk" is that you need to
spend extra efforts to get people
to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more
discipline, and probably puts some extra weight on the shoulders of those who simply
care about good KDE releases. But as we all agree,
SVN sucks for branching and merging. So right now we make it hard for people to work
with different branches (stable/ and trunk/).
It would allow those that need more time to
do their thing to stay in sync with latest features. Basically, it would allow for
different rhythms in the community. As this community grows and becomes more diverse
this might pay off in the end.
The thing is that we cannot really choose, people are using git anyway. And after
having used it for a bit, and git-svn to interact with svn, I have to say that it
makes a lot of things much easier. For one, it doesn't force the commit policy of
the project ("don't break trunk" maybe ;-)) on yourself or your team, and it makes
it easy to share code with others. That might want to work one a feature (or some
surgery) together, but others (those that don't want to be affected by this surgery
just want their desktop to work. Now imagine these peeps, just start developing
features by sharing a number of git trees and committing features to trunk/ when
they stabilise, i.e. presumably don't cause regressions. It also nicely solves
another issue we had recently. Rafael needs some time to finish Goya (have it API
reviewed by Kevin ;-)), but Jeremy already wants to use this feature in
GetHotNewStuff2. Those three share a "review" branch, which is merged when
everyone's happy (after having been announced on kde-core-devel. (Imagine
integration of some sort of peer review system, like review board with
this branch!). This development
style can partly be tested by a subproject, of course. This subproject can then
track trunk/ from SVN and develops features in a distributed way, probably with
another branch as master that sits on top of it and tracks. It's not really a
technical problem, after all, the tools should support the natural way of
breathing for the community. For git in particular, I see the steep learning
curve as one of the major show-stoppers right now. It would, at this point
simply make the barrier of entering a project much higher, which is not a good
thing. With distributed source code management, the question "Which one is
the authoritative copy?" becomes a purely social thing. In the SVN case, it's
always the SVN server, in the DVCS (OMG!) case, it's "who you trust", that
would be the version we publish via SVN.
Interestingly, the KDE's Internationalisation people already work in a distributed
fashion. In the Netherlands for example, Rinse collects translations; that are sent to
him by the people in the translation team he reviews them and commits them to SVN.
Does this whole mess of an idea also contain a solution for "synching downstream"?
One of the reasons why the Release Team initially decided to adopt 6 months
releases is to make it easier
for downstream (distributions, for example) to ship a recent version of KDE.
The thing is that those distributions also have different heartbeats, OpenSuse comes
8-9 monthly, Fedora comes 6 monthly, others as well. Now we're trying to
sync with upstream, in
different heartbeats and downstream in different heartbeats. Right now, we have
the unfortunate situation that we're just too late for OpenSuse 11 (which is really
one of the symptoms of "heartbeats out of sync"). At last year's Akademy, Mark
Shuttleworth brought up the idea of synching release over the whole Free software
stack. While this is a nice vision, I do not see this happen 'globally enough' so
that it really works. The trend
in the Free Software world seems to be to move to a more distributed way
This "we all breathe synchronously" might be one of the things that ties us
together. We've seen this a lot in the time up to 4.0. That was where we as
a community acted as one and lifted KDE from 'utterly broken' into a
releasable desktop. In KDE 4.x, things are fundamentally different. With all
the new frameworks and libraries solidly in place now we we want this to be a
stable platform for a long time. That means we develop features on top of it
and fix bugs in the infrastructure and extend it - not break it. Basically that's
the "Binary Compatible until KDE 5.0" promise.
Moving from one, proven style of development to another is something we
should not take lightly. On the one hand it would help us solving some
scalability challenges in the community (such as too many different people,
expectations, needs for their product and whatnot) and adopting new styles
of collaboration in a community where you're free to share.
Things such as new ways of working together and the ever more diverse community's
needs, expectations and lifestyles are not something we can ignore. We need to
constantly look at ourselves and our environement and think about how we can
improve it. Probably not one big step ("starting tomorrow we never freeze
trunk again, promised") but hundreds of little baby steps.
New tools are on the horizon as well. Distributed version control systems allow
for a more flexible way of sharing code between peers.
[ Sat, 10 May 2008 01:05:19 +0200 ] permanent link
This weblog does currently not offer the option to comment. I would be happy to receive an email with your thoughts.
23-11-2007, 18:44 h
© Sebastian Kügler