www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Cabrera <...@toolazydogs.com>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Thu, 01 May 2008 22:20:26 GMT

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.


Regards,
Alan






Mime
View raw message