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
|
