[PATCH 00/13] Replace mongoose with civetweb.

[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

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.


> > 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.


Amar.