Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] Koneki 1.2.0 Release Review
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



On Thu, May 22, 2014 at 5:14 PM, Simon Bernard <sbernard@xxxxxxxxxxxxxxxxxx> wrote:
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 ?

Le 21/05/2014 19:58, Aleksandar Kurtakov a écrit :

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

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



--
Andrey Platov | Xored Software Inc, President | http://www.xored.com | Eclipse DLTK Project Lead |http://www.eclipse.org/dltk | O: +7 383 363 1033 | M: +7 913 371 371 2 | E:andrey.platov@xxxxxxxxx | S: andreyplatov

Back to the top