[PATCH 00/13] Replace mongoose with civetweb.

Mon May 2 07:57:45 UTC 2016

Am 02.05.2016 um 01:42 schrieb Amar Takhar:
> On 2016-04-29 17:39 +1000, Chris Johns wrote:
> 
>> I had a long chat to Amar about this topic today and he told me we 
>> should follow the FreeBSD model for vendor software. FreeBSD has 
>> https://svnweb.freebsd.org/base/vendor/ and it contains the vendor 
>> source untouched and then the version used is a copy with local changes. 
>> If you follow the link the bind directory is the untouched vendor source 
>> and bind9 is a copy of the bind v9 vendor source with the local changes. 
>> His view is we create rtems-vendor.git and bring all the code into this 
>> repo. He said we should bring all the networking stacks and libbsd each 
>> as a separate directory. He said it brings into a single place the 
>> history of all the packages we have to manage and it lets us combine 
>> this code with the tests. It means users have a single place to go for 
>> any vendor source. It is a change in direction from the RSB per package 
>> approach but if we adopt rtems-vendor.git I do not mind. It also allows 
>> the testing framework he has been working to be used. I will let him 
>> explain this more as it is not area I know too much about.
> 
> My biggest reasoning for merging and my fear about splitting it up is 
> visibility.  Some of the reasons I'd rather have these all in one repository:
> 
>   1. Encourages the re-use of code since it is easy to see what is available.
>   2. 'git log' shows all changes to every module in one place.
>   3. Avoids lesser used modules from quickly being forgotten or becoming out of 
>      date.
>   4. Allows for easily testing all the possible options quickly without further 
>      work.
>   5. Gets users off of old software by making updates more visible.
>   6. By keeping all the toys in the same sandbox is encourages users to play.
>   7. Having to 'git clone' and chase down repositories is quickly becoming a 
>      burden for modern users.  RTEMS has a lot of repositories and we will only 
>      have more in the future.
> 
> #4 is important since it is easy to fall into the trap of using the first module 
> or package that works without bothering to checking the rest -- even if an 
> alternative would be better.  If you are faced with 10 different packages in 
> separate repositories you'll tend to just use the first one that works.  If all 
> 10 are in one place and only requires a change in your build command to try 
> other options then you are more likely to do so.
> 
> There is certainly a fear about this becoming a 'dumping ground' however this is 
> easily mitigated by having a set of rules on what gets added or does not.
> 
> Maintaining vendor imported sources is easy.  Unfortunately Git offers some 
> challenges in doing this.  I've used a tool called 'braid' in the past: 
> https://github.com/cristibalan/braid  Another one I have played with this 
> git-vendor: https://github.com/brettlangdon/git-vendor
> 

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?

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?

> Whatever we choose I would want the method to enforce the ability to strictly 
> track vendor changes.  Without this it will be a mess down the road when it 
> comes to debugging or figuring out where bugs were introduced.  FreeBSDs vendor 
> information goes back 20+ years.  It's saved myself more time than I can count 
> when trying to track down issues.
> 
> 
>>> For the average users it wouldn't make a difference. They most likely
>>> don't want to test RTEMS but only use it.
>>
>> Sigh, Joel and I have been working hard over the last few years to open 
>> testing up so users can test. The RTEMS Project is open and testing is 
>> an important part and it needs to be open. We want published test 
>> results and we want users to confirm they can match those results with 
>> their build. It should not be the domain of experts. My hope is how you 
>> build for production is how you build to test.
> 
> With the new test suite it will be extremely easy to run the tests.  Users will 
> want to run them and hopefully submit feedback.  I would be highly against 
> anything that made testing worse for users.  I've been working 6 years to make 
> it easier for everyone.
> 

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.

> 
>>> So it's not relevant for them
>>> if they build civetweb before or after the BSP.
>>
>> I do not agree. If a user builds some code they should expect to be able 
>> to test it. It should be normal and natural. If we are missing tests it 
>> is something we should fix.
> 
> Agreed 100%
> 
> 
>>> On the long term, this kind of structure could improve the ability to
>>> test RTEMS and it's libraries. We can for example build and install
>>> civetweb and the three network stacks as libraries. If we then build the
>>> BSP afterward, the build system can detect which libraries are available
>>> and build a test for each combination (civetweb with each of the network
>>> stacks). We would just have to link against another library. So for a
>>> complete test run (including all stacks), you only need one set of libs
>>> and one BSP built in the right order.
>>
>> I assume this means the test source becomes a separate package. I had 
>> also floated the idea and Amar made the point to me that it would be a 
>> mistake to move the tests and testing away from the code being tested 
>> and have to agree.
> 
> The test suite as a whole should stay together.  If tests need to be upstreamed 
> they should be however if they are for RTEMS then all must stay in one place.  
> This helps with tracking progress and cross referencing with the RTEMS source 
> when we get down to profiling and coverage.  As for how we enable these tests 
> there are a dozen different ways to do this we can pick the one that makes the 
> most sense for us.
> 

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?

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?

Kind regards,

Christian

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.