Re: ecos-opt

[Jonathan Larmour <jifl@eCosCentric.com>]

Andrew Lunn wrote:
>>As (ex-)Red Hat folks will remember, it was decided way way back to split 
>>off the network stack and SNMP directories into a separate "ecos-opt" 
>>hierarchy in the public CVS tree. And so it has remained to this day.
> 
> 
> How does fit in, if it does, with the idea of going towards lots of
> separate packages. This is something you eCosCentric guys keep
> mentioning, but have not really said much in detail in out in the
> open.

It's always been a goal. Although we've mentioned "2.1" for this, "2.1" 
has been a placeholder for "a future version". We haven't really thought 
much about what a real 2.1 should have - and in particular whether it will 
have the separate packages.

Just so everyone knows what the goal of the packages is, the idea is that 
users don't download a monolithic release, but instead a small set of 
infrastructure host tools, in particular a greatly enhanced eCos 
Administration Tool. When a user runs that, they then get the chance of 
downloading packages from the master site (or mirrors), but can choose 
which packages they want, so they only download what they need. So someone 
needing only one target hasn't downloaded a zillion other HALs. They'll be 
able to confirm they are happy with the licensing too.

The other advantage is we can finally take advantage of versioning, so 
that you can have multiple versions in a repository at one time. You can 
download different versions using the admin tool (perhaps a stable version 
versus a beta version) and install them into your local repository.

One very good benefit is that it makes it much easier to make sweeping 
changes to packages because you would then be able to specify in CDL that 
a package "requires" not just a particular package, but a particular 
package version. So, say we needed to make a backward-incompatible change 
to the ARM HAL, perhaps an entire rewrite; we don't need to break every 
target and fix it... instead we just bump up the major version number; 
every HAL package that has a dependency on it would have specified the 
version number it was written for (a major version bump would indicate a 
version incompatible change of course) and put that in its CDL. Of course 
we could still release new versions of a "version 2 series" ARM HAL, as 
well as a "version 3" - development doesn't have to stop.

This has consequences of course, like ecos.db will be generated from 
package information by the admin tool; and documentation must come from 
each package... in fact this gets more fun when you consider you need the 
appropriate documentation for the package _version_ as well.

Obviously with the proper infrastructure in place to do this, we make it 
easier for third parties to seamlessly distribute their own packages. 
Possibly even binary only packages. Although we won't distribute them from 
our master site (probably), it's always been intended to permit this, and 
is indeed one of the reasons for the GPL exception.

> It seems to me these things are going in opposite directions. Hence i
> think im missing some information....

It's an orthogonal issue. The CVS repo should be straightened out because 
it needs to be. But even with a package based distribution we still need a 
CVS repository... it's only officially released packages that would be 
distributed that way; development would still happen in CVS as at present. 
And just because someone made a change in CVS wouldn't (necessarily) mean 
a new package is made available. Each package would get developed at its 
own rate, and would have their own maintainer who decides that.

Hope this helps explain things a bit anyway!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine