[os-engineering] RE: [os-infrastructure] Re: Model discussionboiled dry(er)

Thu Jun 26 06:26:28 PDT 2008

What is you point?

Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500
Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  +1
650-587-5523 | fax: +1 650-587-5550 | "Wag the Dog" 

-----Original Message-----
From: Andrew Ross 
Sent: Thursday, June 26, 2008 5:42 AM
To: Durwin Wright; Discussions about the infrastructure needed to
support a true opensourcecommunity
Cc: Open Source Engineering
Subject: RE: [os-engineering] RE: [os-infrastructure] Re: Model
discussionboiled dry(er)

Durwin,

You're explaining and defending your model and assertions as we delve
into the subtle differences in stream strategy. We're doing this same as
you question what we've proposed. This is why we care. It's only natural
when people question what you're doing.

What's more fascinating is why the OpenROAD team has attacked the work
being done (svn, Trac, fresh model, etc.) with such gusto. For people
that say it's not about tools, and they don't care about tools, you
obviously do care deeply and there's nothing wrong with that.

As part of this initiative, my team and myself personally have been
accused of excluding others in the discussion, moving unilaterally, and
so forth. This is really no different than the discussions that have
been taking place in the OpenROAD team for 2 years, and the creation of
the branches you created in piccolo, the quiet work to provide a public
interface for piccolo, and the work David has done to look at Gforge and
other tools. 

I see the similarities and thus it is easy to support what you're doing
as well. 

Andrew 

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Durwin Wright
Sent: June 26, 2008 8:18 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: Open Source Engineering
Subject: [os-engineering] RE: [os-infrastructure] Re: Model
discussionboiled dry(er)

One of the most facinating things about this discusion is why does the
database group need buy-in from the OpenROAD team to proceed with their
experiments?  Why do you care about what we do in OpenROAD?  I heard it
mentioned on more than one occasion that "no one really cares about
OpenROAD!"

Personally, that is okay with me.  I truly support the efforts of
Andrew, Alex, et. al. in regards to doing what you have had to do to
implement your vision of the Open Source model.  Just do not presume to
speak on my behalf.

As long as we have access to Piccolo for the next two years and there
exists an Ingres Piccolo Main and Ingres rX branches in Piccolo, I am
happy.  This allows the OpenROAD team time to make the changes that we
need to make that will make something like svn or some other source
control system easier for us to use.  Right now it is no-go proposition.
There are technical reasons why this is true.  To understand them, you
have to understand the OpenROAD special needs and concerns.  Since no
one really cares about this I suggest that the Ingres DBMS team proceeds
with what they have proposed and the OpenROAD team be allowed to proceed
down their path.  We will eventually meet at a common point in the
future.

Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500
Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  +1
650-587-5523 | fax: +1 650-587-5550 | "Wag the Dog" 

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Durwin Wright
Sent: Thursday, June 26, 2008 5:09 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: Model discussion boiled dry(er)

Alex,

What Bodo described is something that we already deal with and have
procedures to address.  This has been the case for years.  It is
something that we are comfortable dealing with.  It is not an unncessary
complication it is a requirement.

Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500
Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  +1
650-587-5523 | fax: +1 650-587-5550 | "Wag the Dog" 

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Thursday, June 26, 2008 5:03 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: Model discussion boiled dry(er)

p ineed would list all changes from the community piccolo branch even
non-enterprise class changes. Non-enterprise class changes could not be
ignored in main because they may subsequently form a multiple part
change that is enterprise class. This means the ineed list from the
piccolo community branches needs to be carefully managed for exclusions
some of which may become changes we subsequently want in main.
[bodo]
That's just a case of required process changes.

No Bodo, it's not just a process change. It's an unnecessary
complication.

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: 26 June 2008 10:59
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: Model discussion boiled dry(er)

See comments below (marked w/ [bodo])

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Thursday, June 26, 2008 11:41 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Re: Model discussion boiled dry(er)

Hi Darryl

 Both models would allow different submission rights under different
branches allowing the community change to be submitted in community code
lines.
 Both models would need to go through existing internal stringent review
processes before hitting an enterprise code line.
 Both models would require a community change to be replicated into its
piccolo code branch equivalent.

 Model a) would have a single point of entry into the enterprise code
line, directly into main. If community members developed a high level of
trust they could eventually be given submission rights to community
main. The IP reviewer can easily patch the difs as community main and
enterprise main are in sync. The employee submitter can work using
internal or external tools.

 Model b) would have multiple points of entry into the piccolo code
branches all requiring a replication mechanism between the community
branch and the equivalent piccolo branch.
[bodo] Model a) has also multiple points ef entries into "main" - see
the different release branches  for our enterprise versions - all
handled using piccolo (I don't think you expect us to change this).
I see it as advantage to have the choice of using piccolo or svn - all
changes eventually are committed to the same "community" codeline which
is just mirrored between both systems.

 The change would then need to
be cross integrated into main or be lost from future branches.
[bodo]
No, you can also directly branch off the "community" branch.
Enterprise-class features can later be x-integrated into main (after
according review process and internal testing).

ONLY
ingres employees would be able to do the cross integration to main
unless we use piccolo in the community (with LDAP and other extensions).
[bodo]
That's rather an advantage - "main" is the Ingres IP, so only Ingres
employees should have the right to put things into it.
I don't think any other commercial OS vendor allows direct commit from
the community into their "main" trunk, not even RedHat who doesn't even
own the IP.

p ineed would list all changes from the community piccolo branch even
non-enterprise class changes. Non-enterprise class changes could not be
ignored in main because they may subsequently form a multiple part
change that is enterprise class. This means the ineed list from the
piccolo community branches needs to be carefully managed for exclusions
some of which may become changes we subsequently want in main.
[bodo]
That's just a case of required process changes.

 A live example is a good idea. Whether the response convinces anyone .
. .

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Daryl Monge
Sent: 25 June 2008 23:05
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: [os-infrastructure] Re: Model discussion boiled dry(er)

Here are some scenarios, possibly colored with my viewpoint, that I hope
adds positively to the discussion.

A while back when I first started looking at porting Ingres to OS/X we
had source tarballs and the old SVN repository.  As my objective was to
pretend to be an external developer, I dutifully downloaded via the
community source and started working on it.  In a very short period of
time I found myself hopelessly out of date.  I had to have the ability
to sync with the code respository whenever I needed or the project was
going nowhere.

I recently discovered a problem with the createdbms shell script
	http://bugs.ingres.com/ticket/138
	http://inspect.ingres.com/r/6/
It is a three line change.  It has not been submitted yet.  In fact I  
can't submit it.   :-(
             or :-) depending on your point of view...........

I think both scenarios are actually representative of what will happen
in the "real" world.  Match them up against the models you may have in
mind and see how they fair.

_______________________________________________
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-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-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