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

[Marc-André Lureau]

On Fri, Dec 5, 2014 at 4:12 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Fri, Dec 05, 2014 at 03:57:29PM +0100, Marc-André Lureau wrote:
>> The blame will be anyway on the one who
>> typed it forever.
>
> I have absolutely no interest in blaming people after the fact, I prefer
> to fix things before the mistake happens ;)

By that I mean that they are aware of the responsability of doing
unreview commit.

>
>> Nothing like replacing a crufted autogen with an obvious autoreconf.
>
> Is this what you did? This is not what I read in the commit log.

"Use autoreconf, allow out of tree autogen.sh run."

>
>> Quick for me is a matter of minutes.
>
> Even if it's a few hours, or a few days, is it a big deal?

That's a big factor, yes.

>
>> There are a lot of trivial patches that have been pending for days.
>
> This means we need to improve on reviews :) Any pointers?

I can point you to patches, but you should try to remember your own for a start.

Also, you can see that other projects have troubles with that, ex
http://wiki.qemu.org/Contribute/TrivialPatches: they are moving the
problem to me, but perhaps it helps.

>> Improving the change can be done immediately upstream or by a
>> after-commit review. That's not a valid argument.
>
> With pre-commit review, you ensure that at least one person read the
> patch. With post-commit review, you have no such guarantee.

With current workflow, you have no guaratee that unreviewed patch go
there by mistake or maliciously. We would need a tool for that.
For me this is the job of maintainer to quickly review each commit
before release.

>> >> 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.
>
> If the clutter on mailing lists is that bad, there's an easy solution,
> a spice-users mailing list in addition to spice-devel. git history is
> what you have to look at everyday, mailing lists history, not so often.

Once again, I disagree, I look as much at list history and git history.

The division you propose is the same than spice-commit and spice-devel
but at a different level with stricter rules.

Btw, do you apply your own rules in your own projects?

-- 
Marc-André Lureau