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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
