Re: [gef-dev] Draw2d/GEF 4.0

[Anthony Hunter <anthonyh@xxxxxxxxxx>]

Hi Alexander,

I am trying my best to be accommodating
and not hurt or slow any of the work you are doing, but I strongly feel
that sending out messages that we are doing a major version is very damaging.
Until we know exactly what is going into the new version, I do not feel
we are justified to call it a major version change or call it 4.0.

The clients I am associated with have
ten years invested in Eclipse and GEF based applications. They have consistently
communicated that backwards compatibility is critical and they do not want
their code broken. You have a huge selling job on the benefits of the new
version. We are talking thousands of developers to convince that a major
new version of GEF is a good idea. 

Until you have significant and measurable
content in the experimental branch, coming up with new name spaces and
two builds and two bugzillas versions is premature in my opinion.

That being said, I have grown tired
of arguing with you. Drive your proposal on the wiki and start progress
on the new features. Call it what you wish. Worst case we deliver the existing
HEAD to Juno as 3.8, so anything we do outside of the main branch is in
reality fine in the short term.

Cheers...
Anthony




From:      
 Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
To:      
 GEF development <gef-dev@xxxxxxxxxxx>,

Date:      
 05/03/2011 05:49 AM
Subject:    
   Re: [gef-dev]
Draw2d/GEF 4.0
Sent by:    
   gef-dev-bounces@xxxxxxxxxxx

---

Well, it seems we may regard this to be principally settled
by now (though, Anthony, I am still lacking an ACK to my last comment),
and so I would propose to raise a bug so we can keep track of everything
further within Bugzilla.

In the meantime two "technical" implications/questions
related to our commitments came to my mind and I would like to get some
opinions on them:

1) I came to the conclusion that the need for a 100% binary
compatibility layer (as requested in 4) implies that we should use a new
namespace for the provisional branch API, because otherwise we will face
name clashes in the end. I was thinking of introducing something like a
"org.eclipse.gef4" or "org.eclipse.g4" prefix for all
our plug-ins in the provisional branch. Other ideas?

2) I was wondering what the bug resolving policy should
be when we have the provisional branch in place. There are a couple of
bugzillas that could be resolved in the branch, but may probably not be
resolvable in the HEAD. Are we going to mark those bugzillas as being resolved
in version 4.0 or are we going to introduce new components we can assign
them to? Are we going to clone the bugs? Any best-practices here?

Cheers 
Alexander

Am 15.04.2011 um 13:49 schrieb Alexander Nyßen:

Hi Anthony,

agreed, except that I would not call it "GEF experimental"
 as this could indicate to our community we will use it as a mere
playground to try out things, and that's not my intention. What about "GEF
4 provisional"?

Cheers
Alexander


Am 15.04.2011 um 03:39 schrieb Anthony Hunter:

Hi Team, 

How about this instead: 

1) After the Indigo release has been completed, a GEF experimental branch
is created by forking the GEF 3.7 code-base into a Git repository (possibly
located next to Zest 2.0, so that all experimental GEF components can be
found in one place).  
2) The experimental branch created thereby will live parallel to the GEF
HEAD branch, considering all its API as provisional unless explicitly graduated.
It will not interfere with GEF HEAD, i.e. it will have its own build process
and separate wiki pages for documentation of the ongoing work (similar
to Zest 2.0). 
3) Committers working on the experimental branch will be responsible for
ensuring fixes made to GEF HEAD also get applied to the experimental branch.
4) Graduation of the experimental branch back into GEF HEAD will have to
imply that a proper compatibility layer is in place so all GEF 3.x clients
run in a 100% binary compatible method. It will furthermore have to be
acknowledged by all GEF committers. 
5) Work will start without an incubator project at first, granting commit
rights on the Git repository to all current GEF committers. The question
of introducing an incubator project (located under GEF) will be deferred
until a) community wants to actively get involved or b) Juno has been released
(whatever comes first). 


Cheers...
Anthony




From:        Ian
Bull <irbull@xxxxxxxxxxxxxxxxx>
To:        GEF
development <gef-dev@xxxxxxxxxxx>,
Date:        04/14/2011
07:11 PM 
Subject:        Re:
[gef-dev] Draw2d/GEF 4.0 
Sent by:        gef-dev-bounces@xxxxxxxxxxx

---

+1, I like this! 

I don't want to open the whole incubator debate again, but I would like
to point out bug 342641 which will make the creation of incubators even
easier.  As Alexander points out, this decision can be delayed until
we actually need one. 

Cheers, 
Ian 

2011/4/14 Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
I would like to come to a conclusion concerning this topic, so let me try
to sketch a compromise based on what has been discussed so far: 

1) After the Indigo release has been completed, a GEF 4.0 branch is created
by forking the GEF 3.7 code-base into a Git repository (possibly located
next to Zest 2.0, so that all provisional GEF components can be found in
one place).  
2) The 4.x branch created thereby will live parallel to the GEF 3.x HEAD,
considering all its API as provisional unless explicitly graduated. It
will not interfere with GEF 3.x, i.e. it will have its own build process
and separate wiki pages for documentation of the ongoing work (similar
to Zest 2.0). However, all bug fixes that are applicable to both branches
will of course also be applied to both. 
3) Graduation of the 4.x branch (to replace GEF 3.x) will have to imply
that a proper compatibility layer is in place so that GEF 3.x clients can
seamlessly transition to it. It will furthermore have to be acknowledged
by all GEF committers. 
4) Work will start without an incubator project at first, granting commit
rights on the Git repository to all current GEF committers. The question
of introducing an incubator project (located under GEF) will be deferred
until a) community wants to actively get involved or b) Juno has been released
(whatever comes first). 

Is that something that we all could live with? Anthony, could you agree
to this? 

Cheers  
Alexander 


Am 06.04.2011 um 22:05 schrieb Alexander Nyßen: 

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 

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


_______________________________________________
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 

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

--   
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

--  
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

--  
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