[PATCH 00/13] Replace mongoose with civetweb.

[Gedare Bloom]

On Sun, May 1, 2016 at 7:42 PM, Amar Takhar <amar at rtems.org> wrote:
> 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.
>
+1 this approach sounds reasonably sane. I have some concerns
regarding licenses and hardware-specific variants, but these can be
mitigated too I believe.