[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[List Home]
|
[eclipse-incubator-e4-dev] E4 Repository Setup
|
- From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Mon, 6 Oct 2008 12:50:44 +0200
- Delivered-to: eclipse-incubator-e4-dev@eclipse.org
- Thread-index: AckkmxgCQLe+KVioRCee/FqeOf/l6wDA9CEQ
- Thread-topic: E4 Repository Setup
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.
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
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
page.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
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