[os-infrastructure] Model discussion boiled down

[Andrew Ross]

Ralph,

This is part of the mapping process. Rather than dealing with community,
policy, and infrastructure as a nebulous mass, we're picking it apart
and systematically working through each component and issue we uncover.
This is not intended to dismiss, or ignore any complexities or
interdependencies. The hope is that it provides a way to deal with them
effectively.

At the moment, no one is signed up to develop piccolo to be appropriate
for community. If someone wants to fight for that great, but let's be
mindful of what else they could be doing other than developing a tool we
can easily get for free. Look at the end result, we'll have a community
code repository that no one else is using, we have to maintain, and no
one is helping develop. It's going to be a tough sell.

We are proposing that we use the very same development processes we use
internally when working with our community. A community contribution has
to pass the same scrutiny as internal contributions. Thus, what we're
doing to enable community really isn't much different than if we hired X
new developers.

I'm sorry to be facetious, but I too would like to see all the details
mapped out yesterday. That way, we wouldn't need to figure them out.
Doesn't this seem a bit unrealistic to you? 

Same question for you. What is it about the controlled model that you
like better?

Andrew 

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Ralph E. Loen
Sent: June 25, 2008 3:56 PM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: [os-infrastructure] Model discussion boiled down

Hello Andrew,

I've decided to reveal myself as at least one of the private e-mailers
to Joe who supports a "controlled" approach.

I thought Roger, David, and Durwin's e-mails were excellent.  I think
the scope, complexity, and interdependencies of the Ingres family of
products needs to be carefully mapped out before "boiling" down any set
of bullet points to present to the executive team.

In particular, I'd like to throw my support behind Roger's efforts to
make Piccolo a community product.  It seems to be that Piccolo, while
obviously slower, is much more appropriate for an enterprise product
such as Ingres than SVN.  As it happens, it's actually quite feasible to
position Piccolo so that it works similar to SVN in pulling down code.
Or so I would gather from my discussions with Durwin and Roger.

Durwin and Roger have, in my opinion, only scratched the surface of what
will need to be put into place to support Ingres as a community effort.
It seems to me that Ingres is a much bigger animal than other community
products.  To me, this is a very daunting proposition.  

I believe community contributions need to pass muster as commercial
grade software.  I would think that the tolerance for instability must
be very low in order for the community edition to be seriously
progressed.

Consider the rigorous set of procedures we have in place for our own
development.  Even when software development procedures are followed to
the letter, internal submissions are often destabilizing, produce
regressions, and generally are ported to only one platform.  Follow-up
work on development submissions is the rule rather than the exception
for any significant submission, even when the contributors are
intimately familiar with Ingres and have been doing this for many years.

If one considers the possibility of redundant or overlapping
submissions, unwanted submissions, submissions that completely
destabilize Ingres, submissions made for a specious requirement that are
at cross-purposes with the direction of development, and any number of
other items that may come up at random from the community, I would think
that a tremendous amount of communication will need to take place with
the community.  We would be well advised to come up with our own
procedures, probably procedures that never existed before, in order to
properly manage community submissions.  If this discourages some
contributors, that is likely to be better for Ingres than not. 

I feel uncomfortable with blanket assurances that this will all be
handled.  I'd like to see some detail on exactly what is being
considered to manage submissions from the community.

Regards,

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
Joe Abbate
Sent: Wednesday, June 25, 2008 12:09 PM
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Cc: Open Source Engineering
Subject: Re: [os-infrastructure] RE: [os-engineering] Model discussion
boileddown

Hi Daryl,

Daryl Monge wrote:
> I thought the original email WAS the survey.  Private mails between 
> individuals do not help us change/refine/augment our views or
positions.

I meant survey in the sense of reviewing and tallying up the responses.

>From what I saw, you (prior to Bodo's "controlled" option), Alex and
presumably Andrew came out in favor of the "fresh" approach, whereas
Bodo, Jay, possibly Sean, and myself were in favor of the "controlled" 
approach (Sean said he'd vote for "model b" [delayed] but in the context

of defending Bodo's proposal, if I read correctly), and Roger said
"delayed" is "not all that unreasonable".  I don't want to put words in
other people's mouths, but I believe most OpenROAD staff may be on the
"controlled" camp as well.  The private email that I received also
agreed.

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