[PATCH 00/13] Replace mongoose with civetweb.
gedare at rtems.org
Mon May 2 01:20:57 UTC 2016
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
> 4. Allows for easily testing all the possible options quickly without further
> 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.
More information about the devel