Le jeu. 1 déc. 2022 à 20:26, Sebastian Kuzminsky <s...@highlab.com> a écrit :
> On 11/30/22 22:24, Johannes P Fassotte wrote: > > It was not to may years ago that LinuxCnc was just over 120Mb in > > extracted size. Now V 2.9 master is takes up 252Mb so its getting > > bloaded with a lot of none essential things. I think it needs a good > > cleaning to get it back on track. I feel that there are to many > > personnal projects being added that are better suited to be developer > > supported addtions and not part of LinuxCnc itself. > > I think the best way to address this concern would be to provide > finer-grained packaging, so that users can choose what GUIs to install. > Indeed ! I hope this is something we'll reach someday 🤞 There is a strong incentive to keep the GUIs in our repo, so that GUI > developers don't have to reproduce our test & packaging infrastructure. > hmm, well, with all the automation possibilities we have, I don't think this is such a big issue. As far as tests, build and packaging are concerned, I feel like the biggest problems are: * like Johannes pointed, that our repository is becoming a heterogeneous behemoth * there is a problem of knowledge sharing on these matters Let me take two late contributions of yours as examples: * you tweaked the GitHub workflow to use Docker containers, and build for several Debian versions and architectures, which is awesome, and the bonus point is that it is just there, available in a standard place where anyone with GH practice can find it and understand it. I already stumbled on a couple of actions that could add small shinny bells to it * you configured publishing of the (devel) translated docs -- thanks a ton for that, that made my day this morning 🙏💥 -- I have neither idea how you did it, nor where to look at to learn. Going further, if those related projects were split: * each would have a much simpler build system, instead of our current big "recette du chef" * finer-grained packages would come naturally, and most probably at an even finer granularity than we could envision today * each could freely and more easily adopt practices and tools most suitable to the languages and technologies they use, as well as a development lifecycle of their own * last but not least, this would support the (re)definition, documentation, versioning and improvement of components interfaces This would bring us a cleaned up and refined architecture overall open the project to more collaborations and evolutions, as well as make the cool kids think they could have good times hacking here :) We could move (for example) the Qt stuff into a new `linuxcnc-gui-qt` > package, which would be installed by default but easy for an end user to > remove. > I wish one could run `apt install [axis|gmoccapy|silverdragon|probe-basic]` and get Debian making its magic pulling all that's needed and only that. > I have no intention of working on this myself, but I would be happy to > review a PR that has successfully made it past our automated package & > test systems. > No rush, Gene just gave us hope that we'll still be here in more than 40 years 😅 Peace J _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
