Here are the problems I see with your approach:
- People have to have both a 5.1 and HEAD checkout (a lot of people probably don't keep both around).
- People have to know how to merge with CVS (a lot don't
know how to do it cleanly).
- It's non-trivial to do the merge for multiple files
and it's easy to miss one or two.
- If you are merging just your changes it can have conflicts that arise from past changes on HEAD or the release which were unmerged (which if we continue to do bulk merges
is not as much of an issue).
- If someone misses merging a change how do we know?
With the current rules we are very confident that nothing gets lost with the primary risk being that a conflict gets resolved the wrong way, at the expense of having HEAD be somewhat out of date with respect to the release branch bug fixes.
Under your suggested methodology, the risk would be
code gets lost, individuals merging make the wrong decision merging conflicts.
I would dispute the assertion that the overall error rate would decline if people resolved their own conflicts -- I have been merging roughly monthly for about a year, with a typical merge affecting ~800 files and there have been about 10 conflicts that I am aware of
being done the wrong way of 1270 commit sets, affecting 7500 files). Depending on how you calculate it that error rate is somewhere between 1% and .1%; I would claim that if you had the 30 people who had done those commits also responsible for the merges on each commit set, that the
error rate would be much higher (and I guarantee we would have lost code/bugfixes along the way).
In order for your approach to work better someone would
have to take responsibility for making sure that peoples
commits were merged properly and if not remind them to
do the merge (and teach people how to properly do merges).
And also periodically make sure that no code had been lost.
I am happy to do the merges with the commit guidelines we have now and I am confident in claiming we are not losing
code or bug fixes. Under your proposed solution I would
not be willing to take that QA role since a) it would be
a lot more work, and b) I would not be at all confident that
code would not be slipping through the cracks. When I said it would take more resources that's what I meant.
This has come up before and I still don't think there are that many instances of things fixed in 5.1 which have not
been fixed on HEAD. If you want to merge to HEAD more frequently then I am only to happy to have you carry out
a merge (and tell you how I have been doing the merges to date so it's all done consistently).
If you want to propose changes to the commit guidelines then submit
a TIP and lobby the OCT members to vote for it. I would say
that unless you found the resources to insure your approach delivered better overall quality that what we do now I personally would vote no.
