www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: [dSCM] Use case: infra down for maintenance
Date Fri, 02 May 2008 08:00:59 GMT
El jue, 01-05-2008 a las 15:20 -0700, Alan Cabrera escribió:
> 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.
> 

<irony>
You mean it would slow our code evolution to a sluggish and confusing
state so that the ASF would die a horrible, slow, thermal death such as
the one the linux kernel seems to be enjoying since they adopted git?
</irony>

While I think we can export data off the ASF issue tracker,
a) there is no way to do extensive work while offline while our
development processes have a proportion of patches hosted in a JIRA
instance, except by handling those patches by hand before going offline,
which is way more painful than pulling the involved branches/whole repos
before going offline.
b) if the server that hosts it has trouble, *we all* have trouble. This
is a key problem of any centralized approach. You may call FUD on it,
the same way that I called FUD on your remark about coordination being a
key problem of any de-centralized approach.
c) if some contractual problem would lead us off JIRA, we would have to
spend a long time migrating and organizing the bug tracker data so that
it is available again with comparible URIs, etc. (see the sf.net ->
roundup migration that the PSF has done as an example).

Regards
Santiago


> 
> Regards,
> Alan
> 
> 
> 
> 
> 
-- 
Santiago Gala
http://memojo.com/~sgala/blog/


Mime
View raw message