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

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

 



 ----- Original Message -----
From: Jeff King
Date: 9/10/2010 8:15 AM
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.

Do you know of any existing software that does this? This may be ideal in the short term.
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.

I agree with you concerning how valuable a human maintainer is.

Josh
--
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]