[os-infrastructure]
Re:[os-engineering] Modeldiscussion boileddry(er)
Deb Woods
Deb.Woods at ingres.com
Wed Jul 2 06:33:04 PDT 2008
Set up with Novell or Red Hat. Two threads/ thoughts going on or do you
want 2 sessions. As we discussed before would be good to have a list of
questions for them. Who wants to pull the questions together and I can
work logistics
deb
-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
David Tondreau
Sent: Wednesday, July 02, 2008 9:01 AM
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Cc: Open Source Engineering
Subject: Re: [os-infrastructure] Re:[os-engineering] Modeldiscussion
boileddry(er)
Great idea Jason and I agree. Perhaps Deb could set this up?
David
Jason Boissiere wrote:
> I don't suppose we have anyone with a similar level of insight into
> Novell/SLES/openSUSE, do we? It's the same basic model as RHEL/Fedora,
> but I'd imagine another perspective on how an enterprise company
> sponsors and builds a community could only be useful. At least, I'd
> suggest they might be useful attendees at any roundtable we arranged.
>
> Novell seem more publicly involved in openSUSE, but whether that's due
> to necessity or choice, I couldn't say. Certainly easier to find their
> logo on the site. They have full-time openSUSE staff, and assign
> specialised staff from the SLE groups to openSUSE tasks if necessary.
> openSUSE bugs go into the same Novell bugzilla as all their other
> products.
>
> As discussed with regard to Fedora, the problems, processes and
methods
> of an OS, while not being precisely analogous to our situation, can
> certainly still be instructional. The formalised status of headrevs,
as
> the factory branch, which may or may not be usable at any point, is
> interesting, I think. The build service infrastructure, and the
> availability of those projects as optional repositories, has some
> relevance to our community project branching discussions. The fairly
> heated mailing list discussions between Novell staff and outside
> contributors about adding/dropping support for functionality is a nice
> glimpse of the future...
>
> Jason
>
> On Fri, 2008-06-27 at 10:19 -0400, Deb Woods wrote:
>
>> See inline for response.
>> deb
>>
>> -----Original Message-----
>> From: opensource-engineering-bounces at lists.ingres.com
>> [mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
>> David Tondreau
>> Sent: Friday, June 27, 2008 9:58 AM
>> To: Discussions about the infrastructure needed to support a true
open
>> sourcecommunity
>> Cc: Open Source Engineering; Andrew Ross
>> Subject: Re: [os-infrastructure] Re: [os-engineering] Modeldiscussion
>> boileddry(er)
>>
>> Hi Deb,
>>
>> Thanks for adding the insights at RedHat. This is very useful. I
have
>> more questions, though.
>>
>> You said there was some concern about the implementation of Fedora in
>> terms of not being able to attract enough people to contribute. Did
>> those concerns bear out?
>>
>> Deb - It was bumpy at first, the community didn't trust RH and we had
to
>> do several things to gain that trust. Set up an independent board,
>> outsiders as maintainers not just committers (we staged that over
time),
>> and 'real' infrastructure with powerful machines to carry the
workload.
>> It couldn't be for just looks.
>>
>>
>> Was there a point at the launch of Fedora
>> where some people looked at it and said: "This is the end."?
>>
>> Deb - There was a TON of second guessing and it was HARD to say the
>> least and we had people who's blood ran open source in everything
they
>> do.
>>
>> How is
>> the move seen there now? What is the view of Fedora from inside the
>> walls at RedHat?
>>
>> Deb - It is seen as the development environment, critical to their
>> success. It is were their future grows, there still is some tension
at
>> times between the fedora guys and the RHEL guys (remember there are
some
>> that are focused on each- the bulk work in both areas). RHEL guys
have
>> to have stable PREDICTABLE deliverables and fedora strives for that
but
>> not a necessity. This is a BIG difference.
>>
>>
>> The Fedora project seems to have strong independent leadership and a
>> sizable community team. You say that there are RH people that work
on
>> Fedora but the externally visible support of Fedora by RedHat is
almost
>> non-existent. Go to fedoraproject.org and about the only reference
to
>> RedHat is a reference that they are a project sponsor (along with 5
>> other big names) and even that information is hard to find. Is that
>> because it is hard to build a "community" around a product that is
>> perceived to be controlled by a commercial, for-profit entity?
>>
>> Deb - you have to be willing to free some of the control, remember
>> fedora now is much more than RHEL. There are tons of projects/
>> functionality that are in fedora that will never get in RHEL. RH
>> probably had a couple hundred people that are involved in fedora,
some
>> use their private email addresses other RH emails. They are there
when
>> you see code posts, etc. They don't make a big deal about identify
>> people on the site to keep a low profile on it being RH. These are
the
>> fedora leaders on the site - I recognize 9 as being RH, may be others
as
>> well.
>> * Jeremy Katz (jeremy)
>> * Tom Callaway (spot)
>> * Kevin Fenzi (nirik)
>> * Warren Togami (warren)
>> * Brian Pepple (bpepple) (chair)
>> * Jason Tibbitts (tibbs)
>> * Christian Iseli (c4chris)
>> * Josh Boyer (jwb)
>> * Dennis Gilmore (dgilmore)
>> * Jesse Keating (f13)
>> * Bill Nottingham (notting)
>> * David Woodhouse (dwmw2)
>> * Christopher Aillon (caillon)
>>
>> Finally, what do you think the relationship is of all these lessons
to
>> Ingres Corp.? We are the same and yet you could argue that we are
very
>> different. We have two models now with the DBMS and OpenROAD. Can
we
>> afford that or do we need to coalesce on one model and one vision for
>> the community?
>>
>> Deb - That one is difficult, I think resolving this in email is hard,
>> you need a f2f with the key players on what you can work with. How
many
>> people do you really have to work with, who is going to get involved
>> from outside, what roles will they play, will they do the
integration,
>> qa, heavy lifting or just the cool projects? We may need to look at
what
>> resources we have and what can we do with this and then look to how
to
>> grow it and maintain it. Have you guys thought about it that way?
Does
>> one model require more overhead to support it? How easy is it to
switch
>> in the future if you need to?
>>
>> Just thoughts to pour out there - When we did this at RH, we locked
>> several of the key developers, dev mgrs, qa resource, sustaining
>> resource, and pm in a room to go through the options and how we would
>> work through it. We also got a lot of guidance from other projects on
>> what worked and didn't.
>>
>>
>> David
>>
>>
>>
>> On 06/27/2008 09:39 AM, Deb Woods wrote:
>>
>>> 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
>>>
>>>
>>>
>> _______________________________________________
>> 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-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