{"id":1246,"date":"2008-05-10T01:05:19","date_gmt":"2008-05-09T23:05:19","guid":{"rendered":"http:\/\/vizZzion.org\/blog\/2008\/05\/are-we-breathing-in-the-same-rhythm\/"},"modified":"2008-05-10T01:05:19","modified_gmt":"2008-05-09T23:05:19","slug":"are-we-breathing-in-the-same-rhythm","status":"publish","type":"post","link":"https:\/\/vizZzion.org\/blog\/2008\/05\/are-we-breathing-in-the-same-rhythm\/","title":{"rendered":"Are we breathing in the same rhythm?"},"content":{"rendered":"

Tom<\/a> and
\n Aaron<\/a>
\n discuss timing and release schedules, and development cycles. Aaron talks
\n about trunk\/ and freezes therein should follow a natural lifecycle. This assumes that
\n the whole KDE community lives and breathes as one individual, synchronised and all.
\n So a development-and-release-cycle forces all developers into one rhythm. Everyone
\n has to follow this one release rhythm. It’s a good idea, but I think we should also
\n make the lives of those easier that choose another breathing ryhthm.
\n There are a couple of things to consider here. The most obvious being that we need this
\n flexibility anyway. We rely on certain release mechanisms and interface stability
\n policies in other projects as well. (We partly solve this problem by providing abstraction
\n layers, think phonon and solid). Now the interesting case is that Phonon, which is new in
\n Qt’s 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle
\n in Qt, and a 6 months one in KDE. So one could argue that it’s a smart idea to breathe
\n in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
\n
This does not solve the initial problem I think, which I think is “different parts
\n of KDE have different heartbeats”. Neither Tom nor Aaron have really
\n questioned the way we currently deal with SVN before
\n releases, so I’ll put on my shiny pink asbestos suit and do it.<\/p>\n

\n What if we never froze trunk? Others (such as, incidentally
\n Qt) have no freezes in trunk\/ and it seems to be a popular and well-working development
\n style for some. When a release enters a freeze, a branch is created that will
\n be stabilised towards the release. trunk\/ at the same time stays open for feature
\n additions. The Golden Rule is “You don’t break trunk\/ (this is what branches are for)”.<\/p>\n

\n (For those not too intimate with development schedules of KDE: trunk\/ is frozen
\n roughly 2 months in advance of a release (supposedly every 6 months). After the
\n actual release, trunk\/ is opened again for new features. Features that take longer
\n than the allotted time be developed in a branch and moved into trunk\/ “when
\n they’re ready, but not during freeze”.)<\/p>\n

\n The obvious downside of this “It’s always summer in trunk” is that you need to
\n spend extra efforts to get people
\n to stabilise, i.e. working in a stabilise-branch rather than in trunk\/. It needs more
\n discipline, and probably puts some extra weight on the shoulders of those who simply
\n care about good KDE releases. But as we all agree,
\n SVN sucks for branching and merging. So right now we make it hard for people to work
\n with different branches (stable\/ and trunk\/).
\n It would allow those that need more time to
\n do their thing to stay in sync with latest features. Basically, it would allow for
\n different rhythms in the community. As this community grows and becomes more diverse
\n this might pay off in the end.
\n
New tools are on the horizon as well. Distributed version control systems allow
\n for a more flexible way of sharing code between peers.<\/p>\n

\n The thing is that we cannot really choose, people are using git anyway. And after
\n having used it for a bit, and git-svn to interact with svn, I have to say that it
\n makes a lot of things much easier. For one, it doesn’t force the commit policy of
\n the project (“don’t break trunk” maybe ;-)) on yourself or your team, and it makes
\n it easy to share code with others. That might want to work one a feature (or some
\n surgery) together, but others (those that don’t want to be affected by this surgery
\n just want their desktop to work. Now imagine these peeps, just start developing
\n features by sharing a number of git trees and committing features to trunk\/ when
\n they stabilise, i.e. presumably don’t cause regressions. It also nicely solves
\n another issue we had recently. Rafael needs some time to finish Goya (have it API
\n reviewed by Kevin ;-)), but Jeremy already wants to use this feature in
\n GetHotNewStuff2. Those three share a “review” branch, which is merged when
\n everyone’s happy (after having been announced on kde-core-devel. (Imagine
\n integration of some sort of peer review system, like review board with
\n this branch!). This development
\n style can partly be tested by a subproject, of course. This subproject can then
\n track trunk\/ from SVN and develops features in a distributed way, probably with
\n another branch as master that sits on top of it and tracks. It’s not really a
\n technical problem, after all, the tools should support the natural way of
\n breathing for the community. For git in particular, I see the steep learning
\n curve as one of the major show-stoppers right now. It would, at this point
\n simply make the barrier of entering a project much higher, which is not a good
\n thing. With distributed source code management, the question “Which one is
\n the authoritative copy?” becomes a purely social thing. In the SVN case, it’s
\n always the SVN server, in the DVCS (OMG!) case, it’s “who you trust”, that
\n would be the version we publish via SVN.<\/p>\n

\n Interestingly, the KDE’s Internationalisation people already work in a distributed
\n fashion. In the Netherlands for example, Rinse collects translations; that are sent to
\n him by the people in the translation team he reviews them and commits them to SVN.<\/p>\n

\n Does this whole mess of an idea also contain a solution for “synching downstream”?
\n One of the reasons why the Release Team initially decided to adopt 6 months
\n releases is to make it easier
\n for downstream (distributions, for example) to ship a recent version of KDE.
\n The thing is that those distributions also have different heartbeats, OpenSuse comes
\n 8-9 monthly, Fedora comes 6 monthly, others as well. Now we’re trying to
\n sync with upstream, in
\n different heartbeats and downstream in different heartbeats. Right now, we have
\n the unfortunate situation that we’re just too late for OpenSuse 11 (which is really
\n one of the symptoms of “heartbeats out of sync”). At last year’s Akademy, Mark
\n Shuttleworth brought up the idea of synching release over the whole Free software
\n stack. While this is a nice vision, I do not see this happen ‘globally enough’ so
\n that it really works. The trend
\n in the Free Software<\/a> world seems to be to move to a more distributed way
\n of development.<\/p>\n

\n This “we all breathe synchronously” might be one of the things that ties us
\n together. We’ve seen this a lot in the time up to 4.0. That was where we as
\n a community acted as one and lifted KDE from ‘utterly broken’ into a
\n releasable desktop. In KDE 4.x, things are fundamentally different. With all
\n the new frameworks and libraries solidly in place now we we want this to be a
\n stable platform for a long time. That means we develop features on top of it
\n and fix bugs in the infrastructure and extend it – not break it. Basically that’s
\n the “Binary Compatible until KDE 5.0” promise.<\/p>\n

\n Moving from one, proven style of development to another is something we
\n should not take lightly. On the one hand it would help us solving some
\n scalability challenges in the community (such as too many different people,
\n expectations, needs for their product and whatnot) and adopting new styles
\n of collaboration in a community where you’re free to share.<\/p>\n

\n Things such as new ways of working together and the ever more diverse community’s
\n needs, expectations and lifestyles are not something we can ignore. We need to
\n constantly look at ourselves and our environement and think about how we can
\n improve it. Probably not one big step (“starting tomorrow we never freeze
\n trunk again, promised”) but hundreds of little baby steps.<\/p>\n

\n","protected":false},"excerpt":{"rendered":"

Tom and Aaron 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… Continue reading Are we breathing in the same rhythm?<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29],"tags":[],"class_list":["post-1246","post","type-post","status-publish","format-standard","hentry","category-kde"],"_links":{"self":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts\/1246","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/comments?post=1246"}],"version-history":[{"count":0,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts\/1246\/revisions"}],"wp:attachment":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/media?parent=1246"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/categories?post=1246"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/tags?post=1246"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}