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

Thu Jun 26 07:43:18 PDT 2008

Agreed.

Alex Hanshaw wrote:
> Can we ban "you said / we said" mail from this list and stick to pros
> and cons of the proposals.
>
>  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 14:45
> To: Discussions about the infrastructure needed to support a true
> opensourcecommunity; Durwin Wright
> Cc: Open Source Engineering
> Subject: RE: [os-engineering] RE: [os-infrastructure]
> Re:Modeldiscussionboiled dry(er)
>
> Andrew,
>
> the OpenROAD team did never attack the work done by you and your team,
> but demanded to have discussions & decisions on processes, models,
> policies etc.
> before (or at least in parallel to) selecting the appropriate tools.
>
> It was just you who felt personally attacked (we still wonder why),
> and answered with accusations of "not recognizing the work of your
> team".
>
> The activities of the OpenROAD team, i.e. for the Piccolo branches,
> have been discussed and announced in the open.
> We also made it clear that all we are doing is a trial of the
> processes/models etc.
> Nothing has been cast into stone.
>
> That's in clear contrast to the work you were doing, which has been
> started hidden,
> and decisions for tools were made without ever asking for any
> discussion.
> The first we heard of the os-infrastructure mailing list was by pure
> chance.
> Questions (or criticism) we made about tool selection were either not
> answered at all
> (like my question about a realistic piccolo<->svn performance
> comparison)
> or hammered down with strange arguments, e.g. for my question "why Jira,
> though it's
> not open source" (So, David looking at OS alternatives like Gforge is a
> good thing to do).
> Yes, I'm also interested in the tools discussion, but the replies I got
> made me struggle to continue.
>
> For the "fresh model" discussion, we made it clear to you and others
> - after some internal discussions - that we prefer a Fedora-like model.
> So, we layed our intentions wide open.
> Youself announced at the development summit that a diverging codeline
> model is in discussion,
> so you even thought it acceptable yourself.
> Now you came back with the "fresh model", so you should accept that we
> still believe
> that the Fedora like model will serve us better and at least let us try
> it out.
>
> BTW:
> I doubt that you have ever been involved in discussions with the
> OpenROAD team 2 years ago.
>
> Bodo.
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> Andrew Ross
> Sent: Thursday, June 26, 2008 2:42 PM
> To: Durwin Wright; Discussions about the infrastructure needed to
> support a trueopensourcecommunity
> Cc: Open Source Engineering
> Subject: RE: [os-engineering] RE: [os-infrastructure] Re:
> Modeldiscussionboiled 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
> _______________________________________________
> 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
>   