[os-engineering]FW: [os-infrastructure] Re: Model discussionboileddry(er)

[Ralph E. Loen]

I took a look at
http://community.ingres.com/wiki/Rules_of_the_road_for_contributing_code
_to_Ingres, which spells out the conditions for which developers may
contribute to the community main.  

Yowzers.  That's quite a set of pre-conditions.  No doubt these would be
very important pre-requisites for anyone who wishes to submit to the
community main if the "fresh" model was to be supported.  It's not hard
to imagine that more restrictions would need to be added as time goes
on.

I suppose some of these pre-requisites need some explanation.  For
instance, "changes that violate the architecture model will be
rejected."  This is an excellent restriction, but pre-supposes that the
contributor will understand what is meant by the term "architecture
model".  So perhaps some Wiki pages, web casts, or other types of
training will be required so that contributors will know whether or not
they are following the architectural model when they propose a
submission.

I'm no expert on the open source community by any means, but development
communities as I understand them prefer a certain amount of autonomy
from the mother ship.  It seems to me that these communities prefer to
be self-policing, with their own standards for submission, bug fixes,
etc.

Of course individual communities are free to branch off at any time, as
Andrew points out.  I can't help wondering if a particular community
would tend to focus on only one branch and propagate that branch
indefinitely.  

What would we do if we wanted to bring in some of the enhancements of a
branch, but the developers had no interest in submitting into the
community main?  If we had to do the integrations ourselves, wouldn't
that branch, in effect, become a type of "buffer" branch?


Ralph Loen
Senior Software Engineer
Ingres Corporation
Ralph.Loen at ingres.com
 
PHONE: +1 650.587.5528
FAX: +1 650.587.5550

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Saturday, June 28, 2008 4:38 AM
To: Joseph M. Abbate
Cc: Open Source Engineering; Discussions about the infrastructure needed
to support a true opensourcecommunity
Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
discussionboileddry(er)

 
Hi Joe,


Regarding changes that community want that we don't necessarily want
back in the enterprise product:

This is another good example (the cluster one) which reminds me a lot of
something we're doing today with Karl for instance. 

I must say up front as there's a slight difference in that Karl
maintains perforce for his use. The rest of Datallegro uses svn. Also,
Datallegro has a business relationship so it isn't true community work
but more of a business partnership. The flow of content would be similar
so it's a valid use case to discuss.

Karl originally did development based on the tar files (ingres2006r2) we
provided on the web. By the time we got the changes to review and
integrate, the code was well over a year old. I integrated 72% of these
myself and came to celebrate heartily when there was a rare trivial
merge. There are a handful of others out there that had enough of a
taste of this to agree with me. If anyone disagrees with me, they're
quite welcome to take on a handful of outstanding submissions to help
them come around to my position. ;-)

We decided the tar files were grossly out of date and that it was best
to grant Karl (as a former employee) headrev access to piccolo via.
reactivating his account and VPN. We had no choice as there was no
public repository for us to use. This worked a lot better for getting
Karl content as he could get the latest bug fixes and features earlier.
It also made the merges go from almost certain manual integration to
almost certain trivial merge. This is a massive improvement.

The outstanding issue was that hands off qa wasn't available to Karl in
a practical sense. Thus, a key criteria
(http://community.ingres.com/wiki/Rules_of_the_road_for_contributing_cod
e_to_Ingres) for acceptance of the code has been an issue. We've done
work to provide set up tools and do a bit of tool cleanup. Now it's
possible for a community member to run the build, create an dbms
instance, and test it with a single command. This is another big
improvement in progress.
 
Let me recap the key parts of this relationship: Datallegro takes
content from us but holds some content back. We reject some of
Datallegro's content as it's meaningful for them, but not
needed/practical/safe for Ingres in general. Most importantly, access to
headrev on our side has made the flow of content go a lot easier.

Joe, this sounds a lot like your example. It's a case of how we've
handled it today, and the model I'm talking about has made it much
easier. Had we created a buffer branch, it would have just made for a
lot more work merging and not solved the content selection process. We'd
have to select and merge out stuff we don't want in any case.


Regarding tools and whether we need(ed) a public code repository:

Obviously the tar files were not the right fit with Karl. Also, they
would not have properly supported work between Warwick University,
Ilmenau University, and Ingres. Nor would it have properly supported
work between the many people interested in our new spatial support. Now
that we're establishing a convention of sharing the ported applications
out of the apps repository, it's much easier for others to contribute. A
public CM made this practical and much easier to do. Proper tools
clearly matter.



Regarding models:

Fedora is a very different animal than Ingres. First of all, Fedora is a
collection of countless vibrant open source projects (bash, screen, gcc,
apache, samba, etc.) The community was there and independent of RedHat
to begin with via. GNU and others. The community would have been there
independent of Fedora and RedHat (see Debian, Ubuntu, Suse, FreeBSD,
etc.) There was even a Fedora Linux project before the Fedora project
got started (there's no open source Ingres project grinding along
despite the company that I'm aware of). 

All of this aside, I believe in the value of allowing community to run
ahead. proposal 1 will support this.  A community spin off is possible
on demand at any time. The proposal lets us have this option without
committing us to all sorts of work to maintain a buffer branch from the
start. It's a model I've used with massive amounts of code (40M+ of
telecom platform/cluster code) and developers (100's I knew of well,
1000's beyond that I only knew were out there) before with success so I
know it works.

This is great discussion, detailed and specific so it's easier to dig
into what matters about it. Thanks Joe.

Andrew

-----Original Message-----
From: Joseph M. Abbate 
Sent: June 27, 2008 2:57 PM
To: Andrew Ross
Cc: Discussions about the infrastructure needed to support a true
opensource community; Open Source Engineering
Subject: Re: [os-engineering]FW: [os-infrastructure] Re: Model
discussionboiled dry(er)

Hi Andrew,

Andrew Ross wrote:
> This looks like the way it works today in piccolo, and has been that 
> way for a while. Have I misunderstood? If someone made a change to 
> dm2r.c in r2, and propped it to r3 by way of main (or made the change 
> in main and patched it to r3), then any feature content or bug fixes 
> affecting dm2r.c in main will always have to be contended with.

Yes, that is the way it works today and it's not a major problem because
"main" is generally a step or two ahead from the current enterprise
codelines. It *is* possible for somebody to make a change in r2 and then
manually integrate it into r3. Typically this doesn't happen between
currently active codelines, but does become necessary say between
oping20 and ingres2006r2, most likely because a feature was
significantly changed between 2.0 and 9.1 (clusters come to mind).

Which reminds me of another example: let's say some "community" 
contributor (perhaps with initials AR) decided to re-implement the Linux
cluster support in a community branch in a significantly different way
than is currently present in r2/r3/main. For argument sake, let's say
there wasn't much interest from our commercial customers on a Linux
cluster solution, but we do have several VMS cluster customers that are
depending on the current implementation (or the 2.0 implementation). How
would we handle these divergencies in a single consolidated repository,
containing both enterprise and community code?

> In general, I'm reading what you've wrote what do we do when we have 
> to fork certain files for good reason and how to deal with the 
> complexity it could cause. (please let me know if I've misunderstood) 
> The proposal
> 1 model is optimized for keeping the code synchronized rather than 
> optimizing it for scenarios where it needs to fork. There's an 
> implicit assumption that the latter is going to happen less often.

That is the latent issue in this entire discussion. I believe those
preferring a "Fedora model" think Ingres Database Community Edition
ought to be or is likely to become the "David Database" (Dah-vid, for
Jacques-Louis David), free to pursue its open source aspirations as seen
by its contributors. Those preferring otherwise (I don't want to call it
"fresh" because there can still be an immediately synchronized
repository pair in the Fedora model), believe the Community and
Enterprise editions ought to go along more or less at the same pace,
each including most of the features of the other, with Community perhaps
taking some riskier stances at first, but eventually being folded back
into Enterprise. The non-Fedora model also sees Ingres Corp as the
ultimate arbiter as to what goes into the official Community repository,
because after all, it is going to be integrated into Enterprise or
otherwise carry the Ingres brand name. OTOH, the Fedora model requires
that Ingres Corp place its trust on a somewhat separate entity, even if
initially we'll be guiding it along.

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