[PATCH 00/13] Replace mongoose with civetweb.

[Amar Takhar]

On 2016-05-02 09:57 +0200, Christian Mauderer wrote:
> 
> Just two thoughts on the tools. Both doesn't need instant answers.
> Please note that I don't intend to contradict the tools.
> 
> I just took a quick glance on the linked pages but from that it seems
> that both tools are quite git-centered. Not everything we might want to
> pack is available in a maintained git repository. Some projects might
> use other version control systems (hg, svn, ...) or just use plain
> .tar.gz files with releases. How would we handle these?

The tools I pointed are focused on the RCS we use at RTEMS which is Git.  
Upstream can be whatever is required.  Git has support for both svn and CVS 
naively which makes things easier.  for a tar.gz we simply unpack it in the 
vendor directory and add it while tracking any additions/removals.

We can choose to preserve any upstream commit logs if we want.  This can be 
useful for some projects in others it produces too much noise.


> If special tools are used: Are these tools only necessary if you want to
> change the sources or would you need them too to use the repository? In
> other words: Would every user have to install them or just someone who
> wants to supply patches to the repository?

They are only used for vendor imports.  If you have project 'abc' that is 
tracked locally then only when we import a new upstream 'abc' are the tools 
required.  Users will never need these only RTEMS developers.


> Like I already said in my other mail, it wasn't my intention to sabotage
> this work. I'm sorry if I gave that impression. I just didn't see
> another way how to move civetweb out of RTEMS and not loose the test
> without putting a lot of time into building a new structure.

No of course not it's fine. :)  I was trying to say there are greater concerns 
about the testsuite.  I'm working on a full, ground up rewrite of the entire 
test suite that will give us more indepth testing and tracking.  For this to 
work the entire testsuite needs to be in one place.  If it is a test that is not 
RTEMS centric then they should be upstreamed.  We will be running upstream 
testsuites for tools and libraries we use as well.  It's a matter of the 
appropriate place to put them.


> I'm not sure, if I understand you correctly here: On the one hand, we
> should keep all tests together. On the other hand we should keep the
> tests together with the tested code. And we are currently discussing how
> to split up some of the code. So wouldn't we have to split up the tests too?

The tested code in this case is 'RTEMS'.  If this is a test that requires RTEMS 
to run then it needs to be with RTEMS.  If it is a test that is for the software 
package only it must be upstreamed.  If we run into the situation where upstream 
tests do not exist or they do not accept ours then they should go in with the 
RTEMS testsuite.  The vast majority of tests are for RTEMS if we have a few that 
are not strictly related it is not a big deal.  The system will keep tabs on 
them just the same.


> I would expect that the current discussion leads to the following structure:
> - one RTEMS core repository containing the tests that test the RTEMS
> core system
> - one RTEMS vendor repository containing vendor libs and apps like
> civetweb and tests for these apps
> 
> Did I interpret that wrong?

This is exactly what I am suggesting we do.  The testsuite will stay in the 
RTEMS repository (rtems.git) then we create a separate repository and 
consolidate *all* our externals.  We will want to come up with a manageable 
hierarchy to keep things organised.  Eg:

rtems-vendor.git
  network/stack1
  network/stack2
  network/stack3
  lib/liba
  lib/libb
  lib/libc
  daemon/server1
  daemon/server2
  daemon/server3
  ...
  vendor/network/stack1
  vendor/network/stack2
  vendor/network/stack3
  vendor/lib/liba
  vendor/lib/libb
  vendor/lib/libc
  vendor/daemon/server1
  vendor/daemon/server2
  vendor/daemon/server3

We also have the option if we wish to have an rtems-vendor.git and 
rtems-vendor-src.git.  If we are afraid of bloat it is not a big deal to put the 
/vendor/* directories in their own repository.

We should start a separate thread and list out what will be consolidated, the 
layout frequency of release and do a rough calculation.  It should be just fine 
to keep it all together in one repo.


Amar.