This link has been bookmarked by 1 people . It was first bookmarked on 29 Sep 2008, by Daniel Jomphe.
-
29 Sep 08
-
The centralized development system in Subversion's trunk doesn't support team-based development very well
-
Furthermore we're still looking for more contributors, so lowering the barrier for entry is another important concern.
-
We will have to allow for more diversity and we must be able to accommodate individual workflows.
-
Companies have their schedules and obligations, and what is stable for one user or developer is unsuitable for another.
-
Together with new tools for collaborating, new development models are emerging.
-
And we have an increased need for flexible and efficient collaboration with third parties and other Free Software projects.
-
KDE's development process should be agile, distributed, and trunk freezes should be avoided when possible.
-
We should set up a process aimed at adaptation and flexibility, a process optimized for unplanned change.
-
Currently, our release cycle is limiting, up to the point of almost strangling our development cycle.
-
Our current release process, depicted in the graphic below, can be described as using technical limitations to fix what is essentially a social issue: getting people into "release mode".
-
many developers complain about Subversion making it hard to maintain "work branches" (branches of the code that are used to develop and stabilize new features or larger changes in the code), subsequent code merges are time-consuming and an error-prone process.
-
The proposal would essentially remove these limitations, instead relying on discipline in the community to get everyone on the same page and focus on stability. To facilitate this change, we need to get the users to help us: a testing team establishing a feedback cycle to the developers about the quality and bugs. Using a more distributed development model would allow for more flexibility in working in branches, until they are stabilized enough to be merged back to trunk. Trunk, therefore, has to become more stable and predicable, to allow for branching at essentially any point in time. A set of rules and common understanding of the new role of trunk is needed. Also, as the switch to a distributed version control system (which is pretty much mandatory in this development model) is not as trivial as our previous change in revision control systems, from CVS to Subversion. Good documentation, best practice guides, and the right infrastructure is needed.
-
KDE's current system of alpha, beta and release candidate releases will be replaced by a system which has three milestones:
-
The Publish Milestone
This is the moment we ask all developers to publish the branches they want to get merged in trunk before the release. Of course, it is important to have a good overview of the different branches at all times to prevent people from duplicating work and allow testers to help stabilize things. But the "Publish Milestone" is the moment to have a final look at what will be merged, solve issues, give feedback and finally decide what will go in and what not.
-
The Branch Milestone
This is the moment we branch from trunk, creating a tree which will be stabilized over the next couple of months until it is ready for release.
-
The "tested" milestone represents the cut-off date. Features that do not meet the criteria at this point will be excluded from the release. The resulting codebase will be released as KDE 4.x.0 and subsequently updated with 4.x.1, 4.x.2, etc. It might be a good idea to appoint someone who will be the maintainer for this release, ensuring timely regular bugfix releases and coordinating backports of fixes that go into trunk.
-
Under discussion are ideas like having some kind of "KDE-next" tree containing the branches which will be merged with trunk soon; or maybe have such trees for each sub-project in KDE. Another question is which criteria branches have to meet to get merged into the "new" trunk.
-
Having a page on TechBase advertising the different branches (including a short explanation of their purpose and information about who's responsible for the work) will go a long way in ensuring discoverability of the now-distributed source trees.
-
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.