[Twisted-Python] on avoiding our policy: casual fixes branch

[Mary Gardiner]

On Thu, Mar 23, 2006, glyph at divmod.com wrote:
> For now, because defining "trivial" is so hard (what if your docstring fix 
> has a typo which actually changes some code which breaks some tests?), and 
> it is always too tempting to classify "just this one" branch as "trivial" 
> because the author wants to merge it really fast and it's not _too_ long, 
> the proposed solution is to have a shared "minor fixes" ticket and branch, 
> which should be reviewed once a week or so, and merged en-masse.

I don't know that I agree in general that we should allow trivial[1]
merges without branching or review, but I don't agree with this proposal
either, it seems *even more* bolted on to the "file bug, branch, fix,
review, merge" model as the "decide it's trivial, fix in place". If
nothing else, I've done code review too, and there's quite a lot of
headaches involved in reviewing 37 unrelated trivial changes in one go,
because they're unrelated and it involves 37 context switches.

Why don't we try the stricter model (no commits to trunk that aren't
merges, each merge to trunk has its own branch and its own bug) for a
few weeks and then we can see:
 1. how angry this has made everyone
 2. how many changes are backed up in review

(This will require some people to keep notes on things like "noticed
typo in docstrings, did not fix because did not have 30 minutes"
though.)

If the answers to 1 and 2 are "very" and "lots"... well, I still don't
think the "minor fixes" ticket and branch idea will be a great solution,
but we'd have some data to evaluate it on.

-Mary

[1] Incidently, describing something as 'hard to define' is not an
argument against anything. Now that I'm a computational semanticist
again, I can tell people (although not on list) in excruciating, gut
wrenching detail, just how hard any damn thing is to define, especially
when you want bright line definitions as we do here. If you want to try
this argument, you need to propose some 'reasonable' definitions first
and then explain why they are, in fact, so much suck. Andrew's attempt
is reasonable, although I would have thought "non-semantic small changes
to documentation" was better than "small changes to documentation."
Now... define 'non-semantic' and we're done! ;)