[os-infrastructure] Accepting (or rejecting) user contributions into piccolo ingres!main and or community branches

[Chris Clark]

Thanks Andrew,

Here is my interpretation of the the 2 (not all 3 as I could only see 
patches for http://bugs.ingres.com/ticket/143 and 
http://bugs.ingres.com/ticket/193) Ingres sprint projects below. We have:

    * Community members using the "Main Community Mirror", in this case
      this is svn (specifically http://code.ingres.com/ingres/main/)
    * Changes are (relatively) small and so diffs/patches to "Main
      Community Mirror" are appropriate
    * I'm making the (big) assumption that for these 2 patches once
      (they are complete), these are changes Ingres Corp will want in
      piccolo ingres!main as we want them in all products lines going
      forward and the community wants/expects them in their builds too.


For these 2 cases, the community and Ingres Corp needs/wants are the 
same. Proposal 1 at http://community.ingres.com/wiki/Community_Model is 
the most useful as no one (either at Ingres Corp or a Community member) 
needs to perform any cross integration or merging work. Should those 
needs change, Proposal 3 will be more important, but this would be a 
joint decision between Ingres Corp and the Community (if Ingres is not 
involved, the Community might as well set up their own project server 
and fork properly).

However the change doesn't come "for free" as we have to either:

   1. wait for the contributer to clean up the change (and possibly
      educate the contributer as to what we need during that process)
   2. or Ingres Corp takes the basis of the change and performs clean up
      before submission (either into svn or piccolo - with a sync to
      occur to get them in line with each other).

Whether Ingres or the Community member performs the clean up to make an 
acceptable change, because at the moment Ingres Corp holds commit access 
back (no one has yet had time/chance to earn commit rights), Ingres Corp 
will be performing the actual code submission. Presumably we have an 
Ingres Corp engineer(s) be the reviewer (and submitter), we already 
trust Ingres Corp engineers with commit access so this should not be 
controversial.

As the community members learn more about the expectations of Ingres the 
liaison cost with specific, repeat contributers (hopefully) will decrease.

I've probably skimmed over some pieces so PLEASE update/pull apart my 
scenario, we need to understand any weak points in the process flow. If 
any of my assumptions are flawed, bring that to light. Also if you like 
Proposal 3, consider using the 2 examples and talking about the process 
flow for that. Certainly these small projects/patches will not help us 
understand the large Project-D/geospatial changes that we will see at 
some point but small diffs are probably going to be the main changes we 
will see initially.

To re-iterate this is the Ingres code line, I suspect the use cases from 
the OpenROAD sprints will be very different.

Coming back to tickets 143 and 193, how likely is it that the changes 
from the community members will be cleaned up by some one external to 
Ingres Corp? Is it too early to ask that question? How do we weigh up 
between spending time ourselves fixing (/re-implementing contributed 
changes) and educating/assisting external contributors so that the 
changes can be taken as-is? These questions are aimed at both the DBMS 
project and EMPIRE.


Chris



On 7/1/2008 12:30 PM, Andrew Ross wrote:
> Hi Chris, All
>
> On the server side, we created a patch file (svn diff) for each change
> set. No branches were needed for them (at least so far) 
>
> Chris Hane collected them and applied them to Emma's work area on the VM
> on her laptop so she could demo the set. He's still got the master set
> while those of us who sprinted have what we worked on.
>
> Now that the dust has settled from the IUA, we'll be checking with the
> sprinters to see if they're planning to complete them. I suspect many of
> them need more work if for no other reason than proper testing and
> process diligence. I expect that in most cases the sprinters will finish
> things off. 
>
> Some of them already have tickets in http://bugs.ingres.com. e.g.
> http://bugs.ingres.com/ticket/170, http://bugs.ingres.com/ticket/143,
> http://bugs.ingres.com/ticket/193
>
> Andrew
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> Chris Clark
> Sent: July 1, 2008 3:19 PM
> To: Discussions about the infrastructure needed to support a true open
> sourcecommunity; Open Source Engineering
> Subject: [os-infrastructure] Accepting (or rejecting) user contributions
> into piccolo ingres!main and or community branches
>
> Something that came up whilst chatting off line with Ralph; the code
> sprint in the UK should have a number of excellent real world (small
> project) use cases to talk about. We have a number of Ingres projects
> and OpenROAD ones to look at (ideally all of them).
>
> Can anyone who is/was involved with the code sprints in the UK talk
> about how that was(/is being)  handled? E.g. were branches made, or were
> patches generated with "svn diff"? How are the changes going to get into
> main (are they going to get into main or do we not want them).
>
> Chris
>
> _______________________________________________
> 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
>