[ECOS] Splitting the eCos repository

[ECOS] Splitting the eCos repository

[Øyvind Harboe]

How about splitting the eCos repository?

- It would help to market the support for multiple repositories. I've
seen a lot of messy maintainence due to the lack of this knowledge.
- It would reduce the size of the eCos repository that 90% use.

Something like:

- eCos core. Up to and including architecture HAL's
- eCos devboard. Contains all the HAL's for development boards.
- eCos highlevel/net. All high level(many files) stuff like net,
microwindows, etc. goes
- eCos legacy.

1 eCos repository is too little, 10 is too many. :-)


The user would then have to either use a development board HAL as-is
or create his own eCos repository, probably duplicating & modifying an
existing HAL.

-- 
Øyvind Harboe
http://www.zylin.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

[ECOS] Re: Splitting the eCos repository

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> How about splitting the eCos repository?
>
> - It would help to market the support for multiple repositories. I've
>   seen a lot of messy maintainence due to the lack of this knowledge.
> - It would reduce the size of the eCos repository that 90% use.
>
> Something like:
>
> - eCos core. Up to and including architecture HAL's
> - eCos devboard. Contains all the HAL's for development boards.
> - eCos highlevel/net. All high level(many files) stuff like net,
>   microwindows, etc. goes
> - eCos legacy.
>
> 1 eCos repository is too little, 10 is too many. :-)

That does sort of sound like a good idea.  Having hundreds of
megabytes of unused stuff under local source control can be
annoying when you want to check out a new copy or diff an old
one.

> The user would then have to either use a development board HAL
> as-is or create his own eCos repository, probably duplicating
> & modifying an existing HAL.

-- 
Grant Edwards                   grante             Yow!  I want you to
                                  at               MEMORIZE the collected
                               visi.com            poems of EDNA ST VINCENT
                                                   MILLAY... BACKWARDS!!

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

Re: [ECOS] Splitting the eCos repository

[Bart Veer]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    Oyvind> How about splitting the eCos repository?

    Oyvind> - It would help to market the support for multiple
    Oyvind> repositories. I've seen a lot of messy maintainence due to
    Oyvind> the lack of this knowledge.
    Oyvind> - It would reduce the size of the eCos repository that 90%
    Oyvind> use.

    Oyvind> Something like:

    Oyvind> - eCos core. Up to and including architecture HAL's
    Oyvind> - eCos devboard. Contains all the HAL's for development boards.
    Oyvind> - eCos highlevel/net. All high level(many files) stuff like net,
    Oyvind> microwindows, etc. goes
    Oyvind> - eCos legacy.

    Oyvind> 1 eCos repository is too little, 10 is too many. :-)

    Oyvind> The user would then have to either use a development board
    Oyvind> HAL as-is or create his own eCos repository, probably
    Oyvind> duplicating & modifying an existing HAL.

I don't think so - at least not for some time.

For most people having a single repository makes life simpler.
Installation is easier, you just need the one directory tree rather
than several. The ECOS_REPOSITORY environment variable is simpler,
with just one entry, so there is much less to worry about if that
variable gets corrupted somehow or if one of the directories gets
moved around for some reason. The single tree is what is documented,
not just in our documentation which we can change (given appropriate
effort) but also in other works like the Massa book. We do not have
problems with novice users complaining on ecos-discuss that they
cannot find e.g. microwindows because they have not installed or
checked out some optional repository. Sure, most eCos users will not
be interested in microwindows but why make life unnecessarily
complicated for the ones who are?

Yes, there are disadvantages. A single repository will contain lots of
stuff that any given developer won't need, wasting disk space. However
the average size of a hard disk is growing faster than the size of an
eCos repository so that problem is actually becoming less important
over time. Similarly bandwidth is becoming less of an issue. 

Support for multiple repositories is great for experienced users. I
have about 20 different repositories at the moment, a mixture of
branches and development trees, and my ECOS_REPOSITORY path has six
entries. However I see no reason for inflicting multiple repositories
on novice users. They have enough to learn as it is.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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

Re: [ECOS] Splitting the eCos repository

[Øyvind Harboe]

> I don't think so - at least not for some time.
>
> For most people having a single repository makes life simpler.
> Installation is easier, you just need the one directory tree rather
> than several.

It also makes life more complicated. E.g. how to manage changes to the
eCos repository.

There seems to be some belief that the average product can use eCos +
HAL's unmodified. I have seen plenty of evidence to the effect that
changes to eCos HAL & other modules will be required by non-trivial
products.


> The ECOS_REPOSITORY environment variable is simpler,
> with just one entry, so there is much less to worry about if that
> variable gets corrupted somehow or if one of the directories gets
> moved around for some reason. The single tree is what is documented,
> not just in our documentation which we can change (given appropriate
> effort) but also in other works like the Massa book. We do not have
> problems with novice users complaining on ecos-discuss that they
> cannot find e.g. microwindows because they have not installed or
> checked out some optional repository. Sure, most eCos users will not
> be interested in microwindows but why make life unnecessarily
> complicated for the ones who are?

I view the introduction of multiple eCos repositories as a necessary
level of complexity. See above.

> Yes, there are disadvantages. A single repository will contain lots of
> stuff that any given developer won't need, wasting disk space. However
> the average size of a hard disk is growing faster than the size of an
> eCos repository so that problem is actually becoming less important
> over time. Similarly bandwidth is becoming less of an issue.

I don't view harddisk space as an observable, i.e. there is no other
way that the user can tell that 10 or 100 mByte is used to store eCos
other than looking.

However, the *large* number of files becomes a performance problem.


Consider: how do I store a snapshot of eCos under source control?
Tricky. I keep a .zip of the entire eCos repository under CVS. Then I
unzip  & work on the eCos repository. Once I've made changes(or
updated to the latest eCos CVS), I zip up the entire dir and place it
under CVS. CVS is terribly inefficient with this sort of
thing(sloooow), should work better with subversion that has binary
diff capability(.zip should work better than e.g. tar.bz2 for binary
diff).


> Support for multiple repositories is great for experienced users. I
> have about 20 different repositories at the moment, a mixture of
> branches and development trees, and my ECOS_REPOSITORY path has six
> entries. However I see no reason for inflicting multiple repositories
> on novice users. They have enough to learn as it is.

Before any reasonably well organised(i.e. they use some source control
on their own stuff and care about eCos CVS HEAD versions/snapshots)
and non-trivial product is finished, I believe that they would have
wished that they had been introduced to multiple repositories.


-- 
Øyvind Harboe
http://www.zylin.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

Re: [ECOS] Splitting the eCos repository

[Andrew Lunn]

> Consider: how do I store a snapshot of eCos under source control?
> Tricky. I keep a .zip of the entire eCos repository under CVS. Then I
> unzip  & work on the eCos repository. Once I've made changes(or
> updated to the latest eCos CVS), I zip up the entire dir and place it
> under CVS. CVS is terribly inefficient with this sort of
> thing(sloooow), should work better with subversion that has binary
> diff capability(.zip should work better than e.g. tar.bz2 for binary
> diff).

What recommend for a product development is take an eCos snapshot,
test it, and then freeze it. You can store this as a zipfile
somewhere. Then start work on your port. Keep only the patch to the
snapshot in CVS. The patch will be small and plain ASCII. So CVS will
have no trouble with it. You can easily write some scripts to generate
the patch and to apply the patch.

> >Support for multiple repositories is great for experienced users. I
> >have about 20 different repositories at the moment, a mixture of
> >branches and development trees, and my ECOS_REPOSITORY path has six
> >entries. However I see no reason for inflicting multiple repositories
> >on novice users. They have enough to learn as it is.
> 
> Before any reasonably well organised(i.e. they use some source control
> on their own stuff and care about eCos CVS HEAD versions/snapshots)
> and non-trivial product is finished, I believe that they would have
> wished that they had been introduced to multiple repositories.

By which time they will no longer be a novice user, and can think
about doing it for there second project.....

      Andrew

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

Re: [ECOS] Splitting the eCos repository

[Øyvind Harboe]

> I'd say not before configtool supports it.
> But it would also make creating a public "experimental" repository possible
> (e.g. on sourceforge) for stuff which didn't make it yet into the main repository.

I'm starting to think that the configtool is doing non-trivial damage to eCos.

There is with eCos a certain necessary level of complexity that the
developer sidesteps when using this tool + it causes problems with the
limited amount of maintenance that this tool receives.

Just a thought....




-- 
Øyvind Harboe
http://www.zylin.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

RE: [ECOS] Splitting the eCos repository

[Doyle, Patrick]

> -----Original Message-----
> From: Øyvind Harboe [mailto:oyvind.harboe@zylin.com] 
> Sent: Friday, August 11, 2006 5:24 AM
> To: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] Splitting the eCos repository
> 
> 
> How about splitting the eCos repository?
> 
> - It would help to market the support for multiple repositories. I've
> seen a lot of messy maintainence due to the lack of this knowledge.
> - It would reduce the size of the eCos repository that 90% use.
> 
> Something like:
> 
> - eCos core. Up to and including architecture HAL's
> - eCos devboard. Contains all the HAL's for development boards.
> - eCos highlevel/net. All high level(many files) stuff like net,
> microwindows, etc. goes
> - eCos legacy.
> 
> 1 eCos repository is too little, 10 is too many. :-)

I like it...

As I said, we already do much the same here.  One of the concerns I've had
about the OMAP ports is to wonder what happens when they get committed to
the repository.  (That has been dwarfed by my primary concern of when are we
ever going to find the time to formalize them).  Minor tweaks and additions,
not to mention total rewrites, need to go through an official maintainer
(which, with suitable negotiations, could be me) to commit them to the CVS
repository.  OTOH, I (here I use the royal "I", meaning Paul or Tom) could
simply maintain an OMAP repository, which would be available as a tarball,
periodically updated, through the eCos web site.  Then the 99.999999% of
folks using eCos on platforms other than the OMAP wouldn't have to deal with
the (albeit minor) bandwidth and disk space taken up by the OMAP port.
Lather, rinse, and repeat that for each processor and platform and you've
got a very sleak core OS plus additions for different applications.

I especially like the fact that eCos was designed from the ground up to be
easily portable to different platforms and processors.  I have yet to try
porting Linux to a new platform, and I know that a lot of progress has been
made in the area of modularizing it to make such ports easier, but I still
cringe at the thought.  Whereas, with eCos, I almost look forward to it :-)

Oops, that was way too much of a digression.

Anyway, I like your idea.  I think the split makes sense in theory... I'm
sure there would be a lot of discussion in the community regarding which
packages belong where, but eCos's inherent architecture would make such
changes easy to implement.

Great idea!
--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