Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Draw2d/GEF 4.0

Yes, I am fine with that. Indeed it's exactly what I had in mind.

Cheers
Alexander

Am 06.04.2011 um 19:44 schrieb Ian Bull:

I agree with Chris that an incubator will help us get more people involved, but if this is unlikely to happen (or until this happens) doing the work in a 'branch' is fine.  The key here it that the work can begin (and proceed) without any concrete end-game plan.   

Now I say 'branch' because technically I think we should mirror a stable state to git and use git for the development.  Fabian already has some experience setting up a build from git using tycho, which should also help here.

We should also ensure that our messaging is clear: this is experimental work without any API (yet). If this work evolves, then we can start to discuss compatibility layers, etc...

Alexander, do you think that will work?  Anthony, are you happy with that plan?  

I'd be happy to work with Alexander to create the git repos, and if Fabian has a few minutes maybe he can help us with the build infrastructure?

Cheers,
Ian 

On Wed, Apr 6, 2011 at 10:27 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
FWIW, if you switch your project repo to Git, we automatically mirror to GitHub. Zest is already there [1].

Wayne

[1] https://github.com/eclipse/zest


On 04/06/2011 03:57 AM, Alexander Nyßen wrote:
While I do not want to anticipate any decision about whether there should be an incubator or not, I think it would be a good to take a snapshot of GEF/Draw2d after Indigo release and put it in a Git-repo (maybe next to Zest 2.0), so we do not accidentally mix things up. I think that would also make it easier for the community to consume. The question of having an incubator or not depends much on how we intend to organize the planning/working/releasing of the 4.0 stuff. If we organize it as an incubator "under" GEF (as e.g. done with the RAP incubator) then that maybe not be such a bad idea, because it would allow to do things quite independently, even if the same "staff" is involved.

Cheers 
Alexander
 
Am 05.04.2011 um 20:28 schrieb Anthony Hunter:

Hi Ian,

Apologies up front, again, it is not my intent to stifle innovation or stop anyone, committer or otherwise, from trying and experimenting with new things.

The facts are that we have one committer: Alexander and no confirmed others. Creating an incubator and announcement to the tools PMC for GEF 4.0 / Draw2d 4.0 is premature.

Create a 4_0_innovation branch in the existing CVS repository and you are done. No discussion required, just do it.

Cheers...
Anthony




From:         Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To:         GEF development <gef-dev@xxxxxxxxxxx>, Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date:         04/05/2011 01:49 PM
Subject:         Re: [gef-dev] Draw2d/GEF 4.0
Sent by:         gef-dev-bounces@xxxxxxxxxxx




On Tue, Apr 5, 2011 at 10:27 AM, Anthony Hunter < anthonyh@xxxxxxxxxx > wrote:
Hi Team,

I really wanted to send a more detailed response, but before we start anything, we need to know in detail, hopefully already tracked by Bugzilla:

1) All the functional changes being requested that require a GEF 4.0 / Draw2d 4.0.
2) How much of GEF / Draw2d would be expected to change.
3) How the backwards compatibility layer would work.

With regards to (3), again, I wanted to make a complete response, but the expectation is and will be that all existing plugins using 3.x API will be provided a compatibility later to work with GEF 4.0 / Draw2d 4.0. This is the same level of compatibility delivered with the Eclipse Platform for both their 3.0.0 and 4.0.0 releases, I expect no less from GEF / Draw2d.

So this is the Chicken-and-egg problem that continues to plague us.  We can't start anything until we know 'in detail' how it will work. And we likely won't know much in detail until we start.

These are arguably fine criteria for 'shipping' or 'declaring API' -- I say arguably because I think we could argue against these too -- but is it true that these criteria must be met before anybody begins working?

This is exactly my reasoning for an incubator.  We could set these out as 'must dos' before the incubator is graduated, but let Alexander (and others) experiment in the meantime.  David mentioned doing this in a branch, and I'm fine with that too -- although with the foundation's transition to git I think we should likely fork the code and use git instead.

All I'm looking for is a tool to let Alexander (and others) experiment with different ideas within the legal (and technical) boundaries of eclipse.org .  The messaging I would like to convey to our users is: This is experimental work, and even if it does come to fruition, it likely won't happen for some time.  Moreover, we are unlikely to stop shipping the 3.x version of GEF / Draw2d even after the 4.x stuff is generally available.

Maybe this sort of experimental development is not easily supported by the Eclipse Development Process and the git-hub mirrors are the recommended approach.

Cheers,
Ian
 

Cheers...
Anthony




From:         Ian Bull < irbull@xxxxxxxxxxxxxxxxx >
To:         GEF development < gef-dev@xxxxxxxxxxx >,
Cc:         Tools PMC mailing list < tools-pmc@xxxxxxxxxxx >
Date:         04/05/2011 12:20 PM
Subject:         Re: [gef-dev] Draw2d/GEF 4.0
Sent by:         gef-dev-bounces@xxxxxxxxxxx





2011/3/22 Alexander Nyßen < alexander.nyssen@xxxxxxxxx >
Hi all,

I had tried to start a discussion on whether to have a new major version of Draw2d and GEF in 2012 here recently. As there has not been much response yet, let me clarify what I was referring to in detail, because that could probably have been misunderstood.

Sorry for not responding earlier.  Don't take that as a sign that I think this is a bad idea. In fact, I think what you are proposing is exactly what we need in GEF!

I haven't looked at the specific API problems you've mentioned below, but an API that doesn't allow GEF to evolve to meet the needs of the current committers (and presumably a portion of the user community) is a problem. Especially if SWT has released new API, some of which we cannot consume with our current design.

While I would thus like to have the chance of adjusting our current API, I see two important arguments that cannot be neglected:

1) we need to provide long-term support for our clients. This implies that - as GEF has been API-stable for quite some time now - we cannot simply come up with a 4.0 revision in 2012 without having announced it in advance and having given our long-term clients the chance to transition to it.

2) we most likely cannot achieve to incorporate all changes in a 6-9 month timeframe, so introducing a 4.0 version as a replacement for 3.7 in 2012 would be no good option from this viewpoint either. Being a replacement, we would have to fix its API again and would - to incorporate all changes - probably have to come up with additional major releases shortly afterwards.


Right, I don't think it makes sense to do all the work in a single 'release'.  

Personally, I would follow the same pattern as e4 / Eclipse 4.x. Start the work in an incubator and see how it unfolds.  By performing the work in an incubator we are not binding ourselves to any API, we can take advantage of parallel IP, we could break/change some of the existing development methods (release schedules, scm systems, etc...). If the work didn't evolve to a usable state, then we can simply archive it; and if it did reach a level of maturity that we are comfortable supporting, then we could role it into GEF proper.

As I mentioned, this model has worked well for e4/Eclipse 4.x. We've also used this same model in p2.  

Unfortunately, we proposed an incubator project [1] last year and it was determined that there is no clear advantage [2,3]. So I'm raising this with the PMC again with a clear question: "We have some existing committers, and possibly new ones (I don't know) who are interested in experimenting with a new GEF API, what is the best way to proceed?"

[1]  http://wiki.eclipse.org/Gef/Incubator/Proposal
[2]  http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01184.html
[3]  http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01187.html

Should we simply fork the bundles into a new project and let the committers work there?  If we do this in GEF proper what does this portray to our user community (are we saying the work is 'release quality')?

cheers,
ian
 

Cheers
Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743

http://www.itemis.de
alexander.nyssen@xxxxxxxxx

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource _______________________________________________

gef-dev mailing list

gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev


_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource _______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743


itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/gef-dev

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743


itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


Back to the top