[os-infrastructure] Re: Model discussion boiled dry(er)

Thu Jun 26 04:17:53 PDT 2008

Both mercurial (http://www.selenic.com/mercurial/wiki/) and bazzar 
(http://bazaar-vcs.org/) are excellent open source scm systems.  
Mercurial is used by rPath Linux and JasperSoft and bazaar has recently 
been adopted by MySQL for managing all they're code. Their tool 
requirements will be at least as demanding as ours and they're 
communities are far larger.
I would encourage you to take a look at what these products offer 
interms of feature and methods of working to give you an idea how how 
far behind piccolo really is. (Automatic gatekeeper support for one)
At the moment the only outstanding issue as far as missing features are 
concerned is the label functionality that. I for one think that we 
should consider reviewing some of our processes before getting too hung 
up on single pieces of piccolo functionality. Even in the event we 
decide we can't live with some feature (p label for instance) both 
mercurial and bazzar are python based and easily extensible.
I am playing with both of these tools at the moment and hope to share my 
findings (and hopefully solutions) soon.

J

Alex Hanshaw wrote:
> I have to agree with J and Andrew that piccolo is unlikely to be
> accepted by the community even if we made it a community tool.
> I'm very disappointed to hear that development time and resource is
> being allocated to extending piccolo when no cost analysis has been
> presented for the work required to extend piccolo vs the cost required
> to improve svn.
> That is no more or less of a unilateral decision than Andrew's initial
> selection of svn. Much of the justified complaints leveled at svn is
> that it was a unilateral decision made without a fair evaluation of the
> options with cross functional input. Let's not repeat that mistake. It's
> a mistake that has made many (including myself) to see red instead of
> making logical business choices.
>
> svn
> 1) has poor merge capabilities.
> 2) does not provide labels
> 3) It is readily available on linux distributions.
> 4) Provides all other capabilities we have in piccolo
> 5) Already accepted by the community
>
> piccolo
> 1) Needs LDAP and authentication mechanisms to be added.
> 2) Not known by the community.
> 3) Not available on linux distributions.
> 4) Has labels
> 6) Has great merge capabilities.
>
>  Add to either list. I'm not sold that developing piccolo will get
> community buy in. I'm no fan of svn (I REALLY hope there is a better
> open source alternative) but the community that was present in Punta
> Cana were very happy to pick up and use svn because they already use it.
> That makes for a compelling argument in terms of acceptance. Further
> more Ingres extending svn would buy a LOT more community brownie points
> that pushing yet another source code repository tool into the community.
>  
>  Alex
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> Andrew Ross
> Sent: 26 June 2008 01:45
> To: Discussions about the infrastructure needed to support a true
> opensourcecommunity
> Subject: RE: [os-infrastructure] Re: Model discussion boiled dry(er)
>
>
>
> Hi All,
>
> I spoke briefly with Durwin this evening to try and better understand
> what the differences are in the models we're discussing (as they seemed
> to provide the same capabilities). He'll represent his own views, but I
> will share some of the essence of our conversation in hopes of building
> towards understanding and consensus. 
>
> The key difference between the model I've proposed and called fresh, and
> the model Durwin has proposed (named controlled by Bodo) is that there's
> a branch (referred to as a buffer in various posts) in between the
> community and enterprise developers. Durwin explained to me that this
> buffer is there to protect against intellectual property issues and to
> provide an integration point for cascading branches should we need to
> use them. 
>
> We agreed that it may be rare where we'd need to integrate multiple
> branches together before integrating them to main. So people know, you
> can do this in svn without a buffer branch. Simply svn merge the
> revisions you want from another branch to your work area on your branch.
> This makes a buffer branch less necessary.
>
> In terms of IP, Durwin shared that he's not aware of any plans for how
> to vet the code (say by using Black Duck, or otherwise). I must say that
> this is not solved by the branch and thus is orthogonal to the freshness
> discussion.
>
> It was also clear talking to a few people including Durwin that they
> didn't realize that main (in piccolo, or what we're proposing in svn to
> mirror) is not the same as enterprise. We branch from main to produce
> the release branch we'll soak and test what will become enterprise.
> (e.g. ingres2006r3) Thus, again, the buffer branch is less necessary.
>
> I want to make it clear that I'm not saying the buffer branch is wrong.
> I just don't think it's needed. As Alex said earlier... why mirror the
> mirror. Where I do disagree is regarding the freshness of the code
> available to community. The bigger the difference between the code they
> develop on and internal resources, the more conflicts we'll see. We've
> seen this with the work we've done with Datallegro.
>
> For people who say they don't care about tools, it's obvious some folks
> have a major problem with svn and want to continue using piccolo. Again,
> this is orthogonal to the freshness discussion. Somehow I suspect people
> wouldn't be getting so excited if we were talking about spinning tar
> files more often. If it helps you accept svn, think of it as a magic tar
> file that we're going to update all the time.
>
> Durwin informed me that development is being done to add public access
> and access control to piccolo. I personally feel this is work in the
> wrong direction as I've shared here previously and J commented on.
>
> Someone reminded me of the obvious this evening. There are going to be
> people who disagree no matter how hard we try to build consensus.
> Leaders of countries are elected with nearly half the country opposed.
> While we'd like to have unanimous agreement, it is unlikely. I ask any
> that have a beef with what we're doing to work with us to improve it or
> come up with something clearly better. This *IS* happening. If someone
> comes up with something better (for instance if we determine we need to
> use Mercurial vs. svn, or Jira vs. Trac), and have a compelling
> argument, I will support it and help. Use your limited complaint tickets
> wisely please.
>
> Andrew
>
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> Daryl Monge
> Sent: June 25, 2008 6:47 PM
> To: Discussions about the infrastructure needed to support a true open
> sourcecommunity
> Subject: Re: [os-infrastructure] Re: Model discussion boiled dry(er)
>
>   
>> Daryl Monge wrote:
>>     
>>> Here are some scenarios, possibly colored with my viewpoint, that I 
>>> hope adds positively to the discussion.
>>>
>>> A while back when I first started looking at porting Ingres to OS/X 
>>> we had source tarballs and the old SVN repository.  As my objective 
>>> was to pretend to be an external developer, I dutifully downloaded 
>>> via the community source and started working on it.  In a very short 
>>> period of time I found myself hopelessly out of date.  I had to have 
>>> the ability to sync with the code repository whenever I needed or the
>>>       
>
>   
>>> project was going nowhere.
>>>       
>> Could you explain why you *had* to sync with the code repository 
>> frequently?  In porting, at least on VMS, we start with a label 
>> typically from Linux and we work on it, sometimes for many weeks 
>> without refreshing anything because we don't want to destabilize what 
>> we already know is working.
>>     
> Development and level 2 are constantly changing the code and it was
> breaking/fixing things as I went along.  I would be overwhelmed with  
> the number of changes over a long period of time.   I found that  
> maintaining a close sync was significantly easier (admittedly for me)
> than trying to go through hundreds of files after a couple months to
> find out if a change may have affected me.  I like working in smaller
> bits and keeping up.  Oddly, you may think we disagree but in fact a
> couple weeks was the typical sync interval.
>
> However, you are correct that there are other scenarios where you do not
> want to sync frequently.  However I believe this simply reinforces my
> point.  Everyone's needs and situations are different and the source
> code repository cannot arbitrarily dictate the sync process that will be
> used by developers.  So here we see that we both may be perfectly happy
> with a sync delay of several weeks.  But I want to sync today.  You
> might want to sync next week.  This implies that the repository has to
> be significantly more update to date than either one of us by ourselves
> needs.
>
> Andrew mentioned 3 months to a year for the delay model.  Are you
> suggesting via your own VMS experience that 1-2 weeks (roughly) is a
> normal sync interval for a major project?  That seems to me to be closer
> to "fresh" than "delay".
>
> Are we only discussing time length between sync instead of a major
> difference in strategy?  Are we violently agreeing?  :-)
>
>   
>> And Jonah Harris, who I mentioned previously, did the FreeBSD port 
>> from the old SVN repository.
>>     
> And where is it?  It is very easy to work on a static port with no
> foreseeable integration point.  It is quite another to make sure you are
> in step with others.
>
>   
>>     
>>> I recently discovered a problem with the createdbms shell script
>>>    http://bugs.ingres.com/ticket/138
>>>    http://inspect.ingres.com/r/6/
>>> It is a three line change.  It has not been submitted yet.  In fact  
>>> I can't submit it.   :-(
>>>            or :-) depending on your point of view...........
>>>       
>> The interesting part about createdbms is that AFAIK it is only in the 
>> community repository.  If it exists in Piccolo, please let me know 
>> where.
>>     
> It was meant as an example of a simple bug fix, with minimum affects on
> the product as a whole.  The fact that this particular file is not in
> Piccolo is not relevant.  I have three other porting bugs outstanding
> and they will affect files in Piccolo.  I suspect (but do not know yet)
> they may also be simple code changes and would also fall into this
> scenario.
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>   