[Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen

[Marc-André Lureau]

On Fri, Dec 5, 2014 at 3:37 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> But to me, it makes the project less friendly if people have no trust
>> to each other for the most basic and obvious improvements.
>
> Basic, obvious is very subjective...  It's not a matter of trusting
> people or not (I'm the person I trust the least, even for the most
> trivial change btw), it's a matter of improving the quality of commits
> with reviews. Even the most basic commit can have a typo in its commit
> message.

Ok, but a commit message is not as important as the change itself,
although it's not reversible. The blame will be anyway on the one who
typed it forever.

>> I am not talking about controversial or complicated fixes. But doc
>> addition, build-sys, cleaning, spelling: this all qualifies to
>> something that is an obvious improvement that I can trust people who
>> have commit access to do the right call.
>
> The spice-protocol submodule removal is an obvious improvement (to me),
> and is only making build-sys related changes, but pushing it without
> review would have been a very bad call.

It's obvious but it's controversial and it is a change in workflow, so
that doesn't fall in this rule. Nothing like replacing a crufted
autogen with an obvious autoreconf.

>> This is to me more healthy than having to bother
>> and wait for each other through a mailing list.
>
> Turnaround should be fairly quick with a trivial patch. The patch is not
> going to get worse by waiting on the mailing list, but it may end up
> being better, so it's a win-win situation.

Quick for me is a matter of minutes. There are a lot of trivial
patches that have been pending for days. Improving the change can be
done immediately upstream or by a after-commit review. That's not a
valid argument.

>> I am first a GNOME developper, where anyone can push changes without review.
>
> This is not true, this depends on the module, the maintainer, your
> relationship with that maintainer and the module, ...

And yet, there is no ACL per project for the reason that we trust each
other doing the right thing and it works well.

>> I think this rule should be left to the maintainer, and as a
>> maintainer of some of the Spice project, I prefer to have a trustful
>> relationship and let people commit directly.
>
> Since you are playing the maintainer card, hopefully as a maintainer you
> are going to listen how people (at least 2 ) in your project community
> want to work, and not unilaterally change the way commits have been
> handled in the past.

Don't you see that I actually discuss the matter here?

>> It's really not much, if
>> the change is wrong, it can be reverted, not a big deal.
>
> Not a big deal save for history cluttering, the need to be careful when
> backporting patches if the commit was followed by a fixup commit, no way
> for fixing commit log typos, or for adding missing information, ...

It's also cluttering the mailing list, you moved the problem. You have
to weight the cost of applying strict rules. I have a different
opinion on that.


-- 
Marc-André Lureau