Re: [PATCH spice-protocol] build-sys: simplify autogen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/05/2014 05:52 PM, Marc-André Lureau wrote:
On Fri, Dec 5, 2014 at 4:12 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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.

Note that those trivial patches are being reviewed by the "trivial patches team"


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.

I disagree.
When doing a release, a maintainer should _not_ review all commits.
Those commits should have been reviewed before being committed.
The number of patches added since the previous release can be large,
and re-reviewing all of them can be too much work for little gain.

Regards,
    Uri.

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]