Thanks Greg. That’s good to hear.
I think the main objective is to give o.e.remote more visibility and I had hoped moving it to TM would help. But I’m not sure TM has any energy left and could actually be a
candidate for termination as the number of active committers is falling dangerously low.
I’m not totally convinced bringing it into CDT is going to make that much of a difference either. Much of this is driven by a dramatic fall off of contributions to a number
of Tools projects. This is really about growing projects in scope and reducing complexity in hopes of making it easier for contributors to join. But I’m wide open to other ideas of making these projects appealing again to keep them going.
As for namespace, I also think it’s important to keep then intact. Forcing consumers to change code would be a killer. We will move repos and things around so they fall under
CDT’s permission tree though.
From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx]
On Behalf Of Greg Watson
Sent: Wednesday, August 30, 2017 8:47 PM
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
Subject: Re: [tools-pmc] Move of Terminal and Remote TM to CDT
I'm still contributing occasionally to o.e.remote and PTP, and PDT just starting using PTP's synchronized projects, so there is still some interest. I'm not really sure how making o.e.remote part of CDT is going to make much difference,
but I'm willing to take Doug's word for it. I also think bringing TM terminal and o.e.remote together is a worthy goal. My only requirement is that the namespace be kept the same and the repo remains separate so downstream users don't have to change anything
other than the repo URL.
Thanks David. Comments in Doug>
But, will point out if CDT committers could "keep it alive" then why can't they simply become committers in TM and do the work there (and, I'm guessing, move (o.e.remote to TM).
Doug> I have become a committer on these components and I fear I am about to be the only active committer on these components. I need help and am looking
to the CDT community for that help. This move makes it easier in theory.
I think there are other consumers of 'remote' and 'terminal' (such as the JEE EPP package) so wouldn't you need to keep a separate build? Oh, just realized you would not have to for EPP packages,
as long as there is a "simultaneous release" :) but you might think through if there are any other consumers that might need it on a different schedule that CDT.
Doug> CDT releases every six months now. Given how few consumers have stepped up to contribute, they should be happy to have these components release
Plus, in Eclipse "main" releases, such as those participating in Simultaneous Release, is there still just one "remote" and one "terminal"? I thought some of the TM re-org/termination issues came up because someone was doing something similar? But, it is a
vague memory -- I have not researched the history.
Doug> Yes, we are down to one Terminal. Wind River has left Eclipse and we were lucky to consolidate the two we had before that happened.
Doug> There are two remotes. RSE still exists and that will be the only thing left in TM. Kaloyan Raev from Zend has been keeping it on life support.
We will need to monitor that situation. In the mean time, we will be keeping o.e.remote as an active component in CDT.
Good luck! (sounds complicated)
Doug> Thanks, it’s not really that complicated. Over the last few months, the number of people contributing to these projects has approached zero.
It’s a pretty sad situation and I’m doing my best to try and make these projects easier for new contributors to get involved with and project consolidation is one tool that I hope can help with that.
On 08/30/2017 04:17 PM, Doug Schaefer wrote:
There is a current request, https://bugs.eclipse.org/bugs/show_bug.cgi?id=500768,
which has the intention of bring the org.eclipse.remote target management system and the Terminal plug-ins together under a single project. The idea is to make Terminal the official terminal for o.e.remote connections, and make o.e.remote the standard (but
not only) connection technology for the Terminals.
My fear is that the originally proposed home in the TM project is about to collapse. As such, I’d like to bring them under the CDT umbrella. C/C++
developers these days deal mainly with remote systems, either embedded development boards or big iron servers. Target Management has always been a desired feature of the CDT (we even had a proposal at one time to build such a system until DSDP came along and
that’s a good story on its own). IMHO, it’s time to bring target management home and give it and CDT some much needed energy.
My proposal as listed on the bug is to bring the two git repos and all related artifacts for these components under the ownership and responsibility
of the CDT. We still need to reach agreement with the projects involved, but before I do that, I’d like to see if anyone on the Tools PMC objects.
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit