Re: [ECOS] Tracking eCos as a hg/git submodule

[Alex Schuilenburg <alexs@ecoscentric.com>]

Patrick Doyle wrote on 2009-10-14 14:39:
> On Wed, Oct 14, 2009 at 9:20 AM, Alex Schuilenburg
> <alexs@ecoscentric.com> wrote:
>   
>> Øyvind Harboe wrote on 2009-10-14 12:37:
>>
>> However, while external developers may want to use submodules and indeed
>> have eCos as a submodule as you suggest, I dont really see that much of
>> a need for them within the public eCos repo myself - unless you really
>> want to break down individual eCos packages into separate submodules but
>> IMHO that is just taking things too far.
>>     
> I have a very weak disagreement with that last point...
>
> [...]
> As I said, it's a weak disagreement, but I think that eCos' packaging
> system lends itself quite well to grafting in submodules from Git (or
> mercurial, with which I have no experience).  It could also streamline
> the core eCos distribution and remove the need to carry around code
> for ancient ports and processors.
>
> That's my next $.02 contribution to the discussion.
>   

At a processor level sure, that is what we already do at eCosCentric for
example, combined with the ECOS_REPOSITORY feature that Oyvind mentioned
in a later post.  It always catches me when trying to debug/modify code
though - which source file actually was used...

However, just to clarify, what I meant was at *every* package level. 
That is just plain overkill.

That said, what you mention above, still really would have no place in
eCos submodules.  The official distribution needs to be clean, assigned
and all the rest.  If you want to make downloads of e.g. arm only
versions of eCos so that people had less to download, that would be a
reason, but bandwidth is cheap and it would simply reduce a 20 s clone
down to maybe 10 s.

However, the real power (and danger) is that hg submodules will allow
you or anyone else to do is create your own repo with the offical repo
as a submodule, and also add your own port to the repo.  You could then
publish that repo to your customers etc.  I mention danger specifically
since, as per my previous emails to Oyvind et al (see
http://ecos.sourceware.org/ml/ecos-discuss/2009-10/msg00046.html and the
thread "Copyright Assignment") eCos has built up a reputation for its
code defensibility.  Having several "dirty" (containing GPL or
unassigned code) public repos about would be a bad thing, particularly
since they will trade off the goodwill of eCos and IMHO devalue it.  
Private repos, as Oyvind alludes to, will be fine because they are
shared with a closed group of companies or individuals who know the
source and the risk involved in using that code.  And it would allow you
to make your own private repo available to only the other interested
individuals as you suggest.  However, making it public means there is a
very great risk of the goodwill of eCos being diluted, and worse, a
greater risk of that "dirty" code finding its way back into the official
repository.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss