Re: [Embedlets-dev] Re: CVS Code tree

[Brill P. <bri...@ro...>]

> > See my and Bill's post on the CVS repository. We cannot do anything with
a zip
> > file, without risking overwriting our work.
>
> Sure you can...it's totally self contained so you can review it and
provided
> feedback and discussion, which is what I think is needed before we start
> hammering out reams of new code/stuff.
>
> Not gonna post the code base in CVS (since I'm one version ahead) until
the
> source code formatting (Jalopy) stuff is in place (coming soon) and I
start
> to see some feedback from the group on the current stuff (up to you guys).

Just tag the versions, so they can be reffered to. Thats what the tagging,
and branching are for.

> Brill chimes in with a similar comment:
>
> > Would you mind posting the source to CVS rather and the zip files (in a
> > proper build environment)?
>
> Soon as I start to see some feedback on the current stuff.  The core
> interfaces and design decisions need to be reviewed and agreed before we
go
> helter skelter building on top of them.

I think you'll start getting feedback when we start to actually try to
implement test cases... I have the same problem with Cork, where I don't get
much feedback, so I don't know if the system is working for anyone ;)

As soon as I can get a good tagged source tree I'll start creating test
cases built on top of Cork, with some device access... but I want to know
what changes (and how) before I start having to replace my source tree on
every update.

> I also need to get the Jalopy source formatting in place first, to ensure
> that all checked in code is in line with the code conventions.

be careful with Jalopy.. I integrated it into the cork build a little while
ago, but found it caused more problems with my source tree than it was
worth, so instead I have it set up so I can manually format a particular
source file when I'm working on it.
If your going to set up it, I suggest you only do it with an automated CVS
commit, and only just before the commit takes place (and only the files that
have changed!) otherwise you get Jalopy resetting all the files changed or
not, and CVS thinks they have changed.

Now... the problem with sourceforge is the darn SSH... I don't know if the
ant CVS task can talk to the SSH'ed CVS or not.

> Before we cast it in concrete (by building on top of the current
interfaces
> too much, which will make it much harder to change the underlying
contracts),
> let's make sure that they are as good as possible, 'cause to do anything
else
> will compromise our plan to make Embedlets a defacto and distruptive
standard
> that becomes widely adopted.

Ok, lets check it in, tag it, and we can branch it later if we need to.... I
also suggest a separate branch (or module) for my japl integration, as I
don't know yet just from looking what I will have to do.

> The bane of many Open Source projects is the tendency to hack too much
code
> too early, instead of doing documentation, design review and the like.
We've
> got enough code now (too much probably, since I'm obviously not immune to
the
> "let's sling more code" syndrome either ;-) ), and it's time to step back
and
> ensure that we are going down the optimal path.

heh... Yah, the age old problem... I find it easier to do brief
documentation, get something working, and go back and document, then do the
next chunk... the long and short is that no matter how much you pre-design
something, you can never actually know its right until you get down to brass
tacks, and make it work.

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com