[os-infrastructure] Re:
[os-engineering]Modeldiscussion boileddry(er)
Deb Woods
Deb.Woods at ingres.com
Tue Jul 1 16:35:01 PDT 2008
I know a lot of the guys at Novell that work on SLES or have since left.
Novell develops a number of features for Sles and holds them back from
the community and releases later- The model isn't as clean on that one.
I can hook you up with some guys if interested
deb
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Jason Boissiere
Sent: Tuesday, July 01, 2008 5:41 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)
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
--
Jason Boissiere
Senior Quality Assurance Engineer
Ingres Europe Limited
jason.boissiere at ingres.com
PHONE +44 01753 559529
www.ingres.com
This transmission is confidential and intended solely for the use of
the recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure
or distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
_______________________________________________
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