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

[Patrick Doyle <wpdster at gmail dot com>]

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...

I think that it might make sense to package the different processors
as submodules.  At least, I thought that might make sense back in the
day when I ported eCos to run on the OMAP.  I did the port; published
it on the mailing list; Jonathan reviewed it; I changed jobs; updated
the port; ported it again to another OMAP variant as well as several
different boards custom designed at the new job; and never saw my
original port make it to the official repository.

I'm not complaining... there were only 2 or possible 3 other people in
the world who were slightly interested in the port, and I pointed them
to the patches on the mailing list and helped them out as best as I
could.  Besides, there was no reasonable way for the eCos maintainers
to test or integrate my ports into the mainline tree.

But I recall thinking at the time, "Gee, wouldn't it be nice if I
could just publish this package somewhere and let others use it."  If
I were to do this again today, I would probably place my ports on
GitHUB and just make an announcement on the mailing list that the
ports were available to anybody who wanted to use them.  Some of
Jonathan's criticisms with my original port had to do with concerns
regarding code that had, ahem, been too inspired by Linux.  For quite
valid reasons, he couldn't let that code into the official repository.
 If I had published it on my own (along with the disclaimers that
such-and-such modules were, ahem, inspired by similar code in the
Linux kernel), then the official eCos repository would not be tainted
by pure GPL code.

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.

--wpd

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