I guess this is a question for Wayne, how do you want us to proceed?
We can start with dot4zest right away, we have a committer with code
who wants to check into CVS and take advantage of parallel IP. There
are CQs for some of the code already. We can do an new GEF committer
election right away?
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Inactive hide details for Doug Schaefer ---2010/02/11 12:18:29
PM---BTW, where did this end up? Ian and Anthony are you workingDoug
Schaefer ---2010/02/11 12:18:29 PM---BTW, where did this end up? Ian
and Anthony are you working together on a plan for a path forward?
From:
Doug Schaefer <cdtdoug@xxxxxxxxx>
To:
Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
Date:
2010/02/11 12:18 PM
Subject:
Re: [tools-pmc] GEF Incubator Proposal
------------------------------------------------------------------------
BTW, where did this end up? Ian and Anthony are you working together
on a plan for a path forward?
BTW2, Boris, feel free to speak up here. I think it's important that
we get your insight to help resolve this matter.
Doug.
On Tue, Feb 9, 2010 at 10:43 AM, Doug Schaefer <_cdtdoug@gmail.com_
<mailto:cdtdoug@xxxxxxxxx>> wrote:
Excellent. Thanks Wayne and Anthony. I think [3] would be huge
boost for the GEF community. The CDT has a pretty big committer
set and the social conventions work well. Peer pressure is what
keeps everything in check. The benefits well outweigh the risks.
Doug.
On Tue, Feb 9, 2010 at 10:37 AM, Wayne Beaton
<_wayne@eclipse.org_ <mailto:wayne@xxxxxxxxxxx>> wrote:
As long as you are not expecting fine-grained access control to
the code repository, #3 sounds grand to me. We are moving toward
our established ideal of having one UNIX group for each project.
That means that every committer gets access to every part of the
repository. Restrictions are managed using social conventions.
>From my POV, there is some risk (albeit small) that committers
with ability to touch all parts of the GEF repository, but
limited understanding of their place in it may do unintentional
damage. Or worse, intentional damage.
Wayne
Anthony Hunter wrote:
Hi Wayne
Can we do this?
[3] I run committer elections for new developers who want
to work in GEF. The new committers complete the new
commiter forms and for foundation gets them processed.
They are then "legal" to work on the code in the exiting
GEF project. There is no risk here since they are working
on a portion of their code in the GEF repository.
Is creating an incubator going to be faster than [3] ?
My only push back is that I would like to see new
committers and their GEF work being done on in GEF and not
"somewhere else".
If we really feel a GEF incubator is the only way, then
you have my support.
Cheers...
Anthony
--
Anthony Hunter mailto:_anthonyh@xxxxxx.com_
<mailto:anthonyh@xxxxxxxxxx>
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Inactive hide details for Wayne Beaton ---2010/02/08
10:52:21 PM---I would like to better understand where the
push back is comWayne Beaton ---2010/02/08 10:52:21 PM---I
would like to better understand where the push back is
coming from. Anthony, are you concerned that this means
more work? Or
From:
Wayne Beaton <_wayne@eclipse.org_ <mailto:wayne@xxxxxxxxxxx>>
To:
Tools PMC mailing list <_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>
Date:
2010/02/08 10:52 PM
Subject:
Re: [tools-pmc] GEF Incubator Proposal
------------------------------------------------------------------------
I would like to better understand where the push back is
coming from. Anthony, are you concerned that this means
more work? Or that the work will be split? Or that it will
be confusing for the community? Or confusing for somebody
else? I'm having trouble understanding the underlying
problem. Sorry.
IMHO, Ian's item #2 is probably one of the best reasons to
create an incubator. Unfortunately, being a committer is a
binary state on a project: either you have access or you
do not. Earlier attempts at finer-grained access have
resulted in lots of misery for all involved.
Without the incubator, existing GEF committers will have
to work with contributors for any contribution. This takes
time away from other important GEF activities, like
working on in-plan items.
In the incubator, you can have a different set of
committers (which may intersect with the GEF committers)
managing off-plan contributions from the community while
working on new and innovative ideas. All this, under the
supervision of the "parent" GEF project. Some of these
contributors can become committers on the incubator and
learn the social conventions while they work on their cool
new ideas; making these people committers on the incubator
will reduce the time requirements from GEF committers
(though somebody will have to monitor these new committers
to make sure that the development process is followed).
This pattern has been followed by numerous mature projects.
I'm thinking of ways that we can make this better. Some
thoughts:
1) Change the EDP so that mature projects can designate a
portion of their code repository as their "incubator" and
allow this portion to have its own set of committers, and
leverage parallel IP. This would require significant
change to the processes the Foundation has in place; as I
go through the mental exercise, it all feels just a little
too cumbersome.
2) Relax some of the requirements on (some) projects.
There is some minimal project data at needs to be provided
via the portal (like description, source code URLs, that
sort of thing). Incubators, at least, shouldn't have to
have releases. Do they need to have plans? If we reduce
the requirements placed on an "incubator" project, does
that make creating one more palatable? I've been
discussing this in my blog [1] and in bug 300000 [2]
Wayne
[1]
__http://dev.eclipse.org/blogs/wayne/2010/01/28/acknowledging-incubators/__
[2] __https://bugs.eclipse.org/bugs/show_bug.cgi?id=300000__
Ian Bull wrote:
Actually, while I think making this part of GEF
proper
could work, the more I think about it the more an
incubator makes sense.
1. GEF is clearly a mature project in
maintenance mode.
Many of the ideas being presented in this
proposal stray
well off the beaten path. An incubator will
help ensure
that GEF maintains it's current direction in
the short
term, with the possibilty of new ideas flowing
in down the
road.
2. The people doing the work are (for the most
part) not
active committers on other projects. An
incubator will
give us a chance to help mentor them.
3. The GEF project, follows a similar plan as
the platform
(with respect to schedules, etc...). Forcing
new ideas to
follow API freeze rules (for example) will only
stiffle
innovation.
We could, if it makes more sense, propose this
project
under "Technology". But since this is tied
closely to GEF,
a tools project (IMHO) seems appropriate.
cheers,
ian
On Wed, Feb 3, 2010 at 9:02 AM, Doug Schaefer
<_cdtdoug@gmail.com_
<mailto:_cdtdoug@gmail.com_ <mailto:cdtdoug@xxxxxxxxx>>>
wrote:
On Wed, Feb 3, 2010 at 10:23 AM, Wayne Beaton
<_wayne@eclipse.org_
<mailto:_wayne@eclipse.org_ <mailto:wayne@xxxxxxxxxxx>>>
wrote:
Another benefit is that you can have a
lower bar for
committers on the incubator. You can use the
incubator to grow folks into committer-worthy
status. Just a thought
The bar is as high as the existing
committers set
it. ;). I'm still hoping for the "Eclipse
Labs"
concept to develop so we can create such
sandboxes
there.
Wayne
Doug Schaefer wrote:
BTW, the only benefit would be
parallel IP.
You can do those other things
without the
hassle of creating and managing a
second
project. And even parallel IP could
be handled
by storing the initial code off
site. Until
it's ready for the review.
Of course, if you want to do it,
I'm fine with
that. It just a pet peave of mine.
On Feb 3, 2010 8:56 AM, "Ian Bull"
<_irbull@eclipsesource.com_
<mailto:_irbull@eclipsesource.com_
<mailto:irbull@xxxxxxxxxxxxxxxxx>>
<mailto:_irbull@eclipsesource.com_
<mailto:_irbull@eclipsesource.com_
<mailto:irbull@xxxxxxxxxxxxxxxxx>>>> wrote:
I don't know, that's a good question. I
thought that incubators provided a
number of
advantages for new projects and new
ideas,
such as:
* Parallel IP
* Pre 1.0 (wrt to API)
* A clear indication to early
adopters of what
to expect
I don't have a problem with
creating this work
as a sub component of GEF, although
some of
this work is clearly "incubation"
style work
(new ideas with undefined API that will
hopefully graduate -- but that will
depend on
the quality and demand of the work
being done).
Anthony, as the GEF lead, what do
you tihnk?
cheers,
ian
On Tue, Feb 2, 2010 at 10:20 PM,
Doug Schaefer
<_cdtdoug@gmail.com_
<mailto:_cdtdoug@gmail.com_
<mailto:cdtdoug@xxxxxxxxx>>
<mailto:_cdtdoug@gmail.com_
<mailto:_cdtdoug@gmail.com_
<mailto:cdtdoug@xxxxxxxxx>>>> wrote: > > I am
on the record a...
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>
<mailto:_tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>>
_
___https://dev.eclipse.org/mailman/listinfo/tools-pmc__
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>_
___https://dev.eclipse.org/mailman/listinfo/tools-pmc__
-- Wayne Beaton, The
Eclipse Foundation_
__http://www.eclipse.org_
<_http://www.eclipse.org/_>
I'm going to EclipseCon!_
__http://www.eclipsecon.org_
<_http://www.eclipsecon.org/_>
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>_
___https://dev.eclipse.org/mailman/listinfo/tools-pmc__
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>_
___https://dev.eclipse.org/mailman/listinfo/tools-pmc__
-- R. Ian Bull | EclipseSource
Victoria | +1 250 477 7484_
__http://eclipsesource.com_
<_http://eclipsesource.com/_> |
__http://twitter.com/eclipsesource__
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list
_tools-pmc@eclipse.org_
<mailto:_tools-pmc@eclipse.org_
<mailto:tools-pmc@xxxxxxxxxxx>>
__https://dev.eclipse.org/mailman/listinfo/tools-pmc__
--
Wayne Beaton, The Eclipse Foundation
_http://www.eclipse.org_ <_http://www.eclipse.org/_>
I'm going to EclipseCon!
_http://www.eclipsecon.org_ <_http://www.eclipsecon.org/_>
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_ <mailto:tools-pmc@xxxxxxxxxxx>_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_ <mailto:tools-pmc@xxxxxxxxxxx>_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
--
Wayne Beaton, The Eclipse Foundation_
__http://www.eclipse.org_ <http://www.eclipse.org/>
I'm going to EclipseCon!_
__http://www.eclipsecon.org_ <http://www.eclipsecon.org/>
_______________________________________________
tools-pmc mailing list_
__tools-pmc@eclipse.org_ <mailto:tools-pmc@xxxxxxxxxxx>_
__https://dev.eclipse.org/mailman/listinfo/tools-pmc_
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
------------------------------------------------------------------------
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
