Re: [Simulavr-devel] Undo the fork ...

[Onno Kortmann]

Hi,

I'll try to answer several issues in this post here. Unfortunately, this 
is mostly about code management issues, so Eric, I'll prove you exactly 
right in this post :-)

> Just leave the historic simulavr directory as is then, so you don't
> have to take care about it (and its history) in the new rep.
>   
Ok, lets do it that way!

If there is no problem in keeping CVS and git in parallel on savannah, 
lets have CVS with the old code and the new code remove and the git with 
the C++ version only. To avoid confusion, Thomas and I will make sure 
that the old-cvs stuff will not be pushed into savannah git to avoid 
confusion for people checking the code out.
> > One question for that step is, what version should I set, in the
> > moment we have set in our fork "0.10rc1", but I'm not fixed on
> > that. Proposals welcome!
> >     
>
> As the legacy simulavr had a version number 0.1.xx, I'd suggest to
> start with something substantial higher than that, at least 0.5.  That
> way, automatic version checks will recognize it as something more
> recent than 0.1.xx.
>
> But then, why not simply start with a 1.0?  Klaus' last simulavrxx
> releases he did were already labelled 0.8.x, so it would seem logical
> to have something more.  I'd encourage you to finally start with
> version 1. ;-)
>   
Ok, to get ahead, I would then strongly propose (which means: Say NONONO 
or I or Thomas _WILL_ do it!) the following: We use the code that makes 
up _CVS_ HEAD (but in git of course) and call it the 'stable' branch and 
give it 1.0rc0. Only important bug fixes will be put on top of that 
until everyone agrees for a release. This should make those people happy 
who want to avoid the API changes but does not hinder TomK & me at 
throwing things around a bit more.

The 'master' branch will be used for Thomas and my changes (will be 
moved as is from avrs) and will one day make up the next stable stuff. 
Yes, the changes are large, but as I promised *I will show you how to 
get to any of the old code* if you want to.

Regarding 'incomplete extra features', such as my still incomplete 
factory code (to generate devices from the .xml files, due to Thomas 
changes, it suffered some bitrot lately), the slightly unmaintained TCL 
interface and all bits of cruft that are still in the current code base:

I would propose here that we simply keep such things in the repository 
until there is 100% consensus that they have to be removed. But at the 
same time, everyone that still wants to use such a half-maintainted 
feature has to make sure that it does not interfere with the build 
process of the most recent development version (that one in master). 
This should hopefully address Petr's objection (which I can clearly see, 
btw).
It should also be as loosely coupled to the rest of the build as 
possible. For my factory, this means some changes in src/Makefile.am, 
configure.ac and removal of the src/fab directory to completely remove 
it. It did not look into it too much, but suspect it to be about the 
same for the TCL interface.
And, the ones who want to use it/develop it whatever get the 
responsibility to keep up with the devel branch and not the other way 
around if at all possible. Meaning that _I_ am responsible to get my 
xml-fab working again or that Joel and anyone else that uses TCL needs 
to take care about reflecting any API changes into TCL.
This should also give an incentive to keep the set of interfaces 
exported to python/TCL as small as possible.


Regarding the web interface, well, I think that Thomas is much more 
knowledgeable about it and if possible, I'll stay away from the set up 
of that :-)

Best regards,

Onno