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

Alex Hanshaw Alex.Hanshaw at ingres.com
Mon Jun 30 02:01:52 PDT 2008 

Hi Deb

 Can you give us ball park figures for RH staff working on the RHEL and
Fedora at the time you were there. If we can't staff that model then Red
Hat's success is by no means a guarantee that it's a good model for us
if the parameters were vastly different.

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Deb Woods
Sent: 27 June 2008 14:40
To: Discussions about the infrastructure needed to support a true
opensourcecommunity; Andrew Ross
Cc: Open Source Engineering
Subject: RE: [os-infrastructure] Re: [os-engineering] Model
discussionboileddry(er)

One thing to keep in mind with a model such as the Fedora/ RH model is
...It takes LOTS of people with the separate stream. There is more
integration work, QA work etc to work in this environment. When RH went
this direction, there was a big concern on if they could attract enough
people to contribute and maintain fedora and not have it all powered by
RH. RH development is done there and then they integrate back to RHEL
the pieces that are ready and have relevance to their offerings. Patches
and security fixes are done to RHEL as well vs Fedora. There are
individuals that only work in RHEL (sustaining staff, integration and
QA) and there are people that work in both.
deb

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
David Tondreau
Sent: Friday, June 27, 2008 8:09 AM
To: Andrew Ross
Cc: Open Source Engineering; Discussions about the infrastructure needed
to support a trueopensourcecommunity
Subject: [os-infrastructure] Re: [os-engineering] Model discussion
boileddry(er)

Andrew,

I don't think the folks at RedHat thought the Fedora "fork" was bad.  I 
think they thought it was very calculated, coordinated and essential to 
the business.  The kind of "bad" fork that you are talking about is when

a completely separate organization takes a project and permanently 
separates a copy of the code from its parent without any intent to ever 
cross-pollinate.  I would argue that this is not *bad* at all  -- its 
simply a characteristic of open source -- a risk you run when you choose

the model.  If you think you can handle the fork, go for it!  Moreover, 
all one needs to do is look at how many variants there are of Linux 
itself to see that forking is common and successful.  There are as many 
examples of derivative projects being successful as well (e.g., Postgres

 > EnterpriseDB), depending, of course, on how you define "success."

In fact, the basic idea that Ingres is open source and can be forked is 
one of the aspects of our viability.  That is, customers may find it 
easier to buy Ingres now that it is open source because its not a 
proprietary technology.  Even if Ingres Corp goes away, the software 
lives on and someone could step in and fill the void.  We will find in 
the long term that if we encourage the community to not only participate

but actually become responsible, we could see  vibrant development occur

around our technologies.  If we try to hold it close, what we actually 
encourage is a non-coordinated fork.

To be candid, *none* of the proposals we are talking about will achieve 
the separation that is necessary in the long term (though Steve's model 
is closest to it) for the simple reason that it is *we* who are talking 
about how the community source will be managed.  The foundational 
principal of the Fedora model is that the community edition is not *for*

the community, it *belongs* to the community.  In the long run, with the

Fedora model, the community will decide how the community code is
managed.

This is what I was referring to when I talked in my "Truths" post about 
open source being harder than we ever imagined if we embrace it.  
Someone said earlier that we will need lots of people just to perform 
cross-integrations.  Yep.  In fact, that is what the engineering will 
tend to migrate to (over the years).  Certainly, you will have 
developers inside the walls who innovate and contribute to the core 
product.  As Deb has explained it to me, there is still quite a bit of 
innovation that occurs at RedHat.  But the foundation that the company 
makes money on is integration, quality assurance, stability and support.

 From a developer's perspective, do I like this idea?  Personally, no.  
I like to think I'm pretty smart and know my technology (and what to do 
with it) better than anyone else.  Unfortunately, the sprints are 
beginning to teaching me I may be wrong in that assumption.  In any 
case, whether I like it or not is irrelevant because I like my paycheck 
too.  What we *have* to do is figure out a way to do is grow the 
community and be commercially successful.  The reality is that RedHat is

the most successful open source company on the block.  I simply cannot 
see how we cannot adopt the practices that made them successful.

The Fedora model is not just about code lines, its part of the 
go-to-market strategy.  How the code is managed simply falls out of this

strategy.  Is deciding strategy above us?  I don't know.  It could be 
that OpenROAD is completely unimportant to senior management.  So much 
so that when the OpenROAD team chose the Fedora model because that was 
the only way we saw it could work and proposed the Empire project, it 
was "Yawn, OK, do whatever you want."  Or, as you have pointed out 
before, perhaps we are expected to lead the company and *be part of the 
formulation of its strategy*.  I am beginning to believe this is the
case.

David


On 06/27/2008 06:59 AM, Andrew Ross wrote:
> Hi Bodo,
>
> I understand this important difference in philosophy. It comes down to
> how strong "gravity" (the propensity to keep content integrating to
the
> trunk) is. A key principle in open source has always been that forking
> code is bad. It's part of open source culture and cited in many
research
> papers on open source as a source of strength. This is why I feel we
> should structure our environment/model to encourage integration.
>
> I understand why people feel allowing the community to diverge is
> important. I feel the branches-are-cheap-so-go-for-it philosophy of
> proposal 1 accommodates this. For example, in proposal 1, if another
> branch was created that Ingres the company does not control or say
what
> goes in to it, doesn't that satisfy the desire to provide a place
where
> community can decide on the content? Please see the community release
1
> branch in the diagram:
http://community.ingres.com/wiki/Community_Model 
>
> Do you agree?
>
> Andrew
>
> -----Original Message-----
> From: Bodo Bergmann 
> Sent: June 27, 2008 4:11 AM
> To: Andrew Ross; Discussions about the infrastructure needed to
support
> a true opensourcecommunity
> Cc: Open Source Engineering
> Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
> discussionboileddry(er)
>
>
> Andrew,
>
> you wrote:
> "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."
>
> If you start from this assumption I understand why you are fighting
for
> it.
> This might be true for bug fixes.
>
> But in a vibrant community I see it rather the opposite way:
> There will be many changes to existing fetures and a lot of new
features
> (the Development Sprint in London just showed this).
> The community will decide what's going to be the community release.
> Example:
> If the community decides to change some code which would tremendously
> improve the performance of the community version (doesn't matter if
it's
> Ingres or OpenROAD or whatever), but which would e.g. rip off backward
> compatibility for the enterprise version or violate B1 security, then
> with proposal 2 (or 3 - made by Steve), this would be possible wheras
> with proposal 1 it would have to be rejected by Ingres Corp.
> with the argument "It brings problems for our enterprise version".
> Steve mentioned "Project D" as another example.
> Such rejections will add a "nice" subtitle to our Open Source
community
> commitment statement:
> "as long at it serves us".
>
> I want the community to decide for itself what they need, we don't
have
> to be the wise guys who tell the community what's best for them (and
> us).
> That doesn't mean we are off the field. We will still support the
> community, guide, teach & help them, let them know about the
> implications of the changes, etc.
> But in the end there will be some kind of community committee which
will
> have the say.
> A vibrant community will serve us better and eventually come up with
> more innovative solutions than one which is permanently dominated and
> patronized by Ingres Corp.
>
> That's why
> Bodo.
>
> -----Original Message-----
> From: opensource-engineering-bounces at lists.ingres.com
> [mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
> Andrew Ross
> Sent: Friday, June 27, 2008 3:50 AM
> To: Discussions about the infrastructure needed to support a true
> opensourcecommunity
> Cc: Open Source Engineering
> Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
> discussionboileddry(er)
>
> Hi Joe,
>
> 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. 
>
> For clarity, with proposal 1, it is possible to have content in
piccolo
> (or call it a protected branch in any scs) that is not available to
the
> public. These changes are not reflected back into main unless
explicitly
> propped.
>
> 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. 
>
> The alternative model (pending the diagram to ensure I understand it
> 100%) looks like someone would have to manually cherry pick & prop
> content to either side to allow community and enterprise to benefit
from
> each other. This may even have to be a team of people as it's likely
no
> one person has domain expertise necessary to make the call. 
>
> Andrew 
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf
Of
> Joe Abbate
> Sent: June 26, 2008 9:12 PM
> To: Chris M. Clark
> Cc: Open Source Engineering; Discussions about the infrastructure
needed
> to support a true open sourcecommunity
> Subject: Re: [os-engineering]FW: [os-infrastructure] Re: Model
> discussionboiled dry(er)
>
> Hi Chris,
>
> Chris Clark wrote:
>   
>> Coming back to the hypothetical DMF change, this should be done in a 
>> public experimental branch, the issue would be if this experiment is 
>> considered a success and if we cross/merge/integrate it into "Main 
>> Community Mirror". This would then end up in main and future 
>> Enterprise Branches, I don't think it would be integrated into 
>> existing commercial branches (they are supposed to be feature 
>> complete, support should only be integrating bug fixes into existing 
>> commercial branches).
>>     
>
> But what I think that the proponents of the "fresh", single
> ingres!main/svn:main fail to realize is that say the new access method
> (NAM) adds a new file, back/dmf/dmp/dm1nam.c and adds calls to the new
> functions in back/dmf/dmp/dm2r.c.  With the immediate, unbuffered
> approach, those changes would presumably move from the experimental
> branch to svn:main and immediately update Piccolo's ingres!main.  No
> problem yet.  Now someone makes a fix to dm2r.c in ingres!ingres2006r2
> and needs to propagate it to ingres!ingres2006r3.  If it overlaps the
> NAM calls, he/she is forced to work around the NAM changes when
> integrating the fix into ingres!main and then ensure he/she doesn't
> propagate any of the NAM changes into ingres2006r3.  With the
> "controlled", "buffered" approach the fix can flow from 2006r2 to main
> to 2006r3 as usual because main doesn't have the NAM changes.
>
> The same applies in the other direction.  Just do a p describe -sfiles
> 469243 to see the number of files that had B1 code in them.  If we add
> them back into ingres!main, in the immediate, unbuffered model, the
> files would be publicly available at
> http://code.ingres.com/ingres/main/src/.  Even if the latter is made
> into a private repository, how does a subsequent ingres2006r2 change
to
> adtcompute.c get propagated to the public community codeline?
>
> Joe
> _______________________________________________
> 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-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

More information about the opensource-infrastructure mailing list