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

Tue Jul 1 19:45:09 PDT 2008

Hi Chris,

The tickets cited will likely be mostly employees. (myself, Ray, Grant)

I'm going to forgo commenting on the workflow at least for now as you've
hit on something very important and that is training and mentorship.
Specifically, you asked a key question regarding how we weigh just
fixing up contributions ourselves OR mentoring a community member until
they get it right. 

I'm sure I've tipped my hand on the ip lists and discussions in person
to show how I feel about this. The balance should be heavily skewed
towards sharing knowledge with the community member. This should also
include new employees/interns.

I'd like to propose a guiding principle of avoiding fixing things up
unless doing so is critical to success. This could be turned into a
decision tree I suppose. Do we need it urgently? Y - OK, fix it up but
work with them after to help them understand. N - Provide encouragement,
advice, and guidance. Do they have a hope of succeeding without an
intervention? N - OK, fix it up but work with them after to help them
understand. Y - Provide encouragement, advice, and guidance. You get the
idea. Someone could probably do a much better job of this decision tree
than I.

If you look at nearly every open source project, the phenomena described
by Paul Spencer (CTO of DM Solutions, founding member of OSGeo) at the
summit has occurred repeatedly. The project founders invested in a 2nd
generation who eventually took over and then taught a 3rd generation,
and so on. As each new generation learned and moved to share their
knowledge the community grew in size. This is a great opportunity for
Ingres.

Practically speaking, here are a few ideas of how we do this
(exceptions will occur... common sense applies):
- share our code reviews with the public
- share our design reviews with the public
- share our discussion and banter (like world-techinfo) with the public
- share tips, tricks, code examples, FAQ's with the public
- participate in bootcamps and code sprints
- buddy up with a n00b, make sure they have as many mentors as possible
- work to ensure captured knowledge like architecture specifications,
standards, and such are easily available and keep reminding people about
them and where they are. If they're missing or out of date, do something
about it.

Again, others can certainly add to this list.

Andrew

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Chris Clark
Sent: July 1, 2008 4:24 PM
To: Discussions about the infrastructure needed to support a true open
sourcecommunity; Open Source Engineering
Subject: [os-engineering] Re: [os-infrastructure] Accepting (or
rejecting) user contributions into piccolo ingres!main and or community
branches

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
>   

_______________________________________________
opensource-engineering mailing list
opensource-engineering at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-engineering