[os-infrastructure] Experience with a Community contribution

[Alex Hanshaw]

Hi David

 See answers in-line.

 Regards

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
David Tondreau
Sent: 09 June 2008 20:37
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: [os-infrastructure] Experience with a Community contribution

Hi Alex,

This is an interesting experience you had so I "peeled this layer off 
the onion" and gave it a new name.  I'd like to discuss your experience 
managing a community contribution separately because I'd like to get a 
feel for what to expect for us down the road.

Your experience is in line with what I would have suspected --  
contributions from the community that need review, testing, adjustment 
or rework before they can be incorporated into the product.  It seems 
like they required a bit more than just baking in the oven for a few 
days.  I have some questions for you based on your experience.

   1. How did you get the code from Marty and Chris?  E-mail?

 Marty supplied an e-mail of the whole file (fortunately main was at the
same revision). Chris Dawe supplied a before and after copies of the
modified function in an attachment to an existing service desk issue. As
the whole function had been rewritten this was not a problem. I had to
make sure things hadn't moved along so that I would lose intermediate
changes.
 My suggestion is that Open Source contributions should be supplied with
the file revision details, the complete source module and as diff output
that can be used with the patch command.

   2. How much code was it?

 Marty's change showed as a lot of differences but was a minor change.
Initially a !(STcmp() that he used threw me and I thought his logic was
wrong so we had to have a little e-mail discussion. When I raised my
initial concerns Marty thought I was right and had had to take a second
look at his own code before realizing that he had be correct from the
start.
 Chris's change rewrote xfsave( ) in front/misc/xferdb are. The intent
of the change was clearly documented but he had used OS calls that were
not available on all platforms. I got a very quick response from Bob,
Hong, Viktoriya and others when I asked about adding this to the CL.

   3. How much time, if any, would have been saved if Marty and Chris
      could have submitted it directly into source management?

The submission itself is not the time consuming element. A full review
of the changes and in the case of Chris' change the rewrite was what
took the time. Over time as contributors establish a track record of
good changes the review time is likely to be reduced. I could have asked
Chris to go back to the drawing board with his change and use ADF and
TMGL calls as I implemented, but this is a difficult choice. How much
help should we be giving? We want to encourage contributors after all.
Again, as they learn more about the Ingres code line the level of
assistance should be reduced. I'd say the amount of time I spent
rewriting parts of Chris change is too much of a burden.

   4. Would there have been any other downsides of them doing that?

In the case of Chris Dawe's change there was additional testing that I
wanted to do. I was making sure the timezone behaviour before the change
was exactly the same after the change. Contributors do not have the same
number of years experience and might not see some of the gotchas coming.
We need to make sure any additional testing steps can be added by an
internal review at the time an IP is posted. We come back to the "trust"
element. Do we trust contributors to fully tests the changes.
 We have had case of IPs internally where they stated HOQA had been run,
but the change itself did not compile. This can be an honest mistake or
it could be someone deliberately cutting corners.

   5. Did Marty or Chris ever ask if they could have direct access to
      the code repository?  Do you think they expected that?

I'm not sure whether either of them were using the svn code repository
or not. One of the advantages of having a code repository externally
would be the file revision information. If they were working from svn I
could have set up an svn build on my VM and do the submission against
the quoted file revision.

   6. Would you have handled the contributions differently if they did
      have access to the repository?  For instance, do you think that
      instead of doing the rework yourself, you might have simply
      rejected the change and told them to re-implement the code based
      on our standards? 

Using a code repository would have made it simpler for me to implement
and summit the change. The choice about who does the rework is not
related to having a code repository in my opinion. As I said above, I
think this instance was not worth the time internally and probably
should have been pushed back with some guidance. The problem here is
that you could end up with a number of iterations that consume as much
or more time. As the community gathers experience with our code this
will not be so much of a problem (this does assume contributors are
regularly working on our code).

   7. Normally, a code change requiring rework would be rejected and
      sent back to the originating engineer for them to make the
      corrections.  Do you think a contribution from a community member
      needs to be treated differently than from an internal engineer. 
      By that, I mean do we need to treat people like Marty and Chris
      with "kid gloves" because we want to encourage participation?

I think we need to be VERY conscious of the need to add a soft tone to
any feedback we supply. It's hard to put a soft tone on "This doesn't
even compile", but it's worth count to 10 and removing the "WTF" from
the response even if your time has been wasted. I think Chris' change
should have been rejected and I should have supplied guidance on the
areas of code that contain the functions he should have been using
instead of the OS call. Long term this is the way forward, though it may
have taken more of my time to do so.

   8. Given the contributions that were made, do you think you spent
      more or less time time reviewing and correcting their submissions
      than it would have take if you had simply originated the changes
      yourself?

 In Marty's case the change took little more of my time than a thorough
review, IP and submission would have done. The investigation of the code
to determine why copydb was slow and the code changes were all done by
Marty. This was a genuine contribution in an area we are unlikely to
allocate development resources that customers case about.
 Chris' change essentially presented the idea for the performance
enhancement and I implemented it with portable function calls. The
investigation and POC was done by Chris. The rewrite time was in an area
of code not often used so the benefits of my time being spent on
implementing this change are questionable. If I had provided guidance to
get to the portable solution it likely would have taken as much of my
time, but Chris would be better educated for the next time.

   9. What was your general opinion of the quality of the code you
      received.  Can you say it was 70%, 80%, 90% or 99% done?

 Marty's was 100%. Chris' code was POC (about 70%). Both guys supplied
good quality code. Portability issues may be a common problem as people
may well now what they want to do, and how to do it with OS calls, but
not know the Ingres wrappers.

  10. What are your feelings about priorities.  You mentioned that these
      two contributions were probably pretty low on the priority scale
      relative to other items in Service Desk.  But you ended up
      spending time on them (presumably to be responsive to and
      encourage the community) which probably means you didn't get other
      stuff done.  What are you thoughts on how we should prioritize
      this work?

 Neither Chris nor Marty applied any pressure to get the changes made in
any given time frame. I could have spent my 10% on a Friday afternoon to
get this work done. I spent a chunk more than 10% because I do think
there will be long term benefits to getting clever guys like Marty and
Chris contributing to our code and wanted to show our commitment to
their efforts. The community is ideal of lower priority improvements
like this. Everyone can benefit from a faster copydb and in cases where
DBs have a lot of tables Marty's changes make a big difference.
 Prioritisation is a difficult issue. There are paying customer issues
that I don't have time to get to from week to week. Losing half a day to
working on open source issues is a tough pill to swallow under those
circumstances. That said, you don't get something for nothing. If you
invest time in people you'll see the benefits. This applies internally.
If new people have an experienced mentor they get up to speed in a
shorter time frame. I think this is worth the time and effort. Chris and
Marty and many others around Ingres have been around Ingres for as long
as us old timers so they're likely to provide a return on investment if
we help them contribute. By the way I'd like to make sure it's clear I
make up the smallest part of that 125 years experience you mentioned in
the earlier mail ;)

Sorry to be such a load of questions but I'm stumbling around in the 
dark on this stuff sometimes and you've got some good first hand
experience.

No problem.


David



On 06/09/2008 05:39 AM, Alex Hanshaw wrote:
>  I recently implemented code changes from Marty Bowes and Chris Dawe.
> Both were performance enhancements to the copydb code.
> Marty's changes needed review implementation and a little testing.
> Chris Dawe's changes needed to be rewritten to use generic code rather
> than platform specific OS calls. Neither change was low cost in terms
of
> my time. The collateral testing needed to make sure Chris Dawe's
changes
> were OK was fairly high.
>  By educating community contributors and placing a higher bar on what
we
> try to integrate this cost could be reduced.
>  My assessment of these two changes is that they made improvements
that
> were important to these two individuals and consumed resources that
> could have been used on higher priority issues. Both individuals had
> invested time in establishing their changes and proving the benefits
> that can now be seem by other customers going forward. I'd question
the
> importance of these changes compared to the bugs listed in Service
Desk
> issues but there's no denying that Marty and Chris spent time trying
to
> make Ingres better which long term reduces our cost to improve Ingres.
>  DBMS changes are more likely to come from partners that need specific
> functionality. Apart from Karl I've not seen any so far.
>
>  Alex
>
>   
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure