All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Jensen <jjensen@workspacewhiz.com>
To: Jeff King <peff@peff.net>
Cc: "Jon Seymour" <jon.seymour@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Coping with the pull-before-you-push model
Date: Mon, 13 Sep 2010 22:47:30 -0600	[thread overview]
Message-ID: <4C8EFE62.7080908@workspacewhiz.com> (raw)
In-Reply-To: <20100910141527.GA6936@sigill.intra.peff.net>

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

  reply	other threads:[~2010-09-14  4:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09  4:47 Coping with the pull-before-you-push model Joshua Jensen
2010-09-09 13:06 ` Ævar Arnfjörð Bjarmason
2010-09-09 14:43   ` Joshua Jensen
2010-09-10  5:35     ` Jon Seymour
2010-09-10 14:15       ` Jeff King
2010-09-14  4:47         ` Joshua Jensen [this message]
2010-09-14  5:24           ` Jeff King
2010-09-14  5:59             ` Avery Pennarun
2010-09-15 21:59             ` David Brown
2010-09-14 12:12           ` Theodore Tso
2010-09-14 15:51             ` Joshua Jensen
2010-09-14 16:24               ` Eugene Sajine
2010-09-14 16:49               ` Ted Ts'o
2010-09-14  4:37       ` Joshua Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C8EFE62.7080908@workspacewhiz.com \
    --to=jjensen@workspacewhiz.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jon.seymour@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.