First off, thank you for bringing this to list. I know I was asked to do so after our last meeting, but I just haven't had the chance. I think this proposal, or something very similar is what we should use once 1.4 is released. My formal job description is QA manager not release manager, but I'm spending a large amount of my time doing release management duties. This proposal would simplify things because each feature would have its own sub-RM who would then work with the full RM when in a final release cycle. I am hoping that post-1.4 I can concentrate more on my QA duties, so we need some kind of way to spread the workload around a bit (if not completely!). With that in mind, perhaps I can play devil's advocate to your position:
On 12-12-16 08:24 AM, Tobias Wunden wrote: > 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. Who determines who owns a given branch/feature? What happens to those which don't have anyone who wants to own them? > 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. So to clarify, the workflow is: work in branch -> branch QA process -> branch release -> nominate for inclusion in trunk -> trunk QA process (verification) -> trunk -> release I think we need a better name for branches (say... features?). But this does bring up a question: Release X of a given feature will be included for Matterhorn 1.5, but release Y (Y > X) will not be unless someone nominates it for inclusion? So we would never upgrade a feature if no one says we want to include the newer version? Or is the nomination process only relevant for *new* features? > -- > > [ 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. I disagree with this, although I'm not sure I have a better counter-proposal. I'm worried we will run the risk of someone fixing an issue, and which then causes (or exposes) another issue much like what we had during the 1.4 release cycle. > 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. I agree, and it's especially frustrating when I can't answer someone when they ask when a release is expected. What we have now clearly does not work very well, and a switch to a smaller focus is the right direction. G > Looking forward to comments. > > Tobias > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
