www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Thu, 01 May 2008 18:42:48 GMT
On Thu, May 1, 2008 at 11:31 AM, Sander Striker <s.striker@striker.nl>
wrote:

> On Thu, May 1, 2008 at 8:05 PM, Matthieu Riou <matthieu@offthelip.org>
> wrote:
> >
> > On Thu, May 1, 2008 at 10:47 AM, Noel J. Bergman <noel@devtech.com>
> wrote:
> [...]
> >  > We do not want "peer to peer between developers" -- that is a
> violation of
> >  > our development methodology, not a tool limitation.
> >  >
> >
> >  I'm just curious about this last statement. Aren't we all supposed to
> do
> >  peer-to-peer review of each others' patches? We tend to use Jira to
> share
> >  patches but I'm missing the fundamental difference in the process.
>
> There is a difference between peer-review, and doing development
> helped by a dSCM which exchanges changesets between cooperating
> peers.  We want everything to flow through the main repository, "forcing"
> collaboration on one tree.
>

So let's see:

1. I develop something locally
2. I post a patch in Jira for review
3. Someone gets the patch and reviews it
4. My patch is brilliant, I commit it.

Compare to:

1. I develop something locally
2. I make it available from a public mirror or my local copy
3. Someone looks at it
4. My patch is brilliant, I push it.

I understand that on step 4, I could very well not push it. But I could very
well not commit it either and just apply it on my super secret vendor branch
instead. The latter is just slightly more painful but not more painful than
slicing a big commit in several small ones to compare to a similar parallel
thread :)

Cheers,
Matthieu


>
> Cheers,
>
> Sander
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message