On 20/8/19 4:51 pm, Christian Mauderer wrote: > On 20/08/2019 00:32, Chris Johns wrote: >> 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. > > Your rtems_waf is a great starting point for reducing that effort (at > least for the build system). But you are right that this can be a big > hurdle.
It helps. I wonder if a step by step tutorial would help? >> 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? >> > > 2 and 3 are both mainly about testing. I agree that this is really > relevant. But is that really simpler with one repo than with multiple > ones? If one repo contains multiple libraries, they need a way to build > and test too. Agreed. >> 4. The release should capture the repos. > > As long as we don't have scripts to do releases it's right that this is > a huge extra effort for each repo. Good point. But we do .. https://git.rtems.org/rtems-release/ ? If the package is in the RSB I can get it to collect the source if we reference the repo as a tarball, which is what we are now doing. >> 5. Cluttering the cgit repo interface where our main focus repos get lost is >> a >> sea of other repos. > > That's why I suggested a prefix or sub-folder. > Yes. >>> 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. > > Wouldn't it just work exactly like the sub-folders for everyone with > commit access? If it does this is a solution but I would need to check. >>> What would be the advantages of one collection repo? >> >> Simpler management and shared overheads, ie build system, testing, releasing >> etc. > > OK. All valid and good points. Some of them are definitively more > relevant than my point of "the repo could get cluttered". But if one > repo is created, we should be careful to have a look at new stuff and > maybe re-discuss a separate repo for stuff that might get bigger. I am happy with separate repos if there is a wider agreement on this so the maintenance work is understood and shared :) > By the way: Where do we draw the line whether something goes into the > RTEMS core repo (like I2C or SPI) and when in some package repo (like > the multiio discussed here)? I think a package (repo) is a great to startinf point for an API to field test. I feel once we get something that is important to RTEMS as a more formal interface it can be moved there and the repo can be archived. >>> 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. > > Yes right. And I don't want to question that. That was just a hint that > it maybe would be good to migrate the playgrounds to some prefix on the > long term. It's no urgent matter and I don't want to start that right > now. It's just something that we should keep in mind in case we have an > opportunity like a reorganization or similar. The reason is the same as > mentioned above: It could make cgit (or similar lists) simpler to read > if the playgrounds are grouped. I like the subdir idea and it if works maybe we can have a playground. I just need some time to look into it. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
