(I failed to post this to the mailing list the first time, retrying
using my EMO superpowers).
If code is being moved from one project to another, we'll need to do
a restructuring review. For this, we'll need an IP Log review and a
paragraph describing what you want to do (I'll create the review
record based on this paragraph).
When we move the code, we'll keep the commits intact, and credit for
the contributions will move to the destination project's IP Log. If
the commits are copied, the credit will exist in both IP Logs. If we
squash the history (not recommended), we'll lose any record of the
contributors (unless we include them as "Also-by" entries in the
squashed commit).
I'm in favour of using a separate Git repository if that makes
things easier for all involved.
I hope that this makes sense.
Wayne
On 06/03/15 03:35 PM, Oberhuber, Martin
wrote:
Hi
Greg, Doug, Wayne –
On
our side, we are ready for bringing the refactored TCF
Terminals View code from TCF into TM, as discussed
previously.
Before
we “Just commit the code” as you had proposed, I would like
to check again with Wayne whether a Restructuring Review
would be adviseable, for two reasons:
1.
Checking
the TCF IP Log, there have been contributions at least from
Max Weninger and Markus Schorn to the TCF Terminals. Both
work for Wind River (Member Agreement) but are not
committers: Do such IP Log Entries need to get moved to the
new project ? How ? Would the GIT history do that
automatically ?
https://www.eclipse.org/projects/ip_log.php?projectid=tools.cdt.tcf
2.
We
need to also move the Bugzilla Backlog for Terminals, so
looks like some help from Webmaster will be needed.
I
would appreciate if the three of you might get a chance
hooking up on this subject at EclipseCon and coming up with
advice.
That
reminds me, regarding the next steps for the proposed “TM
4.0” GIT repository / component:
-
Bringing
o.e.remote to TM had been discussed. Is this going to happen
? When ?
-
Creating
a separate git repo to hold “core components” independent of
RSE in TM had been discussed. Is this going to happen ? When
?
Having
a small, fresh git repo as target for our restructured code
would probably make some things simpler.
Comments
? Thoughts ?
Thanks,
Martin
--
Martin Oberhuber,
SMTS / Product Owner – Development Tools,
Wind
River
direct
+43.662.457915.85 fax +43.662.457915.6
+1.
It’s more an issue when you want to move committers from
one project to another. Since you’re committers on both,
just fire it over.
Having
just cleaned up my internal serial port/terminal
implementation to get back to the old Terminal View, I got
an appreciation of how simple the old view is to extend
and how the TCF Terminal integration was more than doubled
the size of the code. If we’re going to go with that as
our one terminal implementation, I’d like to see how we
can simplify that.
I
also want to see a tighter integration with o.e.remote.
All the terminal types can be implemented using remote
services with the bonus that they also support other UI
elements. With my user hat on, I’m not sure why creating a
Terminal and opening a File Browser over the same wire
would require different frameworks. I just want to click
on my Connection in the Connections view and Open Terminal
or Open File Browser and the right things happen. (And,
yes, I’ll be adding a file browser with full drag and drop
to the o.e.remote UI probably in the Mars.1 timeframe).
Is
a move review even necessary? I think this is only for
when whole projects move. In this case, I think you
could just create a Gerrit patch and submit it to the
TM repo.
Remaining
issues have been fixed, and the refactored
terminals view is now available from our Marketplace entry
[1] as
well as directly from our p2 repository:
In
order to look at the source, you can simply
File > Import > Team > Project set
from this URL:
to
get all the necessary repos in one step (TM,
o.e.remote, TCF) with projects categorized
into Working Sets.
We
now need to decide on the next steps to
ensure that we can align on this as the
common Terminals view for Eclipse.
If
a Move Review / Restructuring Review is
desired to move over the sources into TM,
we’d appreciate guidance from Greg and Doug.
The
alternative would be just updating the EPP
packages to use the new terminals view
instead of the now deprecated legacy one.
Comments
or thoughts are most welcome at this point !
Martin Oberhuber,
SMTS / Product Owner – Development Tools, Wind
River
direct
+43.662.457915.85 fax +43.662.457915.6
Please
note that the proposed dependency reduction
for the “Terminals” view implementation has
been completed. If you install the terminals
feature from our nightly build repository
[1], you want see any other o.e.tcf
feature/plug-in, nor will you get GSON. The
only external dependency the “Terminals”
view have is to org.eclipse.cdt.core.native
to support the local terminal functionality.
The marketplace contribution will be updated
soon.
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
--
Wayne Beaton on behalf of the Eclipse Management Organization
@waynebeaton
The Eclipse Foundation
|
