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:
