On 20/8/19 5:12 am, Christian Mauderer wrote: > On 19/08/2019 00:35, Chris Johns wrote: >> On 18/8/19 3:53 am, Joel Sherrill wrote: >>> >>> >>> On Fri, Aug 16, 2019, 8:43 PM Chris Johns <chr...@rtems.org >>> <mailto:chr...@rtems.org>> wrote: >>> >>> On 17/8/19 7:02 am, Joel Sherrill wrote: >>> > FWIW the repo is git clone git://git.rtems.org/multiio.git >>> <http://git.rtems.org/multiio.git> >>> > >>> > More below >>> > >>> > On Fri, Aug 16, 2019 at 3:20 PM Wendell Silva <silv...@gmail.com >>> <mailto:silv...@gmail.com>> wrote: >>> >> >>> >> Well, I'm a non-OAR user with at least one customer 100% satisfied >>> with >>> multi-io lib. >>> >> >>> >> Suppose I'm going to championize it, how do I do to get started? >>> > >>> > I'm glad you are happy with it. I was happy with it on the robotic >>> project >>> > I did with it. >>> >>> This repo could be added to the RSB as a package. It has been converted >>> to >>> rtems_waf however it would be good to have the support changed from the >>> files >>> being in the multiio repo to a submodule referring to the rtems_waf >>> repo. >>> >>> Can the package be built for all BSPs? >>> >>> It would need to be documented. I was considering adding a Packages >>> chapter to >>> the User Manual and it could be a section under that chapter. >>> >>> >>> Personally, I think there are only two things of long-term value in it. A >>> few >>> shell commands and an interface to access discretes and analogs. >>> >>> If the interface is just considered a shim layer that an application can >>> implement, then it is independent of any bsp. A system with multiple IO >>> cards is >>> abstracted through this by the system integrator. >>> >>> Is it worth being independent then? >>> >>> The two drivers in there now are PC-104 so only available to pc386 and >>> possibly >>> not even compatible with anything you can buy now. One was based on a single >>> chip solution so may be available in later incarnations and for other >>> buses. No >>> idea though. >>> >>> I don't mind treating it as a small package either. If we want to show how >>> one >>> should be done, this is small enough to be an example. >> >> I do not know which is better, a common packages repo or separate repos for >> each >> package. I am tending to lean to a packages repo where we can collect >> fragment >> of code like this. >> >> Chris > > Hello Chris, > > I had some bad experience with collection repos in the past (private and > at work). They tend to become big and contain a lot of unrelated stuff. > Even if you only want a small part, you always have to clone everything. > And some packages might grow with time and then it's hard to split the > repo up.
This makes sense and I am concerned this could happen. > I assume the main problem with lot's of repos is that it's slightly > confusing to find anything? It can but I hope no matter which path is taken we have some documentation that helps a user. My main concerns are: 1. Creating a repo, build system and test set up for small pieces of code can be an obstacle to the code being placed in the open. 2. We need to have a way to test each repo, building and even running tests. The RSB's 3rd party packages support is a good start and when combined into a package set for a BSP it should be easy to build with a single command. 3. Testing? 4. The release should capture the repos. 5. Cluttering the cgit repo interface where our main focus repos get lost is a sea of other repos. > If that's the only reason maybe it would be > better to add a prefix or put packages into a sub-folder. Something like > 'rtems-packages/multiio' in this case. This could work. I see cgit has a `project-list` option but I would need to check in detail if it fits doing this. > What would be the advantages of one collection repo? Simpler management and shared overheads, ie build system, testing, releasing etc. > PS: Maybe we should have created the maintainer playgrounds more as > 'user/<name>', 'user-<name>' or 'private/<name>' or similar. Anyone with commit access has a personal playground now. chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
