On our side, we don't want to take the lead on DLTK project.
The project is dying, this confirms we must remove the dependency
one time or another. Forking could allow us to do that slowly with a
lot of flexibility. This allow us to remove generic code if needed.
It seems better than taking time to keep DLTK alive artificially.
Le 23/05/2014 19:48, Eric Rizzo a
écrit :
I'm in favor of the proposal to transition some Koneki commiter(s)
to be committer(s) on DLTK and (eventually) assume the DLTK lead
role.The question is, does anyone on the Koneki team have the
inclination to do so?
Eric
I believe I shall join the discussion as a formal
project lead on the DLTK project. Definitely all the
resources involved into DLTK in the past no longer
connected with the project. Some (mostly Alex Panchenko alex.panchenko@xxxxxxxxx)
participating on his spare time, which I guess is very
much limited. There are no efforts, which may back DLTK,
probably besides Zend/Eclipse PDT and Koneki. So it’s only
initiative of some individuals like Alex to keep project
in shape.
Under given circumstances, the project is dying slowly
and there are definitely some steps required to protect
projects relying on DLTK and/or shutdown DLTK gracefully.
It’s true DLTK is not as flexible as good LTK layer
need to be, BTW during DLTK development we had another
definition for DLTK, which is Dirty LTK or Draft LTK. The
main goal for DLTK was to build full-featured IDEs fast,
and I’m pretty sure DLTK played well in this area allowing
many projects over the world to break entry-level barrier
and come up to an IDE for their technology.
Current situation in the ecosystem is much better, at
least because of success of Xtext, but say in 2008 it was
extremely hard and costly for most to develop an IDE on
top of Platform, and I did not see a lot of related
success stories. A good LTK layer ideas were floating
around for years, but without any significant results.
As for forking DLTK VJET is not a good case to refer
to: these guys forked DLTK many years ago, while it was
actively developed and never contacted with DLTK
committers, so we never hear about the reasons behind such
a fork.
Definitely many projects were depending on DLTK, but it
looks like most of them are no longer actively developed.
So DLTK freeze down very likely would not affect them
negatively. On the other hand we do not know the number of
active ones, so the best resolution as it seems to me may
be following:
- Koneki folks to take over DLTK leadership and evolve
it in the same way as they plan to evolve fork
- If there are any active user who step in contrary to
Koneki vision, restart similar discussion and fork if
there are no consensus.
I guess the above would not add much overhead to
Koneki, releasing two projects, add more traction to DLTK
and explore actual DLTK usage. Please share your thoughts,
and comments from Eclipse PDT would be appreciated.
Thank you very much, and
Kind Regards,
Andrey
We will follow this
proposal.
For the DLTK committer proposition, I don't know, maybe, but
as I say :
- I'm not sure DLTK is the right way to factorize language
Tooling effort
- the project seems to be less and less active.
That's way we think about remove the dependency.
How many active project still use DLTK ?
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
----- Original Message -----
From: "Simon Bernard" <sbernard@xxxxxxxxxxxxxxxxxx>
To: "Technology PMC" <technology-pmc@xxxxxxxxxxx>
Sent: Wednesday, May 21, 2014 8:06:22 PM
Subject: Re: [technology-pmc] Koneki 1.2.0 Release Review
Removing dependency to DLTK is something we often talked about.
DLTK help us to start quickly, but now it seems to slow us down.
When we face a problem with DLTK (bug, improvement, lack of flexibility), we
currently:
- investigate the problem,
- report the bug,
- implement a workarround,
- try to provide a patch.
This is really costly, most of the time for not so much. Sometimes a
workaround is not possible and some other times we need to duplicate a lot
of classes.
The project is still alive but not really active. Only small patches are
integrated. We understand that DLTK team has no more time/ressource to
continue as much as they want[1]. We know about this kind of problem.
But for us maybe this would be better to fork DLTK internaly, this could
allow us to be more reactive and sometimes to simplify the code (By removing
generic part of code). It's just an idea, we continue to talk about that.
But we are not the first, vjet project has been forking dltk for a while.[2]
The ideal would be to have an Eclipse project to communalize efforts for IDE
or Language Tooling in Eclipse. Not a framework like DLTK, but a set of
bricks, something more like Platform Text or Platform Debug. I don't know if
this kind of project is still relevant?
There is still talk on Tools PMC to form an IDE project exactly for this purpose. An actual proposal is supposed to be in the works now (summer is coming so it might not happen ASAP).
Isn't DLTK team willing to grow some of you as committer to ease your collaboration?
Alexander Kurtakov
Red Hat Eclipse team
[1] https://dev.eclipse.org/mhonarc/lists/dltk-dev/msg02305.html
[2] http://git.eclipse.org/c/vjet/org.eclipse.vjet.all.git/tree/
Le 21/05/2014 18:18, Wayne Beaton a écrit :
Agreed. Which is why I need to hear more.
Wayne
On 05/21/2014 11:22 AM, Aleksandar Kurtakov wrote:
----- Original Message -----
From: "Wayne Beaton" <wayne@xxxxxxxxxxx> To: technology-pmc@xxxxxxxxxxx Sent:
Wednesday, May 21, 2014 6:19:40 PM
Subject: Re: [technology-pmc] Koneki 1.2.0 Release Review
I'd like to take it a little further than that, Chris...
Please add more commentary regarding the DLTK dependency and why you're
thinking about forking.
Wouldn't it be better for everyone if the work spend on internal fork is
spend on dltk itself?
Are patches not accepted or there is some other problem?
Alexander Kurtakov
Red Hat Eclipse team
Wayne
On 05/21/2014 10:14 AM, Chris Aniszczyk wrote:
+1
Any more comments on "We think about removing the DLTK dependency, maybe we
can start with an internal fork."
The commit activity does look sparse but they do releases here and there:
https://projects.eclipse.org/projects/technology.dltk/documentation On Wed,
May 21, 2014 at 3:19 AM, Simon Bernard < sbernard@xxxxxxxxxxxxxxxxxx
wrote:
Hi,
We need the PCM approval for our next release.
The release review is planned for Wednesday May 28th.
Sorry for the delay, but the EMO say that the approval is needed
today. (Next time we will planned that earlier, sorry again)
Cheers,
Simon https://bugs.eclipse.org/bugs/show_bug.cgi?id=435319
https://projects.eclipse.org/projects/technology.koneki/releases/1.2.0
_______________________________________________
technology-pmc mailing list technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc --
Cheers,
Chris Aniszczyk http://aniszczyk.org +1 512 961 6719
_______________________________________________
technology-pmc mailing list technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc --
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
_______________________________________________
technology-pmc mailing list technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
Removing dependency to DLTK is something we often talked
about.
DLTK help us to start quickly, but now it seems to slow us
down.
When we face a problem with DLTK (bug, improvement, lack of
flexibility), we currently:
- investigate the problem,
- report the bug,
- implement a workarround,
- try to provide a patch.
This is really costly, most of the time for not so much.
Sometimes a workaround is not possible and some other times we
need to duplicate a lot of classes.
The project is still alive but not really active. Only small
patches are integrated. We understand that DLTK team has no
more time/ressource to continue as much as they want[1]. We
know about this kind of problem.
But for us maybe this would be better to fork DLTK internaly,
this could allow us to be more reactive and sometimes to
simplify the code (By removing generic part of code). It's
just an idea, we continue to talk about that. But we are not
the first, vjet project has been forking dltk for a while.[2]
The ideal would be to have an Eclipse project to communalize
efforts for IDE or Language Tooling in Eclipse. Not a
framework like DLTK, but a set of bricks, something more like
Platform Text or Platform Debug. I don't know if this kind of
project is still relevant?
[1] https://dev.eclipse.org/mhonarc/lists/dltk-dev/msg02305.html
[2] http://git.eclipse.org/c/vjet/org.eclipse.vjet.all.git/tree/
Le 21/05/2014 18:18, Wayne Beaton
a écrit :
Agreed. Which is why I need to hear more.
Wayne
On 05/21/2014 11:22 AM,
Aleksandar Kurtakov wrote:
|
