[Zope3-dev] Re: [Zope-Coders] Re: [Zope-Checkins] CVS: Zope3/src/ZConfig/tests - test_schema.py:1.10.2.1

[Andreas Jung]

--On Dienstag, 11. Februar 2003 20:36 -0500 Tres Seaver <tseaver@zope.com> 
wrote:


>
> I would like to lobby the zope-coders community for an explicit ban on
> this practice, with the ban to be waived only in very exceptional cases.
> "Back-merging" from the HEAD to your branch is a dubious practice at
> best, even for branches which expect to outlive the merge by a
>
>   - The "backmerge" checkins create noise for those who review the
>     checkins;  your backmerge created some 60+ totally spurious
>     messages, followed by another 60+ two hours later as you merged
>     them in together with the "real" changes.  I try hard to read
>     the checkins for both the Zope and the Zope3 repositories, which
>     I consider to be a significant contribution to the code quality
>     under the rubric, "Given enough eyes, all bugs are shallow."  Huge
>     checkins like these defeat that practice, as I can't find the
>     "substantial".changes amid the noise.

This is a question a question of the CVS notification mechanism but
not of the way how we use the CVS. I asked about a year ago to have
a way to filter to distinguish between checkins from "private" and
"official" branches. And there was common agreement that there is
no such need. A private developer branch is used to seperate the
developers work from the other one. As developer I really don't like
to care about the traffic that is caused by my work on "my" branch.
I care about the work but not about the noise.


>
>   - The "backmerged" changes obscure the intent of the branch:  it is
>     now impossible to use the CVS machinery to tell just what changed
>     on the branch.

Sometimes backmerging is necessary when the HEAD has changed a lot and
when you are not able/allowed to merge stuff back to the HEAD.

>
>   - What you really wanted to do today was to get your sandbox
>     to the HEAD, then merge your branch to it, taking only the
>     "minimal" diffs on the branch.  You could've then tested and
>     checked in on the head, and marked the branch as "retired".

This is not always straight forward when your changes for a feature are
spread across the sources. Especially when you don't have green
light to merge your stuff to the HEAD. For the reST integration
I had to backmerge once or twice since the proposal has not been
accepted for a while.

I agree with Tres that noise from private branches sucks but
in the first place I suggest to fix the notification machinery
by keeping a list a branches that are "official" Zope branches
(Zope-2_X-branch). Notifications from official branches should be
marked somehow (in the subject) and it should be possible to
write a filter rule to distinguish between official and private noise.

Andreas