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

[Marc-André Lureau]

Hi

----- Original Message -----
> >>> Yes, that it should not have been pushed.
> 
> I agree.
> 
> I would prefer we eliminated the trivial push rule altogether.

I agree, if it can help to avoid this kind of endless discussion.

But to me, it makes the project less friendly if people have no trust to each other for the most basic and obvious improvements. 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. This is to me more healthy than having to bother and wait for each other through a mailing list. It also allows to prioritize, trivial things shouldn't be at the same level as critical bug fix or protocol changes.

I am first a GNOME developper, where anyone can push changes without review. This is based on a trust and meritocratic relationship too, and I like it, and afaik it works well. In fact, most projects I know follow that rule. It makes sense to me that maintainers and main contributors can decide to push changes without bothering and waiting on others. It will be looked over by other people anyway. If they don't, they should try to keep looking at recent changes. Because we are not self contain project, we need to do that anyway for many other projects we depend on. But there is no need to force people to check and review every single minor improvements. There are more important pieces of our stack where changes can go without review (all of them?).

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. It's really not much, if the change is wrong, it can be reverted, not a big deal.

With a bit more perspective, a project where every single change has to be approved is not an open project to me. I'd prefer to work elsewhere.