[os-infrastructure] svn and piccolo

[Michael Lochead]

Although we have not yet made any determinations for an issue tracking
system beyond service desk, I¹m certainly not opposed to the idea of a
single issue tracking system, if it made sense for our customers, our
development engineers and our support teams.  I would agree with Alex¹s
comments below ­ our issue tracking system should not be a differentiating
factor for the service supplied to paying and community users.  I would hate
to explain to a customer that one of the benefits they get as a customer is
the privilege to use service desk!

I¹ve never been concerned about providing too much support to the community
at risk of losing paying customers, and definitely our goal is to only
expand the level of support we offer to our community, and bring the
community into our support processes.  Community support is about solving
problems for our community users, helping new users of Ingres to get
familiar with Ingres products, and sharing ³end-user² experience, which I
don¹t think you can ever over-provide.  This will always be different from
Enterprise Support, where we work with our customers to maximize
availability, performance, security and problem management, and provide a
24x7 guarantee that Ingres will be there to ensure their systems continue to
function.  It is a bigger challenge for other open source companies like
Jasper and even MySQL to some extent, because there is less critical
dependency on their products.

Mike Lochead  


On 5/22/08 7:43 AM, "Alex Hanshaw" <Alex.Hanshaw at ingres.com> wrote:

> Piccolo would keep track of what has or has not been integrated between the
> piccolo-opensource branch and main.
> There would be no need to track what has been moved between an svn repository
> and it¹s equivalent piccolo branch because
> They would always be kept in lock step.
>  
> I¹d still argue the case for a single issue tracking system and given that
> Service Desk is not linked at all to piccolo
> or BUGs retaining piccolo would not make life worse if a unified issue
> tracking system were used and it was not
> hooked into piccolo or BUGs. Of course some will still argue the need for
> separate systems to differentiate the
> service supplied to paying and community users. I refuse to accept that any of
> our paying customers are paying
> so that they can be the privileged ones that get to use Service Desk. If we
> clearly describe the differences of
> paid and community support in actual terms of the support given the issue
> tracking system should not affect
> our customers decision to use paid vs community support.
>  
> We have web access to BUGs information on newbream. We could expose this
> externally to have a single BUGs
> repository. We could just let the community log issues as our paying customers
> do. Paying customers do not log bugs
> so do community users need to be able log bugs, or could they browse a
> knowledge base in the same way as
> paying customers? Perhaps restricted to content generated from community
> issues?
>  
> No one has defined the difference between community support and paid support.
> Until they do we shouldn¹t be making any
> decisions about the implementation.
>  
>  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:22
> 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,
>  
> We talked about doing this early on, and I agree if we want to maintain two
> systems, it is definitely the way to do it. Also, I think we're going to need
> to do this in the short term regardless.
>  
> As time progresses, we'll be maintaining branches in piccolo and svn for each
> release. This paradigm does accomplish many of the missing capabilities such
> as public bug tracking, public code repository, etc. However, it may be a bit
> more expensive in terms of complexity, infrastructure, keeping track of what's
> been propped where, and training than maintaining one system. There were a
> number of people who expressed the opinion that we should not do this at the
> summit as they felt the cost would be prohibitive.
>  
> It is still early in the analysis, but it looks like we have no silver bullet
> to do per-platform patching for maintenance. What is your feeling at this
> point regarding which is least painful... maintaining two systems, or headrev
> patching while the codeline is in maintenance?
>  
> 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 6: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/41a60314/attachment.html