Re: Coping with the pull-before-you-push model

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

 



On Fri, Sep 10, 2010 at 03:35:21PM +1000, Jon Seymour wrote:

> This is probably the cultural shift that is hardest for enterprises to
> accept - why do I need a _person_ to do this _manual_ work when tools
> like {insert favourite non-DVCS here} can do this for me? To
> management, this looks like a step-backwards.

Bear in mind that you can still shift to a maintainer model, but keep
the maintainer automated. That is, you can queue up "to-pull" heads, and
then have an automated process pull them one by one and do some basic QA
(does it merge, does it build, does it pass automated tests, etc). Which
is not that different from what many shops do in the non-maintainer
model, except that when you break the build, the maintainer process
notices _before_ publishing the merged tip, so everybody won't try to
build on your broken crap.

I seem to recall that Gerrit does something like this, but I may be
mis-remembering. I haven't actually used it for real work.

I still prefer a human maintainer, because they can do things like
reorder the queue manually (or outright reject flaky topics) to get more
sensible merges, or do easy but non-trivial merges themselves to avoid
kicking code back to the developer.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]