[os-engineering] RE: [os-infrastructure] Re: Model
discussionboiled dry(er)
Alex Hanshaw
Alex.Hanshaw at ingres.com
Thu Jun 26 05:41:48 PDT 2008
Durwin
I'd like OpenROAD buy in so we have a product wide, consistent approach
that does not lead to a community repetition of the internal processes
(or lack thereof) that allowed DBMS development to break OpenROAD over
and over.
I think that product groups doing their own thing in isolation would be
a mistake. That does not mean that different models can not be followed
by different groups.
I certainly thought I had managed to avoid speaking on anyone else's
behalf.
Apologies if anyone felt differently.
"No one cares about OpenROAD's needs". Sorry, I'm stunned. "No one"
would clearly include me and I have engaged OpenROAD people in ALL of my
communications on this subject because they are the people best placed
to voice concerns or opinions that I will not have thought about because
of my DBMS perspective. Generalization is a bad thing Durwin. Do not tar
everyone with the same brush.
If everyone does their own thing we will not necessarily meet at a
common point. We will not gain the advantage of listening to people with
a different perspective.
Alex
-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Durwin Wright
Sent: 26 June 2008 13:18
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
More information about the opensource-infrastructure
mailing list