At last week's developer meeting, we were debating why it took the community so long to get 1.4 done.
One of the major obstactles that were identified during the meeting is that right after 1.3, everyone was rushing in the code that had been developed on the side during the (rather long) release time of 1.3, and it turned out that not all of the changes had been thoroughly tested and not all of them had been fully thought through, which is why we ended up with a big chunk of code that was no longer manageable and that left us with one choice only, which was working through the whole codebase and fixing all of the bugs in order to get to a stable codebase again. In order to not get there again, the attending developers came up with the following #proposal and are looking for feedback from the other developers as well as adopters: [ 1 ] Feature development in branches and review and merge by a peer committer New features should *only* be developed in branches. Once development is finalized, the release process of this feature is started, ending with a merge of verified and QA'ed feature to trunk, while the feature has gone through the reiew of a peer committer. This process will put the community into the position to *always* be able to perform a release off the current trunk. In addition, code will be looked over by a second pair of eyes, which is always a good thing. a) The feature's development lead proposes to the community (by sending in e-mail to this list) to integrate the feature into the release version of Mattterhorn. The e-mail contains links to the relevant tickets as well as to documentation on the wiki and describes in details the areas of Matterhorn that are affected by the feature. b) The community discusses on list (the initial thread should be spawned both on the users and the developers list) whether the feature should be included (or skips the discussion if it is obvious to everyone that the feature should be merged). During this phase, adopters and developers are asked to review the feature from a functionality perspective. The community can make suggestions on how to improve or tweak the feature in order to increase its overall value. The feature's developers may or may not decide to incoroporate these suggestions into the current version. c) Once discussion on the users and developers list has come to an end, and the feature developers are happy with the current state of their work, they initiate a vote on the committers list (or ask a committer to do it on their behalf) for feature inclusion and ask for a peer committer to perform the merge and attest proper functioning of the feature according to the documentation as well as test coverage and inclusion in the integration tests where feasible. d) The peer committer creates a branch of the current trunk "release", merges the feature branch into the release branch and starts the feature verification. Fixes or adjustments are made on the feature branch and are merged into the release branch continuously. Ideally, this process should not take a long time and is therefore unlikely to get out of sync with the current trunk. Once everything is working as expected, the peer committer merges the release branch into trunk, perfoms one final round of verification and announces the availability of the feature in trunk to the developers and users list, and the feature developer is asked to add links to the documentation to the upcoming relese page. -- [ 2 ] Bugs are committed to trunk Only bugfixes should be committed to trunk directly, and committers are asked to be sensitive about the differentation between bugfixes and the introduction of new features. If unsure, ask on list, pointing to the JIRA ticket and the proposed solution. Keep in mind that the overarching objective is that trunk not only compiles and passes unit and integration tests, but also *always" is in a releasable state. Everything that would put this objective at risk *must* happen in a branch and be merged to trunk with care. -- It is obvious that this way of merging functionality into trunk is a bit slower than before, where everyone was able to move code in at will. However, the downsides of this approach have become very visible over the last year, and I am sure not too many committers are happy with this situation, especially as committing institutions can never be sure when a feature will make it into the next official release. Today, regardless of how much effort an institution is willing to put into a feature, in order to guarantee a timely release including the feature, they also need to set aside an unknown number of hours for fixing hundreds of unrelated issues so the release can get out. This is obviously not motivating at all and hinders development of new features in public, because institutions are not willing to invest unlimited amounts of resources just to share their work with others. Looking forward to comments. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
