ecos-opt

ecos-opt

[Jonathan Larmour]

Now that 2.0 is out and for the moment we hope, people will be less 
reliant on CVS (or at least there won't be a much better time), I would 
like to do something a little drastic...

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.

However I've found I still get the odd problems because of this, in 
particular if you use "checkout" as a way to update your source tree, 
instead of "update" it barfs.

So I'd like to finally bring everything back into one tree. I believe it 
can be done fairly easily, by just moving the directories into place 
within the repository and then putting in symlinks directly in the CVS 
repository in the old places to make sure existing checkouts work.... but 
new checkouts would not get those as I would update the "modules" file 
appropriately. It would only really affect things for people using 
"checkout" to update their sources, but since that's already broken there 
can't be many of those :-).

Any objections or suggestions? If not, I'll choose a quiet period some 
time soon to do it.... as you can tell actually doing it is just a few 
trivial commands actually! But of course I'll need to test it.

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

Re: ecos-opt

[Gary Thomas]

On Wed, 2003-05-21 at 13:31, Jonathan Larmour wrote:
> Now that 2.0 is out and for the moment we hope, people will be less 
> reliant on CVS (or at least there won't be a much better time), I would 
> like to do something a little drastic...
> 
> 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.
> 
> However I've found I still get the odd problems because of this, in 
> particular if you use "checkout" as a way to update your source tree, 
> instead of "update" it barfs.
> 
> So I'd like to finally bring everything back into one tree. I believe it 
> can be done fairly easily, by just moving the directories into place 
> within the repository and then putting in symlinks directly in the CVS 
> repository in the old places to make sure existing checkouts work.... but 
> new checkouts would not get those as I would update the "modules" file 
> appropriately. It would only really affect things for people using 
> "checkout" to update their sources, but since that's already broken there 
> can't be many of those :-).
> 
> Any objections or suggestions? If not, I'll choose a quiet period some 
> time soon to do it.... as you can tell actually doing it is just a few 
> trivial commands actually! But of course I'll need to test it.

Sounds fine to me - I was never very fond of the split anyway.\

You should be able to test this with a local copy of the CVS tree.
That way, when you make the change all the ducks will be in a row.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: ecos-opt

[Andrew Lunn]

> 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 seems to me these things are going in opposite directions. Hence i
think im missing some information....

      Andrew

Re: ecos-opt

[Jonathan Larmour]

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