[PATCH 00/13] Replace mongoose with civetweb.
amar at rtems.org
Mon May 2 13:08:11 UTC 2016
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:
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.
More information about the devel