On 2023-01-20 11:03 +1100, Chris Johns wrote: <snip> > It is good to know the amount of python is small. It should be easy to add :)
Agreed. > I have been OK with the headers and tests being generated this way because the > agreement is files in rtems.git can be manually edited and rtems-central has > to > track those changes. The sources and code to generate the files need to be > located together. Yes. To be clear in this case if we have <somefile.h> in rtems.git and <somefile.yml> in rtems-central.git where you need to edit <somefile.yml> to generate <somefile.h> then both the tool *and* somefile.yml need to be in rtems.git. If what you are saying is the requirement is reversed. rtems-central.git needs rtems.git to work that's fine and the order it should be. > The specification maintenance is a separate responsibility to the function and > role of rtems.git and related repos. The bar to make changes in rtems.git is > at > the source level because it is the norm for open source projects and those > working with the code. The separation also helps make it clear how funding of > the qual related work happens. If we bring those specifications items down > into > rtems.git the responsibility moves to that repo and that raises the bar on > being > able to make a change. Our view on this may change as we learn now the > pre-qual > effort effects what we do. I think the important part here is it's evolving. Change happens sometimes you do one thing one way to discover you really want or need to do it another. > We have YAML files to run our build system and it is awesome. It also allows > automation so I think it makes sense to provide an interface to read and write > these files to aid automation rather than a disjointed set of personal > scripts, > tools etc that may break or clash. Agreed on this. > The FreeBSD single repo is about the kernel and base runtime. The ports are > not > part of this so the analogy breaks down. Bringing the RSB, RTEMS tools and > documentation into a single repo creates new complexities I am not sure we are > prepared enough to handle those. Maybe patch review and CI would help here and > how they effect a single repo is something I have not given much > consideration too. In theory I'm not against bringing everything together into one repository it allows for a lot of inter connectivity we can't do right now. Regardless even if we had been doing it this way I would still advocate for the change being in the /rtems/ directory versus /rtems-central/ Amar. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
