On Mon, Dec 08, 2014 at 03:37:32PM +0100, Marc-André Lureau wrote: > So much of this is quite irrelevant to the discussion at hand about > unreviewed commit rule. I know this is about a lot of stuff, libvirt HACKING fine had plenty of interesting things, so I thought why not keep them. I don't mind dropping everything :) > In general I don't think we need that document, because we follow very > common participation rules. Having strict rules makes contributions > more difficult and that's really not what we are after at this point. It's more about having things documented in a place easy to refer to than about having strict rules, but I don't feel too strongly about having this in a HACKING file or not. > > you removed some part related to make check, I am not sure why. We don't have a decent make check, I'm not sure it's giving useful results. I can readd it. > About unreview commit, this is a good summary of what we already > apply. Bu the problem will remain that deciding whether a change > "trivial" is subjective. > I beleive my autogen.sh fix was obvious and fixed an obvious build > problem and didn't required all this fuss. Many other parts of Spice > would deserve that attention, not an autogen.sh fix. Yup, it is subjective, which is why it's good to have 'rule of thumb' rules which everyone agrees on. When a patch deviates too much from these rules, you know you should send it even though in your subjective opinion it's trivial. Regarding that recent patch (emphasis added): « **if a recently committed patch** breaks compilation on a platform or for a given driver, then it's fine to commit a **minimal** fix directly without getting the review feedback first » so it does not qualify even if you gut instinct told you otherwise. Christophe
Attachment:
pgpBfYb7hu8s9.pgp
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel