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

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:
----- 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
EclipseCon France 2014


Back to the top