Hi Tobias,
thanks you for writing the proposal. And I give a +1 for it.
I see a few open questions:
- Are we staying with lazy consensus about a new feature is nobody is
answering in a new feature announcement? (3 weekdays)
- Is a majority needed or is any vote against a new feature stopping it?
- What happens if nobody is reviewing the new code voluntary?
- Is the initial commiter responsible if later on we notice that his
code breaks something?
- What happens with probably small tasks that are not bugs? For example
upgrading the Atom Feed to the 1.0 version (what I hope will not be too
much to do)? Or adding new unit or integration tests...
I would guess that it is an optimistic view that the trunk is always
ready to release with this new approach as intesive QAing always
bringing up new bugs. But I think your proposal is going in the right
direction and we will hopefully speed up the release process by this.
Thanks
Rüdiger
Am 16.12.2012 15:24, schrieb Tobias Wunden:
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]
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: [email protected]
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
