[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] git migration for ECF
- From: Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
- Date: Wed, 28 Jul 2010 21:53:39 +0200
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6
On 07/28/2010 07:46 PM, Scott Lewis wrote:
> 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).
New adopters probably have a hard time finding their way through the
code base. If you don't know what server-side/, providers/ or
compendium/ stands for, you're lost. We might need something like a map
that takes you from the wiki to the code.
> 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
> 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).
Sounds to me as if we need to ask the question how new contributors tend
to approach the code base. Currently you just get a full copy of the
repo and then try to pick the pieces you are interested in. That's why I
like 2. better where one who is usually interested in a certain part of
ECF, gets something like a "starter pack" (probably not the best
With the extra benefit that smaller repos keep the history clean from
clutter that would originate from a different area of the project.
For extra comfort we might offer a superproject which aggregates all
"starter packs". Alternatively .psf files will do (do they understand
git repos yet?).