[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] git migration for ECF

Hi Markus,

I have pending changes and additions that have not yet been committed to the CVS repo...so I think it's a little early to be freezing the CVS repo access. If this is just for testing...how long will the testing period last?

When we do the final changeover, we'll need to give some advance warning (i.e. days) via this list.

Some additional comments inline below

Markus Alexander Kuppe wrote:
Hi,

for testing, I've imported the ECF CVS repo to git [0]. Please do
_not_!!! write to this repository. Your changes will definitely be lost.


Currently the repo is a 1:1 copy of the original CVS repo. But I would like to start a discuss if we want to:

a) purge old/outdated branches (e.g. everything that is not Release_*,
maint_*, master)?

This is probably ok...although there may be some branches created by other committers (for non-releng purposes) that they might want to maintain.


b) restructure the repo into smaller parts/repo:

0. Leave it as it is
- To coarse grained
- folders are artificial (e.g. what is compendium/)

The compendium module contains that ECF impl of OSGi remote services (which is part of OSGi compendium). I'm not married to this organization, but loosely speaking it is how Equinox also structures things (they separate standards parts impl so that it's clear what's from core spec, what's from compendium, etc).



- framework/ contains a lot of non framework bundles
+ less work

1. Create a repo for each top level folder in org.eclipse.ecf/
- see 0.

2. Group functionality/feature sets into separate/distinct repos (e.g. a
discovery, remoteservice, presence, filetransfer, telephony, collab...
- providers are used by different feature sets
+ best compromise between maintainability and flexibility
+ well adopted (ecf-nonepl, other projects)
+ best reflects the areas of work

3. One repo per bundle/feature and execisvely use submodules to structure
- git submodule not yet supported by egit
o creating a bundle/features means creating a new repo
+ best flexibility

Personally I'm leaning towards 2. as the best solution of both
directions. Although for my GSoC project I have taken the one bundle per
repo attempt (3.) and am quite happy with it. Basically the git
supermodule can be aligned with the corresponding Eclipse features. It
even targets a specific version (e.g. feature A references bundle B in
rev 1, while feature A references bundle B rev 2). However Eclipse
tooling is definitely not up to the task (yet). One has to use cmd line
clients.

Although I think that 2 makes some sense, it might result in a large number of separate modules...i.e. a very 'flat' structure...with many directories (i.e. one for each ECF api results in quite a few now). This can/could be seen by others (particularly those unfamiliar with the project) as a complex structure...and therefore less approachable/understandable.


I don't know what the 'optimal' organization is...I'm just pointing out the trade-offs...i.e. more granularity (many directories at top level) can/could mean more perceived complexity...and I would like to keep things as approachable/understandable/simple as possible...both for those that know/are familiar with the API structure (i.e. existing committers) as well as others (contributors, community members, consumers, others).

Scott