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 22:36:22 GMT
On Thu, May 1, 2008 at 3:20 PM, Alan Cabrera <adc@toolazydogs.com> wrote:

>
> On May 1, 2008, at 11:42 AM, Matthieu Riou wrote:
>
>  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 :)
> >
>
> The difference is step 2.  In the former there is a single known place for
> people to monitor.  In the latter, it adds complexity in the form of known
> and unknown peers whose locations must be kept track of and disseminated.
>  Given the nature of developers who are loathe to follow even the modicum of
> procedure that we already impose I predict a proliferation of ad hoc peers
> that are not on most people's radar.
>

That's because we have an existing process in place and created a single
known place for the patches (Jira). We could very well have a single known
place in the latter case if so we choose.

Cheers,
Matthieu


>
>
> Regards,
> Alan
>
>
>
>
>
>

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