Hi all,
I got an action item from the Oct-2 call to notify the mailing list
about how "cvs import" can be used to track Eclipse 3.5 advances
in the E4 Repository.
It's basically described here:
http://cvsbook.red-bean.com/cvsbook.html#Tracking%20Third-Party%20Source
s%20(Vendor%20Branches)
with the "cvs import" reference here:
http://cvsbook.red-bean.com/cvsbook.html#import
Now the question whether that's readily applicable to E4 is on a
different table. I think it depends a lot on how we envision the E4
work to move forward. To me, it currently looks like
*
We want to seed the E4 Repository with E3.5
*
We want to sync up at Milestones in order to adopt E3.5 bug
fixes
CVS Import can do this for us (with merging automatically where
possible), as long
as the structure doesn't deviate too much. In case we start moving
things around,
it won't work any more (merge conflicts on each and every merge). So I
propose
investing some thought NOW what we really want to achieve, before we
start something
and get trapped in Merge Hell at some point. There are other
alternatives possible.
I particularly think about Git, which I hear is quite good at Merging
individual branches.
It has a cvsserver emulation, and Eclipse integration (Egit), and works
very well on
Linux especially (the Windows port seems not yet as mature).
It looks like the various E4 technologies have slightly different
requirements, if I'm not mistaken:
*
SWT Browser Edition is developed in parallel to E3.5 and could
likely also live in the E3.5 Repository -- which seems favorable to me,
since having ONE Repository avoids merge issues right from the beginning
*
For Resources, we might want to have one or multiple independent
sandboxes just for Experiments, but will likely keep aligned with E3.5
enough to "release" things into the E3.5 Repository rather than keeping
a separate E4 Repository around. Anyways, for Resources it seems not to
be that much of a problem, since there's not so much change happening in
the E3.5 Repository so there won't be too much to merge.
*
For the UI Work, I just do not know what's appropriate.
My Proposal:
I would propose that we create Team Project Sets to pick up E3.5 stuff
wherever
possible, and keep the E4 specific Repositories as small as possible, in
order to
avoid merge issues. Create a Wiki Page ("Where to get the Source") to
document
where the stuff is.
For now, it seems more important to have a technically sound Repository
setup,
rather than one single Repository point of access for consumers. I'd
propose
deferring Repository Changes wherever possible.
But I'd think that only the various component people can know what's
best
for their stuff.
Those groups who already have some sources should start a "E4 Where to
get
the Sources" Wiki page based on the current
http://wiki.eclipse.org/E4/Running_the_demos
<http://wiki.eclipse.org/E4/Running_the_demos>
page.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Boris
Bokowski
Sent: Thursday, October 02, 2008 4:28 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] today's call
There are two topics for today that I know about. Feel free to
bring up more.
Topic 1: Project provisioning - see
http://www.eclipse.org/projects/project_provisioning_request.php
<http://www.eclipse.org/projects/project_provisioning_request.php>
We need to make decisions on the following:
* Component structure
* Initial committers: Website update privileges
(all?), Download server privileges (need to pick one or two)
* mailing list: move to e4-dev?
* Bugzilla: I am assuming we want a new "Product"
called e4, but which components should we create? Suggestion: Core, UI,
Resources
Topic 2: Pervasive themes - Martin sent an email to the list but
we haven't discussed. Here is an excerpt from Martin's email:
I'm wondering what happened to the pervasive architectural
themes
that were identified at the summit:
* Reducing Bloat
* Too Many Listeners
* Becoming More Asynchronous
* Eclipse Application Model
A lot of people signed up as being interested at the Summit, but
who's
actually going to work on these items? And, given that these
items are
pervasive across all components, how are we going to communicate
about these things, discuss and share ideas?
Boris
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
