On 31/05/11 23:13, Brion Vibber wrote:
I tend to agree that a more active 'pull good
fixes& features in from
feeder branches' model can be helpful, for instance in allowing individual
modules, extensions, etc to iterate faster in a shared-development
environment without forcing the changes to trunk/mainlines's production
deployment& release channels until they're ready.
What prevents us to actually implements this? We could just restrict the
/trunk/ to a few merging people, they will only take care of merging
revisions set from other branches.
Developers then build their fixes / features in their own branches and
get it reviewed / signed-off by others. Once done, it is submitted to
the merge team.
This is much like the REL branches which only a few people are able to
merge trunk changes in. Just with another layer :-)
The VCS would be up to the developer (thus solving the "migrate from svn
to git" issue in the meantime). Subversion will only be used to actually
merge patch sets in trunk or REL branches.
But these need to be combined with really active,
consistent management;
just like keeping the deployment& release branches clean, working, and up
to date consistently requires a lot of attention -- when attention gets
distracted, the conveyor belt falls apart and fixes& features stop reaching
the public until the next giant whole-release push, which turns into a
circus.
Then we need merge windows. A date by which everyone would have to make
sure their patch is ready: tested heavily, reviewed by people actually
knowing the part of code impacted, test written, style fixed, i18n ...
If the patch does not make it in the current merge windows, it will
apply for the next one.
--
Ashar Voultoiz