[os-infrastructure] svn and piccolo

[Michael Sale]

With respect to the difference between community support and paid  
support, the core difference is service desk tickets, phone number to  
call, timely response, at least some kind of response, fixes for  
critical bugs, all on the enterprise version of the product... all the  
core value of support stuff that's out on the website. The value of  
community support is focused on head rev, no promises, timeliness is  
not included, fix your own bugs or wait, build your own code or wait,  
no knowledge base, etc....

I'm guessing what you're really looking for is a more productized  
definition of community support, not enterprise. Am I correct? To a  
certain degree, that's never going to happen because community support  
is what the community makes it. On the other hand, there is the matter  
of what Ingres employee involvement is going to be. In that space, it  
is still very fluid IMHO as we really find our niche as a company and  
as individuals. For some, their contribution may be totally different  
then their typical role inside the company (e.g. Daryl and the Mac  
port, Ruby... no premium customers doing that), for others in  
development or L2, there will be overlap, still others, there's a lot  
of clarity (relatively), such as Empire.

I am pretty dag-durn sure that we'll see community interactions bleed  
over into both support and enterprise L2 interactions. So in my  
opinion, a combined ticketing and bug system would be wise if  
possible. On the other hand, combining the two could be VERY painful  
for both and would likely not be possible inside of at least one year,  
maybe two. **That doesn't mean we shouldn't start it NOW**


Regards,

Mike Sale


On May 22, 2008, at 10:22 AM, Alex Hanshaw wrote:

> Hi Andrew
>
>  At the moment the lack of labels from which further changes can be  
> made and the poor integration capabilities of svn
> suggest that on a day to day basis running two systems MAY be better  
> than running just svn. I’m ignoring the upfront cost
> of the move and large number of changes that would need to be made  
> to our build process as those are one off costs (though
> they would be high).
>  I say “may be better” because we would need to see if a lock step  
> piccolo/svn branch could be fully automated. If it can then
> two systems would be better based on svn’s merge capabilities alone.
> I think product management and sales/support need to define what the  
> difference is between paid and community support
> before we can make an informed decision about which technology we  
> use going forward.
>  We need to identify any overheads involved in using two source  
> control mechanisms. Keeping a piccolo branch in lockstep
> should be something that can beautomated. Deciding what gets pulled  
> into main may be an overhead but that exists even
> if we had only svn, and the merge from opensource to main would not  
> be pretty unless svn got much better at integrations.
> I’ve not worked out an equivalent for “ineed” in svn. Does ones  
> exist? If not the opensource to main cross integrations would
> be very difficult under an svn only model.
>  Your previous mail did raise potential further duplication in terms  
> of bug and issue tracking. How we wish to implement
> those going forward plays a factor in answering the question “Are  
> two systems cheaper in terms of time and effort on
> a day to day basis”.
>
>  Regards
>
>  Alex
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Andrew Ross
> Sent: 22 May 2008 17:00
> To: Discussions about the infrastructure needed to support a true  
> opensourcecommunity
> Cc: David Reed; Robert Kibble
> Subject: RE: [os-infrastructure] svn and piccolo
>
>
> Understood about the replicated piccolo server & database company  
> comment Alex. Perhaps you would like to race... you setting up &  
> documenting work flow for replicated piccolo vs. me setting up a  
> mirrored svn repository?
> ;-)
>
> Regarding svn's build in merge capabilities. No argument is needed.  
> The svn team is very up front about the fact they make no attempt to  
> provide a leading diff tool. Pick whichever diff tool you like and  
> tell svn to use it. If we believe this were a real show stopper,  
> then we must feel the countless people using svn are daft.
>
> In general, regarding mixed revision requirement will be a challenge  
> to most version control systems on the market (closed source or  
> open). It sounds like the answer to my question is that you're in  
> favour of running two systems, correct?
>
> Andrew
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Alex Hanshaw
> Sent: May 22, 2008 11:05 AM
> To: Discussions about the infrastructure needed to support a true  
> opensourcecommunity
> Cc: David Reed; Robert Kibble
> Subject: RE: [os-infrastructure] svn and piccolo
> Hi Andrew
>
>  So far my experience of svn’s merge capabilities is that it is  
> dreadful. Merging a change that adds a line and deletes a line  
> against an earlier
> revision of a file failed miserably and required a manual merge.  
> Mercurial documentation includes an overview of other software and  
> the merge
> capabilities of svn were one of the big criticisms aimed at svn. SE  
> crosses all changes to all forward code lines. Poor merge means a  
> lot of manual work.
>  svn does not have labels, it has tags that turn into a branch so  
> you can pulled a mixed code revision with and use it for further  
> code submissions.
> The number of times I pull an entire build is very small. Regular  
> incremental pulls to head revs not only mean that HOQA tests are
> against current change but mean that piccolo network performance is  
> not an issue. Mixed revision labels from which we can work is a  
> requirement.
> svn does not provide that requirement. You would need to pull a tag  
> work out wha the fix was and then pull a second build against the main
> code repository in order to submit the change and not make the tag a  
> branch. So now I’d have to pull 2 copies locally.
>  Given my experience of svn’s attempts to merge changes I’m not so  
> sure one system would actually be less work.
>
>  If piccolo performance is really that bad I’m sure “p read” could  
> be set up to pull from a local read only replicated DB. If only we  
> were a
> database company with a replication product.
>
>  Alex
>
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Andrew Ross
> Sent: 22 May 2008 15:42
> To: Discussions about the infrastructure needed to support a true  
> opensourcecommunity
> Cc: David Reed; Robert Kibble
> Subject: RE: [os-infrastructure] svn and piccolo
>
> Hi Alex, Bruce, All
>
> I haven't had time to try it yet, but I'm fairly certain we can  
> mirror the repository to all offices. You'd pull code or update from  
> a read-only mirror that's available on the local (gigabit) network.  
> This should take a deterministic amount of time and greatly reduce  
> inter-office (VPN?) code pull traffic.
>
> The read-only mirror repositories would sync when someone commits  
> code to the master.
>
> Updates will be committed against the master repository. Since we're  
> mostly only pushing tiny diffs, even going over a slow network for  
> this should still be zippy.
>
> Andrew
>
> p.s. Following up on the disk space & svn discussion. The repository  
> today consumes only 266MB of disk space, even with the branches  
> people have created. Borrowing a line from Steve, disk space is  
> indeed cheap. Having issues with disk space because people are using  
> the system *a lot* is a good problem to have.
>
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Alex Hanshaw
> Sent: May 22, 2008 10:23 AM
> To: Discussions about the infrastructure needed to support a true  
> opensourcecommunity
> Cc: David Reed; Robert Kibble
> Subject: RE: [os-infrastructure] svn and piccolo
> Hi Bruce
>
>  Piccolo is throttled on the network, svn is not.
>  Svn took over an hour to come down in the uk, vs 5 minutes for  
> Andrew.
>
>  There may be a problem in setting up the OpenRoad community  
> repository given the code is shares from
> different versions of Ingres. Some discussion with Andrew may be  
> required.
>
>  Alex
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Bruce A. Lunsford
> Sent: 22 May 2008 15:17
> To: Discussions about the infrastructure needed to support a true  
> opensourcecommunity
> Cc: David Reed; Robert Kibble
> Subject: RE: [os-infrastructure] svn and piccolo
>
> Sounds good to me, particularly if the syncing of piccolo-opensrc  
> and svn is automated, which it seems like it could be.  One other  
> advantage is that we don’t lose the history in piccolo by a 1-time  
> switchover to svn (or alternatively have to come up with a way to  
> get the history migrated to svn).  One downside is that I was really  
> enjoying the under-10-minute refresh of an entire source build area  
> using svn as opposed to 8 hours or so with piccolo (which is why “p  
> need” will continue to be the favored approach with piccolo versus  
> blowing away a build area and starting from scratch).
>
> From the perspective of EDBC, this approach also helps because the  
> EDBC server code is now at the point of being put into piccolo.   
> This was never possible before because of the lack of a piccolo  
> mainframe client, which was recently completed.  Moving to another  
> CM system would have meant porting another CM client to the  
> mainframe (or sticking with piccolo).
>
> Regards,
>
> Bruce
>
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com 
> ] On Behalf Of Alex Hanshaw
> Sent: Thursday, May 22, 2008 3:49 AM
> To: opensource-infrastructure at lists.ingres.com
> Cc: David Reed; Robert Kibble
> Subject: [os-infrastructure] svn and piccolo
>
> Hi all
>
>  Robert Kibble today suggested a rather neat solution to our svn and  
> piccolo dilemma.
>
>  The idea is that we create a piccolo branch off of main that is  
> identical and kept in tight lock step with
> the svn repository.
>
>  Every submission in the svn repository could then be replicated in  
> the piccolo-opensrc branch with a file
> copy of the affected files. No need to merge difs.
>  Every change in the svn repository could then be easily integrated  
> into main through the use of an ineed against
> the piccolo-opensrc branch.
>  Any change in main that we wished to push through into the svn  
> repository could be done by locking the affected
> files in the svn repository at head rev, crossing the change from  
> main into the piccolo-opensrc branch (identical
> at head rev to svn) and then whole file copy the piccolo-opensrc  
> files to the svn repository for submission.
>
>  By forcing a tight lockstep of the svn repository and the piccolo- 
> opensrc branch replicating the changes between
> the two repositories would be as simple as copying files.
>
>  If we adopt this approach:
> 1)       We have zero disruption to our paying customers.
> 2)       We can provide a community codeline using svn.
> 3)       We can easily pull changes between the community repository  
> and our piccolo repository.
> 4)       No need to rewrite existing scripts and procedures built on  
> and around piccolo.
> 5)       Significantly reduced svn training costs.
> 6)       Ingres staff wanting to contribute to the community edition  
> can working in svn or piccolo (removes the barrier of not knowing  
> svn).
>
>  Let me know what you think.
>
>  Regards
>
>  Alex
>
>
>
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080522/f861c496/attachment-0001.html