Re: Switching SCM to git and commit/review policy

[Rolf Leggewie <no2spam@nospam.arcornews.de>]

[resending mail from 13:02 MESZ which apparently got lost somewhere]


Otavio Salvador wrote:
> What people think about that?

Sounds good to me, at least the most realistic proposal I saw so far.
Because it deals better with some short-comings in the "have every patch
touched by two devs"

1) we already have a *HUGE* backlog of patches in our bug tracker[1].
   This will only grow bigger if we require even more human intervention
2) it does not treat every patch the same, differentiation is needed
   IMHO, as well as efficiency and (semi)-automatic processes

Basically, I am fine with "commit to dev, test out, fix regressions if
present".  OTOH, "prevent regressions up front by reviewing everything"
will slow down .dev to a crawl, I am afraid.  Don't we have stable for
that very reason (less volatile code) and with exactly the "2 ACKs per
commit"-policy?   I am all for review for big changes and where
efficiently possibly, but I fail to see the value of it for example for
the type of work that I often do (the busy-work that Cliff Brake so
eloquently described on June 13th).

With the huge number of open bugs and things that need fixing which have
been untouched for ages, I am not convinced that slowing things down
even further is a step in the right direction.


Footnotes:
==========
[1]http://bugs.openembedded.net/buglist.cgi?keywords=patch&resolution=---