Guys,
Please don't take offense at my meddling, but one problem that I see is
that attempts to do incubation type things in GEF have simply failed.
Dredging through some recent notes, I see comments like this.
This is by my count the third request for a GEF incubator.
I will
repeat what I said to the others, make it so, if there is a need, make
it happen.
Apparently several folks do feel there is a need and are trying to make
it happen...
The same note exchange includes an attempt by Alexander Nyssen to get
involved. He introduces himself like this:
I am a Software
Engineer, working for itemis in Germany, where I am very much involved
in graphical editors and graphical modeling tools (I develop GEF and
GMF based tools and I am also itemis' coach for providing GEF-based
courses and customer on-site coaching). Not only because of my job, but
also personally I am pretty much interested in the GEF project, and I
have worked with and actively followed it already 5 years before
getting employed at itemis (during which time I was a Ph.D. student at
RWTH Aachen University, where as part of my research project I have
build graphical editors with GEF as well).
During those years of intensive work with the GEF framework, I
have very much learned to appreciate what is there, but I have also
identified weaknesses and collected some ideas of what could be
improved. The reason I have not very much appeared as a contributor to
the GEF project so far is not a lack of interest. It is just that two
smaller patches I have contributed to it (195527 and 245182) have not
caused much response, and because I had already gathered some
bad experiences with working intensively as a non-committing
contributor on another project (I had completely refactored TPTP's AUTO
GUI recorder to support the recording of figures in a GEF graphical
viewer in terms of bug 133099 in early 2008, having spent days and
weeks of work on it; the patch has been moved from target milestone to
target milestone since, still not having been adopted till today).
However, this is another story, I just wanted to bring it as an
argument for my sudden "emerging".
Let me therefore state that I would like to help bringing the
GEF project forward. As I very much appreciate the Eclipse way of
becoming a committer, it would also be quite fine for me to start
helping the project with some active contribution, as long as I can be
sure that my work is somehow taken into account. Maybe we can exchange
ourselves about what could be a suitable starting point.
What I discussed with Ed at the Eclipse Summit Europe however
is yet another issue. I think that a lot of improvements could be
brought to the project with the need of having to break the current
API. As I understand that API stability is pretty much important for
GEF, because a lot of products build on top of it, an incubation
project in the style of e4 could indeed be a very good way of achieving
both. As I already stated to Ed I would be willing to take
responsibility for such an approach (I would definitely like to "make
it happen", and I also have a colleague that is very much into the
topic and would like to contribute). However, I think that such an
approach would be most gainful only, if active communication and
collaboration between it and the GEF project could take place. That is
why active participation in the GEF project is of a high interest to me
in this regard as well. It would be fine if we could investigate this
further.
When folks show up like this for a modeling project, I generally try to
set the hook and reel them in. I think something needs to be done to
help make folks like this feel more welcome.
Regards,
Ed
Anthony Hunter wrote:
No offence Ian, the end goal here is that it sounds like I have
won you over and we can get this work going in GEF!
"There are schedules and release review and API freeze,
etc."
Only for code going into that release.
If we feel the code is not ready yet, no need to contribute it to that
release. So yes for work in May and June that could go into the release
after.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Ian Bull
---2010/02/04 06:19:33 PM---Sorry, I didn't mean any offense by
anything I said. I should have probably used the word stable project
for GEF. All I meant
Sorry, I didn't mean any offense by anything I said.
I should have probably used the word stable project for GEF. All I
meant was that it's at the bottom of a very large stack and any changes
must consider it's placement in this stack. If the proposed work can
be done without breaking any clients, great! But we won't know this
until we try.
I view some of this work in the same way that e4 fits
with the platform. Some stuff will be successful, some won't. Some
stuff can be back ported, some can't.
Regarding the mentoring of new committers, I was
following up on Wayne's comment that the barrier to entry is lower. If
someone breaks the build, or API, or is still learning the rules
regarding third party libraries, this is much easier to deal with in an
incubator rather than a project on the release train, No?
Finally, regarding the innovation, I don't feel GEF is
hard to work with.. anymore than the platform is hard to work with.
There are schedules and release review and API freeze, etc... These
are all very valuable in an "stable" project, but don't make sense in
the beginning.
If we can do this work in GEF, and we can separate
this work from the release train, and folks doing this work are free to
committ code during May and June (That's prime time for SoC work and
it's also RC time for us), then let's do that. If those things are
hard to manage in an existing / stable project, then let's do the work
in an incubator.
The key for me is not where the work is being done. We
have people who want to get involved, let's see what we can do to bring
them on board.
cheers,
ian
On Thu, Feb 4, 2010 at 2:57 PM, Anthony Hunter <anthonyh@xxxxxxxxxx> wrote:
Hi Ian, more of my personal
comments:
1. GEF is clearly a mature project in maintenance mode. [...]
Incorrect. GEF is not in maintenance mode. GEF is a stable project that
has fewer major features year over year because the community has not
contributed them. GEF has been consistently keeping up with Eclipse
releases and new OS platforms every year as part of every Eclipse
simultaneous release. When the community has contributed larger
features, GEF has accommodated them (Zest is perfect example of that).
GEF has been adding small fixes to Helios as dependent teams have asked
for them. We have even been asked for API changes and we have gladly
incorporated them. A project in maintenance mode would be adverse to
all change. This is not the case with GEF.
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.
Does this make sense? What
is the difference between mentoring a committer on an incubating
project or a released project?
3. [...] Forcing new ideas to follow API freeze rules (for example)
will only stiffle innovation.
If you feel this strongly that working within the GEF project is going
to stiffle innovation?
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Ian Bull
---2010/02/04 05:11:36 PM---Actually, while I think making this part of
GEF proper could work, the more I think about it the more an incubator
makes sense.
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@xxxxxxxxx>
wrote:
On Wed, Feb 3, 2010 at 10:23 AM, Wayne Beaton
<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@xxxxxxxxxxxxxxxxx <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@xxxxxxxxx
<mailto:cdtdoug@xxxxxxxxx>>
wrote: > > I am on the record a...
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx <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
--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org
I'm going to EclipseCon!
http://www.eclipsecon.org
_______________________________________________
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
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
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
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
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
|