Hi,
The separation of trunk from feature developed provides many
advantages. It will allow those who really want a more esoteric
feature that hasn't been merged into a release 'roll their own' with
understanding that the code remains unsupported by the project.
Do need to have a strategy for resolving conflicts if more than one
feature has been agreed to be merged at the same time or do we simply
allow one feature in at time and, other features will need to update
thier code to work with the new core before they can be merged?
I thought about this since 1.2. I had the idea that we should do it
similar to airports and use merge-slots. A developer or an institution
can ask for a slot to add one ore many feature to trunk. The feature(s)
might run trought the process Tobias brought on list if we all agree. A
slot has for example one week where all approved feature can be merged
and the than all bugs should be fixed. Than after one week we have a
stable trunk again and the next one can merge. If trunk isn't stable
after week, the merge will be reverted and the applicant can ask for a
new slot.
That is very important. We had similar rules before, but I can't
remember that we really remove a comitted feature. Insted we often wait
a long time for fixes.
Nils
_______________________________________________
Matterhorn mailing list
Matterhorn@opencastproject.org
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
matterhorn-unsubscr...@opencastproject.org
_______________________________________________
