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. >> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel