|
Replies:
14
-
Last Post:
Oct 17, 2005 10:19 AM
by: Karyn Ritter
|
|
|
Posts:
142
From:
Newport Beach, California
Registered:
4/27/05
|
|
|
|
SCM and its effect on governance
Posted:
Oct 11, 2005 2:36 PM
|
|
> Subversion isn't a distributed SCM, so it's not a contender for that
> portion. (The simplest way to identify a distributed SCM is that one
> repository can pull from or push to any other as a natural operation.)
I think we have been given this as a requirement from Sun engineering
without any consideration for its effect on governance.
The model of development using a distributed SCM is for each
individual or team to maintain its own branches and occasionally
submit complete change sets to a higher-level individual managing
a gateway for release. In general, there is no independent review
of such changes until a merge/put-over is requested, at which time
the benevolent dictator/gateway for the destination branch
determines, possibly after consulting with others, whether or not
the merge takes place.
That model fits the development process at Sun today because
there is a known hierarchy of Sun employees whose role is to act
as a gateway manager according to the procedures set out by Sun.
Coincidentally (or not), it is also the model that Linux uses
for inclusion of code in the kernel, and what most of the Linux
distros use for the rest of their operating systems as well
(i.e., package maintainers as gateways).
It is important to note, however, that this is not collaborative
development in the Apache sense of development. It is open source
by virtue of the resulting products, but not collaborative because
there is no notion of peers in the decision-making process. It is
truly hierarchical in both authority and life cycle -- each
individual gateway controls its own destiny until the maintainer
fails, at which point a new maintainer is assigned or the software
replaced by an entirely separate line of development with its
own maintainer. In fact, even with an active maintainer, the
normal result of a change request is that the benevolent dictator
takes the patch and changes it arbitrarily to fit what they
personally feel is worth committing to their own code base.
Hierarchy has the advantage of there not being a need to vote on
decisions, but has the disadvantages of there being almost no peer
review of independently delivered parts until very late in the
development process (typically, long after the original developer
has any interest in making changes to correspond to reviewer input)
and an extreme vulnerability to benevolent dictator overload.
This is in contrast to the collaborative model used by FreeBSD,
Apache, PHP, etc., wherein almost all development takes place
on branches within a single centralized repository viewable
by everyone interested in the project and changes are reviewed
as soon as they are made. This model removes barriers to entry
from the community, allowing them to participate in development
during the stages when their participation has the greatest
impact (i.e., design and early prototyping). It also gives the
public an easy way to start contributing, simply by reviewing
commit messages as they occur and pointing out mistakes when
they are inserted in the code.
When I got involved in OpenSolaris, folks assured me that Sun
wanted to see a governance model that reflected the collaborative
method of open source, not the benevolent dictatorship of Linux.
However, every time we talk to Sun engineering it seems clear that
they assume their current model of development cannot be changed
and thus nothing other than distributed SCM is possible. Such a
model assumes that key Sun engineers will be the gateways and
Sun ARCs will define the minimal criteria for gateway acceptance.
I think hell will freeze over before Sun will allow any outsiders
to be a benevolent dictator for any portion of OpenSolaris
considered essential to Solaris. The collaborative model is safe
for Sun because it has the effect of protecting everyone's most
important interests (veto power on changes based on technical
rationale) while treating everyone as peers. In contrast, the
hierarchical model places an individual in that position and
everyone must trust that individual to be even-handed.
Nevertheless, it is still a valid model for OpenSolaris, since
there is no effective difference between having a closed group
at Sun determine who the dictators shall be versus the Linux
method of having Linus Torvalds do the same. I should note,
however, that Linux would have failed miserably if Linus were
not such a nice guy that is respected by the entire community.
So, I have to ask again: what is it that Sun wants in a governance
model for OpenSolaris? Do you want a collaborative model in which
outsiders are peers in the development process, or do you want
a hierarchical model in which outsiders merely contribute and hope
to obtain benefits from the process? Do you want this project to
be more like Linux or more like FreeBSD?
I can write a governance process that works one way or the
other, but I will not write one that attempts to do both.
Dictators and collaborative development do not mix.
....Roy
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
Posts:
1,901
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 11, 2005 3:41 PM
in response to: fielding
|
|
Hey,
On Tue, 2005-10-11 at 14:36 -0700, Roy T. Fielding wrote:
> > Subversion isn't a distributed SCM, so it's not a contender for that
> > portion. (The simplest way to identify a distributed SCM is that one
> > repository can pull from or push to any other as a natural operation.)
>
> I think we have been given this as a requirement from Sun engineering
> without any consideration for its effect on governance.
Not to be too negative, but have we? I've seen zero requirements being
published out on the public lists, which I find personally quite
disappointing on such a wide reaching decision.
Glynn
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
803
From:
Plano, TX
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 7:16 AM
in response to: gman
|
|
On Wed, 12 Oct 2005, Glynn Foster wrote:
> Hey,
>
> On Tue, 2005-10-11 at 14:36 -0700, Roy T. Fielding wrote:
> > > Subversion isn't a distributed SCM, so it's not a contender for that
> > > portion. (The simplest way to identify a distributed SCM is that one
> > > repository can pull from or push to any other as a natural operation.)
> >
> > I think we have been given this as a requirement from Sun engineering
> > without any consideration for its effect on governance.
>
> Not to be too negative, but have we? I've seen zero requirements being
> published out on the public lists, which I find personally quite
> disappointing on such a wide reaching decision.
Agreed. The analysis that was done was not shared with the community or
done with community input or participation. The result of the analysis,
which took several weeks, was shared in a 5 line (or so) paragraph. In
fact, I don't even know who worked on the analysis!
I'll persue this up as a CAB action item. We can, and must, do better than
this type of "black op" behavior if the OpenSolaris project is to be
successful.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 9:37 AM
in response to: gman
|
|
>>>>> "Glynn" == Glynn Foster <Glynn dot Foster at sun dot com> writes:
Roy> I think we have been given this as a requirement from Sun engineering
Roy> without any consideration for its effect on governance.
Glynn> Not to be too negative, but have we? I've seen zero requirements
Glynn> being published out on the public lists, which I find personally
Glynn> quite disappointing on such a wide reaching decision.
Hmm, for some reason I was under the impression that a draft
requirements list was yet to be sent out for comments.
But anyway, I agree that the SCM requirements need discussion, including
the question of centralized-vs-distributed.
mike
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
803
From:
Plano, TX
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 7:18 AM
in response to: fielding
|
|
On Tue, 11 Oct 2005, Roy T. Fielding wrote:
> > Subversion isn't a distributed SCM, so it's not a contender for that
> > portion. (The simplest way to identify a distributed SCM is that one
> > repository can pull from or push to any other as a natural operation.)
>
> I think we have been given this as a requirement from Sun engineering
> without any consideration for its effect on governance.
>
> The model of development using a distributed SCM is for each
> individual or team to maintain its own branches and occasionally
> submit complete change sets to a higher-level individual managing
> a gateway for release. In general, there is no independent review
> of such changes until a merge/put-over is requested, at which time
> the benevolent dictator/gateway for the destination branch
> determines, possibly after consulting with others, whether or not
> the merge takes place.
>
> That model fits the development process at Sun today because
> there is a known hierarchy of Sun employees whose role is to act
> as a gateway manager according to the procedures set out by Sun.
>
> Coincidentally (or not), it is also the model that Linux uses
> for inclusion of code in the kernel, and what most of the Linux
> distros use for the rest of their operating systems as well
> (i.e., package maintainers as gateways).
>
> It is important to note, however, that this is not collaborative
> development in the Apache sense of development. It is open source
> by virtue of the resulting products, but not collaborative because
> there is no notion of peers in the decision-making process. It is
> truly hierarchical in both authority and life cycle -- each
> individual gateway controls its own destiny until the maintainer
> fails, at which point a new maintainer is assigned or the software
> replaced by an entirely separate line of development with its
> own maintainer. In fact, even with an active maintainer, the
> normal result of a change request is that the benevolent dictator
> takes the patch and changes it arbitrarily to fit what they
> personally feel is worth committing to their own code base.
>
> Hierarchy has the advantage of there not being a need to vote on
> decisions, but has the disadvantages of there being almost no peer
> review of independently delivered parts until very late in the
> development process (typically, long after the original developer
> has any interest in making changes to correspond to reviewer input)
> and an extreme vulnerability to benevolent dictator overload.
>
> This is in contrast to the collaborative model used by FreeBSD,
> Apache, PHP, etc., wherein almost all development takes place
> on branches within a single centralized repository viewable
> by everyone interested in the project and changes are reviewed
> as soon as they are made. This model removes barriers to entry
> from the community, allowing them to participate in development
> during the stages when their participation has the greatest
> impact (i.e., design and early prototyping). It also gives the
> public an easy way to start contributing, simply by reviewing
> commit messages as they occur and pointing out mistakes when
> they are inserted in the code.
>
> When I got involved in OpenSolaris, folks assured me that Sun
> wanted to see a governance model that reflected the collaborative
> method of open source, not the benevolent dictatorship of Linux.
> However, every time we talk to Sun engineering it seems clear that
> they assume their current model of development cannot be changed
> and thus nothing other than distributed SCM is possible. Such a
> model assumes that key Sun engineers will be the gateways and
> Sun ARCs will define the minimal criteria for gateway acceptance.
>
> I think hell will freeze over before Sun will allow any outsiders
> to be a benevolent dictator for any portion of OpenSolaris
> considered essential to Solaris. The collaborative model is safe
> for Sun because it has the effect of protecting everyone's most
> important interests (veto power on changes based on technical
> rationale) while treating everyone as peers. In contrast, the
> hierarchical model places an individual in that position and
> everyone must trust that individual to be even-handed.
> Nevertheless, it is still a valid model for OpenSolaris, since
> there is no effective difference between having a closed group
> at Sun determine who the dictators shall be versus the Linux
> method of having Linus Torvalds do the same. I should note,
> however, that Linux would have failed miserably if Linus were
> not such a nice guy that is respected by the entire community.
>
> So, I have to ask again: what is it that Sun wants in a governance
> model for OpenSolaris? Do you want a collaborative model in which
> outsiders are peers in the development process, or do you want
> a hierarchical model in which outsiders merely contribute and hope
> to obtain benefits from the process? Do you want this project to
> be more like Linux or more like FreeBSD?
>
> I can write a governance process that works one way or the
> other, but I will not write one that attempts to do both.
> Dictators and collaborative development do not mix.
Agreed on all points.
Lets put this on the agenda for todays CAB call.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 9:44 AM
in response to: alhopper
|
|
>>The model of development using a distributed SCM is for each
>>individual or team to maintain its own branches and occasionally
>>submit complete change sets to a higher-level individual managing
>>a gateway for release. In general, there is no independent review
>>of such changes until a merge/put-over is requested, at which time
>>the benevolent dictator/gateway for the destination branch
>>determines, possibly after consulting with others, whether or not
>>the merge takes place.
>>
>>That model fits the development process at Sun today because
>>there is a known hierarchy of Sun employees whose role is to act
>>as a gateway manager according to the procedures set out by Sun.
>>
>>Coincidentally (or not), it is also the model that Linux uses
>>for inclusion of code in the kernel, and what most of the Linux
>>distros use for the rest of their operating systems as well
>>(i.e., package maintainers as gateways).
This is a flawed view of Sun's development model for Solaris.
I agree, that if that *were* the proposed model, I would be
uncomfortable with it as well - "gatekeeper as dictator" is
an unacceptable state.
Fortunately, this is not the case. The difference - as I wrote
here on Aug 23
http://www.opensolaris.org/jive/thread.jspa?messageID=8058ὺ
is that the "sun-style-gatekeeper" is not the hierarchical dictator
as you might find in Linux et al.
Instead, the role of decision maker is formalized into community
based behaviors:
1) a general "do we want it?", managed entirely by
the community and expressed as intent, policy or
guidelines as needed. The suggested "three +1's
and no -1's" is one such expression.
2) a specific "is this change architecturally acceptable?",
managed by the architectural review committee(s) which
are "staffed" entirely by community members, who perform
peer review of the proposal.
The role of the "sun-style-gatekeeper" is simply to ensure that
all requested putbacks/commits have these two "approvals".
The expected work flow follows this course time line:
1. An idea for <something> germinates into
something that a part of the community
wishes to work on.
2. A proposal is generated that addresses the
architectural/technical intent of the <something>
3. The community determines whether or not the
proposed <something> fits within the norms of
their community.
4. The ARC(s?) determine whether the proposal
is acceptable; if not, it suggests/requires
changes, or it denies the proposal completely.
5. Armed with the above "approvals", the project
team goes off, creates a SCM branch to work
with, does its development however it desires,
tests it and does whatever is needed to complete
the job it signed up to do.
6. When complete, the team selects a release branch
to integrate into, and requests that its
gatekeeper integrate their changes. If the
team has obtained the above "approvals" and
the release is in a state to accept the change
(i.e., not in a formal release end-game...)
the gatekeeper is obligated to integrate the
change.
7. The team's branch is merged with the release
branch, tested, and a new release is published.
The team branch can be deleted, as it has no
more function.
The core difference, which I see as a "terminology" rather than
"practice" disconnect, is the impact of where a branch is maintained.
You seem to equate "distributed SCM" with pushing branch development
out of the public view, with the only alternative of forcing all
branch development to take place in a single centralized repository.
I don't think that this matters much, as long as all the sub-
communities that are working on O.S. things have a branch that
is available in a place where they can all work on it together.
> Such a
> model assumes that key Sun engineers will be the gateways and
> Sun ARCs will define the minimal criteria for gateway acceptance.
I'd rewrite this:
Such a model assumes that key _community_ engineers will be the
gateways and _community staffed_ ARCs will define the minimal
criteria for gateway acceptance.
(of course, as we transition from "current status quo" to this
future state, there will be a time at the beginning where the
gatekeepers will be Sun engineers (Hi Danek!) and the ARCs will
be staffed by Sun engineers (Hi PSARC!), but this *will* change)
Your points about Apache (et al) are exactly my target as well:
The collaborative model is safe for Sun because it
has the effect of protecting everyone's most important
interests (veto power on changes based on technical
rationale) while treating everyone as peers.
A hierarchical model in which outsiders merely contribute and hope
to obtain benefits from the process is flawed and can not work.
-John
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 10:14 AM
in response to: plocher
|
|
On 10/12/05, John Plocher <John dot Plocher at sun dot com> wrote:
John,
I understand that the flow below is your view of how tings suppose
to work in OpenSolaris, right ? If so I quite disagree with you.
See below:
>
> The expected work flow follows this course time line:
>
> 1. An idea for <something> germinates into
> something that a part of the community
> wishes to work on.
Naturally.
> 2. A proposal is generated that addresses the
> architectural/technical intent of the <something>
This may or may not be the case... Sometimes people just
want to experiment in order to _get_ to proposals.
They still however are part of the community and have a right
for existance.
> 3. The community determines whether or not the
> proposed <something> fits within the norms of
> their community.
That step is unneeded, IMHO. Community can come and go
as needed. It should not be something with hard walls and
boundaries. In any case the whole [special] community
existance should have nothing to do with the development.
And indeed it so today - look at UG community.
> 4. The ARC(s?) determine whether the proposal
> is acceptable; if not, it suggests/requires
> changes, or it denies the proposal completely.
That seems to be WAY to wrong to me. Do you really suggest
that in order to develop something for OpenSolaris I need
ARC (or whatever other comitee) approval ??? That may be
the case for the Sun corporate environment, where engineering
resources need to be quantified (since they are finite) and used
wisely. However, in the open world no ARC can tell me what to
do. Insisting on that role for ARC will only provocate forks and serve
little good to the community at large.
> 5. Armed with the above "approvals", the project
> team goes off, creates a SCM branch to work
> with, does its development however it desires,
> tests it and does whatever is needed to complete
> the job it signed up to do.
Once again, what prevents me from doing it even today ?
Without any ARC approval ? Heck, Polaris community did
it already. So what's the point ?
> 6. When complete, the team selects a release branch
> to integrate into, and requests that its
> gatekeeper integrate their changes. If the
> team has obtained the above "approvals" and
> the release is in a state to accept the change
> (i.e., not in a formal release end-game...)
> the gatekeeper is obligated to integrate the
> change.
That has to be different, since at this point intervention of
ARC (or any other relevant comitee) may (should?) be required
in order to determine the eligibility of the project integration into the
main release.
> 7. The team's branch is merged with the release
> branch, tested, and a new release is published.
> The team branch can be deleted, as it has no
> more function.
Right, no problems here :)
I have overall impression that the whole model is an adaptation
of the Sun' current scheme to a wider audience. I believe that
it cannot go that way. You just cannot manage the community
as a group of Sun employees. And if you'll create a a tough
rules, people will leave. That should no happen.
Regards,
Cyril
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
803
From:
Plano, TX
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 11:23 AM
in response to: imp
|
|
On Wed, 12 Oct 2005, Cyril Plisko wrote:
> On 10/12/05, John Plocher <John dot Plocher at sun dot com> wrote:
> John,
>
> I understand that the flow below is your view of how tings suppose
> to work in OpenSolaris, right ? If so I quite disagree with you.
> See below:
>
> >
> > The expected work flow follows this course time line:
> >
> > 1. An idea for <something> germinates into
> > something that a part of the community
> > wishes to work on.
>
> Naturally.
>
> > 2. A proposal is generated that addresses the
> > architectural/technical intent of the <something>
>
> This may or may not be the case... Sometimes people just
> want to experiment in order to _get_ to proposals.
> They still however are part of the community and have a right
> for existance.
>
> > 3. The community determines whether or not the
> > proposed <something> fits within the norms of
> > their community.
>
> That step is unneeded, IMHO. Community can come and go
> as needed. It should not be something with hard walls and
> boundaries. In any case the whole [special] community
> existance should have nothing to do with the development.
> And indeed it so today - look at UG community.
>
> > 4. The ARC(s?) determine whether the proposal
> > is acceptable; if not, it suggests/requires
> > changes, or it denies the proposal completely.
>
> That seems to be WAY to wrong to me. Do you really suggest
> that in order to develop something for OpenSolaris I need
> ARC (or whatever other comitee) approval ??? That may be
> the case for the Sun corporate environment, where engineering
> resources need to be quantified (since they are finite) and used
> wisely. However, in the open world no ARC can tell me what to
> do. Insisting on that role for ARC will only provocate forks and serve
> little good to the community at large.
There are a couple of points to be made here.
a) This review is necessary only for someone who wants to see their work
ultimately integrated into Solaris - the commercial project. If your
intent is not to have the work integrated - then you don't need to bother
with this. But ... see more below.
b) If you do intend to see your work integrated into Solaris, the
commercial distribution of OpenSolaris, then early review is intended to
catch "silly" things like:
- someone else is already 80% done with what you're proposing
- someone else tried your (technical) approach before and found it not to
work. So the ARC will tell you why it did'nt work and what was flawed with
it. And possibly make available the associated email threads - or at least
a sanitized version of them.
- there is a design/architecture decision you've made that violates one of
the Solaris core values, like, for example, backward compatibility etc.
- there is a design decision you've made that is not compatible with the
future direction of OpenSolaris
- you've missed some key functionality that is necessary to integrate it
successfully. For example, to support truss, or zones or DTrace or blah,
blah.
- you're suggesting a software architecture that might be fine in a
userland application, but could cause not deterministic behavior in an OS
kernel; or cause unexpected and objectionable response time hiccups to
other applications etc.
The early ARC review may also help you sharpen your development skills -
becuase it'll allow you to tap into a bunch of engineering talent with a
proven track record of success. Or prevent you from making a silly error
by omission etc.
--- topic change ---
Three members of the CAB have been closely involved with the Development
Process re-engineering efforts that have been a work in progress for
several months now. That work is close to initial/draft publication, and I
think, that when you see the entire process, and not a simplified summary
of it that John P provided, it'll make more sense and be acceptable to the
majority of serious OpenSolaris developers IMHO.
I can understand your initial reaction to Johns email ... but please
reserve judgement until you see the entire process. I think that you'll
find that most of what that process describes is already being done by most
serious developers. But many developers probably have not seen it written
down, or formalized before.
The intent is to help and not hinder the development process and to insure
a painless integration of your work into Solaris - while maintaining the
level of reliability, correctness and stability that Solaris is well known
for.
Don't forget that OpenSolaris members will be able to particpate at every
point in the process.
So .... please hang in there for a little longer until you see the entire
development process published. I think it'll be a easy "sell" for most
serious developers.
> > 5. Armed with the above "approvals", the project
> > team goes off, creates a SCM branch to work
> > with, does its development however it desires,
> > tests it and does whatever is needed to complete
> > the job it signed up to do.
>
> Once again, what prevents me from doing it even today ?
> Without any ARC approval ? Heck, Polaris community did
> it already. So what's the point ?
>
> > 6. When complete, the team selects a release branch
> > to integrate into, and requests that its
> > gatekeeper integrate their changes. If the
> > team has obtained the above "approvals" and
> > the release is in a state to accept the change
> > (i.e., not in a formal release end-game...)
> > the gatekeeper is obligated to integrate the
> > change.
>
> That has to be different, since at this point intervention of
> ARC (or any other relevant comitee) may (should?) be required
> in order to determine the eligibility of the project integration into the
> main release.
>
>
> > 7. The team's branch is merged with the release
> > branch, tested, and a new release is published.
> > The team branch can be deleted, as it has no
> > more function.
>
> Right, no problems here :)
>
>
> I have overall impression that the whole model is an adaptation
> of the Sun' current scheme to a wider audience. I believe that
> it cannot go that way. You just cannot manage the community
> as a group of Sun employees. And if you'll create a a tough
> rules, people will leave. That should no happen.
>
>
> Regards,
> Cyril
>
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 12:38 PM
in response to: alhopper
|
|
On 10/12/05, Al Hopper <al@logical-approach.com> wrote:
> On Wed, 12 Oct 2005, Cyril Plisko wrote:
Al,
I can see your point, however, I do have a couple of thoughts,
See below:
>
> There are a couple of points to be made here.
>
> a) This review is necessary only for someone who wants to see their work
> ultimately integrated into Solaris - the commercial project. If your
> intent is not to have the work integrated - then you don't need to bother
> with this. But ... see more below.
>
> b) If you do intend to see your work integrated into Solaris, the
> commercial distribution of OpenSolaris, then early review is intended to
> catch "silly" things like:
That's quite a dangerous choice of wording, 'cause it sounds like Solaris
as an OpenSolaris-based distribution is special compared to others.
I am sure that was not your intention.
>
> - someone else is already 80% done with what you're proposing
That shouldn't be ARC responsibility - for open source project that
information should be available anyway. If Sun wants to brew some
secret project without any community involvement (that's their right,
of course) I wouldn't consider that case in the scope of OpenSolaris.
Moreover, in such a case how can ARC or some other _community_
based committee be aware of such a project at all ?
> - someone else tried your (technical) approach before and found it not to
> work. So the ARC will tell you why it did'nt work and what was flawed with
> it. And possibly make available the associated email threads - or at least
> a sanitized version of them.
>
That's a valid point, however I'd (again) expect that info to be available
anyway, right ?
> - there is a design/architecture decision you've made that violates one of
> the Solaris core values, like, for example, backward compatibility etc.
>
> - there is a design decision you've made that is not compatible with the
> future direction of OpenSolaris
>
> - you've missed some key functionality that is necessary to integrate it
> successfully. For example, to support truss, or zones or DTrace or blah,
> blah.
>
> - you're suggesting a software architecture that might be fine in a
> userland application, but could cause not deterministic behavior in an OS
> kernel; or cause unexpected and objectionable response time hiccups to
> other applications etc.
All these should prevent the integration, not the work itself.
>
> The early ARC review may also help you sharpen your development skills -
> becuase it'll allow you to tap into a bunch of engineering talent with a
> proven track record of success. Or prevent you from making a silly error
> by omission etc.
That's why we have mailing lists/forums/etc, right ? Why do we need another
committee to do this ?
>
> --- topic change ---
>
> Three members of the CAB have been closely involved with the Development
> Process re-engineering efforts that have been a work in progress for
> several months now. That work is close to initial/draft publication, and I
> think, that when you see the entire process, and not a simplified summary
> of it that John P provided, it'll make more sense and be acceptable to the
> majority of serious OpenSolaris developers IMHO.
Cool !
>
> I can understand your initial reaction to Johns email ... but please
> reserve judgement until you see the entire process. I think that you'll
> find that most of what that process describes is already being done by most
> serious developers. But many developers probably have not seen it written
> down, or formalized before.
>
>
> The intent is to help and not hinder the development process and to insure
> a painless integration of your work into Solaris - while maintaining the
> level of reliability, correctness and stability that Solaris is well known
> for.
>
> Don't forget that OpenSolaris members will be able to particpate at every
> point in the process.
>
> So .... please hang in there for a little longer until you see the entire
> development process published. I think it'll be a easy "sell" for most
> serious developers.
>
I will. Looking forward to see the doc.
Regards,
Cyril
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 2:36 PM
in response to: imp
|
|
[I want to amplify Al's comment that the intent of all this
is to help and not hinder the development process and to
insure a painless integration of your work into [Open]Solaris
- John]
Cyril Plisko wrote:
>> John Plocher wrote:
>> 2. A proposal is generated that addresses the
>> architectural/technical intent of the <something>
>
>
> This may or may not be the case... Sometimes people just
> want to experiment in order to _get_ to proposals.
I probably should have prefaced this all with a few assumptions:
"This is for projects that wish to integrate back into OpenSolaris,
and does not affect any private tinkering or investigation done
without that intent" - and - "at some point, with zero or more
tinkering and prototyping, an idea will germinate into a proposal.
How exactly that happens is out of scope for this discussion."
> They still however are part of the community and have a right
> for existence.
Right, but. :-)
The "but" is they don't have a right to be integrated back into
the community's source tree until and unless the community wants
it. This is not anarchy.
One of the benefits of a distributed SCM environment is that
anyone can create their own branch, play with it however they
wish, and relatively effortlessly keep it in sync and up to
date with the community.
>> 3. The community determines whether or not the
>> proposed <something> fits within the norms of
>> their community.
>
>
> That step is unneeded, IMHO. Community can come and go
> as needed. It should not be something with hard walls and
> boundaries. In any case the whole [special] community
> existance should have nothing to do with the development.
> And indeed it so today - look at UG community.
Glossary overload. Does Community := OpenSolaris or does
community := "some discussion forum" or ...?
In the governance proposal, there is postulated a community that
is self-responsible for its work-product. The above is simply
restating that point for things that intend to go back into the
official source tree. It obviously does not apply for things
that don't so intend.
>> 4. The ARC(s?) determine whether the proposal
>> is acceptable; if not, it suggests/requires
>> changes, or it denies the proposal completely.
>
> That seems to be WAY to wrong to me. Do you really suggest
> that in order to develop something for OpenSolaris I need
> ARC (or whatever other comitee) approval???
No, not at all - for development. Rather, if you intend to
incorporate the result INTO OpenSolaris, the community needs
to understand and approve the impact - if any. Things that
don't impact the architecture of the system obviously don't
need architectural review.
This means that for 80+% of things, this step turns into a NOOP.
For the other 20%, it is much better to do this interaction
early (when there is still a chance to influence the effort),
rather than at the point of integration when there isn't.
> That may be
> the case for the Sun corporate environment, where engineering
> resources need to be quantified (since they are finite) and used
This isn't a resource allocation issue at all - it is a
"develop software by intent rather than by accident" one.
> wisely. However, in the open world no ARC can tell me what to
> do. Insisting on that role for ARC will only provocate forks and serve
> little good to the community at large.
Right - the ARCs don't exist to tell you what you can or can't
work on, but rather they exist to help you figure out what
architectural constraints or challenges your efforts will face
if/when they integrate back into the main source tree.
For example:
Suppose you want to gratuitously change the open()
call in libc in such a way that would break all
existing programs.
You can work on this effort as much as you want,
but you _should_ face difficulties if/when you attempt
to integrate the change back into OpenSolaris.
It is the role of the community architects (aka ARC
members) to manage the evolution of the system.
> Once again, what prevents me from doing it even today ?
> Without any ARC approval ? Heck, Polaris community did
> it already. So what's the point ?
If you want the OpenSolaris community to incorporate
your changes into the official OpenSolaris source base...
> I have overall impression that the whole model is an adaptation
> of the Sun' current scheme to a wider audience.
Certainly - this is the process that gives Solaris the stability
and predictability that is valued by Sun and its customers. IMHO,
it would be foolish to abandon that process and let OpenSolaris
devolve into a more chaotic system. (It would also be foolish
to force Sun's existing system on the community, or to assume that
such a process should be static and not evolve over time...)
> And if you'll create a a tough
> rules, people will leave. That should no happen.
One of the differentiators of the OpenSolaris community
is that it values reliability, correctness and stability;
attributes that come directly from the development process
used. As Al said, please hang in there...
-John
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Hugh McIntyre
Hugh.McIntyre@Sun.COM
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 2:27 PM
in response to: fielding
|
|
|> > b) If you do intend to see your work integrated into Solaris, the
|> > commercial distribution of OpenSolaris, then early review is intended to
|> > catch "silly" things like:
|>
|> That's quite a dangerous choice of wording, 'cause it sounds like Solaris
|> as an OpenSolaris-based distribution is special compared to others.
|> I am sure that was not your intention.
IMHO at least it should say something like "want to get your code integrated to
the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into
Solaris" necessarily.
|> > - someone else is already 80% done with what you're proposing
|>
|> That shouldn't be ARC responsibility - for open source project that
|> information should be available anyway.
|>
|> > - someone else tried your (technical) approach before and found it not to
|> > work. So the ARC will tell you why it did'nt work and what was flawed
|>
|> That's a valid point, however I'd (again) expect that info to be available
|> anyway, right ?
Not everybody knows everything. I.e. even if the information is publically
available you may not have found it. I'm sure this already happens within Sun
sometimes, so it's not an inside-versus-outside-Sun thing. Although the
inside/outside problem makes this worse since clearly there's a bunch of
historical information that's not public, now at least.
This part of the process could mainly be thought of as a chance for a courtesy
warning to warn people before they spend 6 months working on something and then
find out at the end that it's already been done or that a lot of changes might
be requested at the end. [*]
If doing this via ARC seems too formal (maybe it is) think of this in terms of
sending mail to the relevant community mailing list for comments instead. You
can still work on the feature yourself if you don't like the comments, but it
may help to avoid wasted time.
Hugh.
[*] One difference for OpenSolaris is that inside Sun if there is a team working
on a project, there's presumably an assumption (in general at least) that the
project will be done as promised. Whereas not every external developer is
working on things full time (or is paid), so just because someone else is
working on a project does not guarantee it will get finished. I.e. just because
you get told "someone else is already 80% done" does not mean you can't work on
it.
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
803
From:
Plano, TX
Registered:
4/27/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 12, 2005 6:06 PM
in response to: Hugh McIntyre
|
|
On Wed, 12 Oct 2005, Hugh McIntyre wrote:
>
> |> > b) If you do intend to see your work integrated into Solaris, the
> |> > commercial distribution of OpenSolaris, then early review is intended to
> |> > catch "silly" things like:
> |>
> |> That's quite a dangerous choice of wording, 'cause it sounds like Solaris
> |> as an OpenSolaris-based distribution is special compared to others.
> |> I am sure that was not your intention.
>
> IMHO at least it should say something like "want to get your code integrated to
> the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into
> Solaris" necessarily.
Agreed. It was poorly worded. I was in the middle of about 3 things when
I saw the post and made an effort to respond to it ASAP.
> |> > - someone else is already 80% done with what you're proposing
> |>
> |> That shouldn't be ARC responsibility - for open source project that
> |> information should be available anyway.
> |>
> |> > - someone else tried your (technical) approach before and found it not to
> |> > work. So the ARC will tell you why it did'nt work and what was flawed
> |>
> |> That's a valid point, however I'd (again) expect that info to be available
> |> anyway, right ?
>
> Not everybody knows everything. I.e. even if the information is publically
> available you may not have found it. I'm sure this already happens within Sun
> sometimes, so it's not an inside-versus-outside-Sun thing. Although the
> inside/outside problem makes this worse since clearly there's a bunch of
> historical information that's not public, now at least.
Its easy to understand when you have a complex set of related software
systems that are used to manage very large software development projects
and the concept of going public at some point in the future was never
considered. Since these tools also manage client/customer/partner data and
data related to new products/projects, you can easily see that its almost
impossible to "split the baby".
> This part of the process could mainly be thought of as a chance for a courtesy
> warning to warn people before they spend 6 months working on something and then
> find out at the end that it's already been done or that a lot of changes might
> be requested at the end. [*]
>
> If doing this via ARC seems too formal (maybe it is) think of this in terms of
> sending mail to the relevant community mailing list for comments instead. You
> can still work on the feature yourself if you don't like the comments, but it
> may help to avoid wasted time.
>
> Hugh.
>
> [*] One difference for OpenSolaris is that inside Sun if there is a team working
> on a project, there's presumably an assumption (in general at least) that the
> project will be done as promised. Whereas not every external developer is
> working on things full time (or is paid), so just because someone else is
> working on a project does not guarantee it will get finished. I.e. just because
> you get told "someone else is already 80% done" does not mean you can't work on
> it.
>
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
151
From:
US
Registered:
5/11/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 16, 2005 10:00 PM
in response to: alhopper
|
|
Thanks to everyone who responded to this thread. I hope people like Hugh
helped to allay some of the fears being expressed. Stephen Hahn has been
out of the office, and I'm not sure if he'll jump in on this when he
returns.
In any case, there are a couple of things I wanted to mention:
1. A "distributed source code management system" describes the type of
functionality we've found essential to managing a large source base
with so many developers. This kind of system allows developers to
make and test large- or small-scale changes without destabilizing
the main source tree.
In the end it all comes back into the main source tree, and others
have done a good job describing the way our gatekeeping system
works. Without listening to lengthy process descriptions like the
ones Al and Rich have participated in, it may be difficult to
understand that Sun/Solaris doesn't have a dictator: benevolent or
otherwise.
2. The requirements for making a decision about a distributed source
code management system have not yet been proposed. Stephen Hahn
will absolutely send the initial requirements list out to the
community, and have the discussion in the public. There is no
"black op" happening here. We're just not moving as quickly as
we'd like.
Perhaps you all can give us some ideas about how best to keep the
community informed about our progress (or lackthereof).
3. It is my belief that the governance model can be written without
any further guidance from Sun. The CAB should write what they
think is best for the OpenSolaris community, and then it is up to
the community and Sun to ratify it.
Thanks,
Karyn
Al Hopper wrote:
> On Wed, 12 Oct 2005, Hugh McIntyre wrote:
>
>
>>|> > b) If you do intend to see your work integrated into Solaris, the
>>|> > commercial distribution of OpenSolaris, then early review is intended to
>>|> > catch "silly" things like:
>>|>
>>|> That's quite a dangerous choice of wording, 'cause it sounds like Solaris
>>|> as an OpenSolaris-based distribution is special compared to others.
>>|> I am sure that was not your intention.
>>
>>IMHO at least it should say something like "want to get your code integrated to
>>the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into
>>Solaris" necessarily.
>
>
> Agreed. It was poorly worded. I was in the middle of about 3 things when
> I saw the post and made an effort to respond to it ASAP.
>
>
>>|> > - someone else is already 80% done with what you're proposing
>>|>
>>|> That shouldn't be ARC responsibility - for open source project that
>>|> information should be available anyway.
>>|>
>>|> > - someone else tried your (technical) approach before and found it not to
>>|> > work. So the ARC will tell you why it did'nt work and what was flawed
>>|>
>>|> That's a valid point, however I'd (again) expect that info to be available
>>|> anyway, right ?
>>
>>Not everybody knows everything. I.e. even if the information is publically
>>available you may not have found it. I'm sure this already happens within Sun
>>sometimes, so it's not an inside-versus-outside-Sun thing. Although the
>>inside/outside problem makes this worse since clearly there's a bunch of
>>historical information that's not public, now at least.
>
>
> Its easy to understand when you have a complex set of related software
> systems that are used to manage very large software development projects
> and the concept of going public at some point in the future was never
> considered. Since these tools also manage client/customer/partner data and
> data related to new products/projects, you can easily see that its almost
> impossible to "split the baby".
>
>
>>This part of the process could mainly be thought of as a chance for a courtesy
>>warning to warn people before they spend 6 months working on something and then
>>find out at the end that it's already been done or that a lot of changes might
>>be requested at the end. [*]
>>
>>If doing this via ARC seems too formal (maybe it is) think of this in terms of
>>sending mail to the relevant community mailing list for comments instead. You
>>can still work on the feature yourself if you don't like the comments, but it
>>may help to avoid wasted time.
>>
>>Hugh.
>>
>>[*] One difference for OpenSolaris is that inside Sun if there is a team working
>>on a project, there's presumably an assumption (in general at least) that the
>>project will be done as promised. Whereas not every external developer is
>>working on things full time (or is paid), so just because someone else is
>>working on a project does not guarantee it will get finished. I.e. just because
>>you get told "someone else is already 80% done" does not mean you can't work on
>>it.
>>
>
>
> Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
> Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
> OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
> _______________________________________________
> cab-discuss mailing list
> cab-discuss at opensolaris dot org
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 17, 2005 10:15 AM
in response to: kritter
|
|
Karyn Ritter wrote
> 3. It is my belief that the governance model can be written without
> any further guidance from Sun.
IMHO, you might want to make a distinction between "Sun as a corporate
entity" and "Sun employees who are members of this community".
If you meant the former: +1
If you meant ther latter, -1 - nothing in this community's DNA should
prevent Sun employees from being first class members - we should not
set up a system (of rules, expectations or assumptions) where external
voices are somehow different than internal ones. We all are community
members, and we honor openness and inclusiveness.
> The CAB should write what they
> think is best for the OpenSolaris community, and then it is up to
> the community and Sun to ratify it.
The CAB shouldn't be expected to invent stuff that doesn't reflect the
community - a model of
"we control the content, all you can do is say yes or no,
without an ability to influence it"
would be a bad thing - fortunately, the CAB isn't operating that way.
-John Plocher
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Karyn Ritter
kritter@eng.sun.com
|
|
|
|
Re: SCM and its effect on governance
Posted:
Oct 17, 2005 10:19 AM
in response to: plocher
|
|
John Plocher wrote:
> Karyn Ritter wrote
>
>> 3. It is my belief that the governance model can be written without
>> any further guidance from Sun.
>
>
> IMHO, you might want to make a distinction between "Sun as a corporate
> entity" and "Sun employees who are members of this community".
>
> If you meant the former: +1
>
Yes, this is what I meant. I was responding to Roy's comment that Sun
needed to provide guidance about what we want before the CAB can write
the governance proposal.
Thanks,
Karyn
> If you meant ther latter, -1 - nothing in this community's DNA should
> prevent Sun employees from being first class members - we should not
> set up a system (of rules, expectations or assumptions) where external
> voices are somehow different than internal ones. We all are community
> members, and we honor openness and inclusiveness.
>
>> The CAB should write what they
>> think is best for the OpenSolaris community, and then it is up to
>> the community and Sun to ratify it.
>
>
> The CAB shouldn't be expected to invent stuff that doesn't reflect the
> community - a model of
> "we control the content, all you can do is say yes or no,
> without an ability to influence it"
> would be a bad thing - fortunately, the CAB isn't operating that way.
>
> -John Plocher
>
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
