[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] git migration for ECF
- From: Wim Jongman <wim.jongman@xxxxxxxxx>
- Date: Thu, 29 Jul 2010 22:00:31 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; b=XgvOX2hEAI9yyjgr0X8XsnghIKjDrqlbhwEqTEkm9CvqnUOdIse0YfBEq2Kcg38y9x eTZ5coH8g91uWpWZDfBY/EEyrOSsddQo+pQGZTh5aE7SGXuFtOEUsbI/ag5lvLwkKYup nnXsNy22Zzfadya/PhtHXk8141AeOWN7j89cQ=
Marcus' ideas on the repo structure sound good to me. The compendium naming should be more a redirect than an official name IMHO.
As a new member I was quite happy with the cvs structure and I think this way it will be even more clear. I also like the starter pack analogy.
On Jul 28, 2010, at 21:53, Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:
> 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
> naming), e.g.:
> 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?).
> ecf-dev mailing list