All very good points, Julian! Very much agreed. Thanks.
I think the heart of the problem lies in "what *style* is this
branch?" as you note below:
2008/10/23 Julian Foad <julianfoad_at_btopenworld.com>:
>...
> Does that matter? Maybe that would be better because we would all know
> exactly which commits are supposed to be reviewed (all of them) which
> would avoid the tendency for us to start ignoring all commits on
> branches. If that's the main problem (and it certainly could become a
> problem - we already review branches far less than we should), then we
> should at least consider addressing it in a different way, such as using
> a "/branches/scratch/" name space.
Bingo. I was unaware that Neels' branch was intended to be a "public
development of a patch". In that sense, then I'm very glad it is
there, for all the reasons that you point out. BUT. I didn't know that
it would be subject to (good) review when it finally got merged, on
the basis of it being reviewable-sized.
I think your suggestion would be a fine idea. Something like
/patches/tree-conflict-notify/ would work well.
>...
> I guess you're saying that we can't trust most of ourselves most of the
> time to stick to a reviewable-sized change, and then make sure to get it
> reviewed. And historically that's been so. So maybe overall it would be
> better not to work in this way.
No, my comment wasn't about trusting ourselves, but a lack of
awareness of the *intended* size of Neels' work.
But your *is* true. Some of the branches get a bit big, or too
long-lived, or whatever.
> Is it the question of being easily able to know what to review that's
> most important here?
Yes. And to that point, let me formally suggest a /patches/ directory,
as a sibling to /branches/. We can put developer-work in there, and we
can also drop third-party patches in there, too, pending
review/tweaking/application (rather than attach them to the issue
tracker, for example).
Thoughts?
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-23 13:09:57 CEST