+1, I think there's more to gain by asking for forgiveness than by
asking for permission. That said, committers should raise a discussion
before committing if they feel the changes can be controversial.
On Tue, Jul 9, 2013 at 1:57 PM, Ali Lown <a...@lown.me.uk> wrote:
> (Prompted by vjrj's bumping of the reviews today)
>
> Currently we are using review-then-commit, but it seems (to me) fairly
> rare to get a useful review from it (if anybody bothers to review at
> all).
> It also seems fairly pointless for 'simple' commits (most/all of the
> ones currently in the queue).
>
> Christian has raised this before, but it hasn't really had a
> conclusion made about it.
>
> I feel that we would be much better served with the committers simply
> committing changes as-and-when (we have commit mails anyway).
>
> Though, this may seem like it presents too much risk on the committer
> for 'breaking' something, there is no reason 'trunk' should always be
> compilable. (This is what we have branches (e.g. make a 'stable'), or
> releases for).
>
> Perhaps the best answer is some hybrid, so that 'trivial' commits are
> just done, but major changes are reviewed. (Think: Commit
> 'improvements to logging', Review 'adding i18n support').
>
> Can I request 'informal' votes:
> +1: Commit everything always. Make releases for stuff that should be
> compilable.
> +0: Commit/review hybrid
> -0: I don't understand/see any difference, but will defer to somebody else
> -1: _Always_ review everything.
--
Regards/Saludos,
Bruno Gonzalez
http://www.stenyak.com | stenyak @ irc://irc.freenode.net
