On Sat, 9 Dec 2017 23:21:57 +0000 "Robin H. Johnson" wrote: > I did wish to participate re two items here, but regretfully I will be > travelling at the time, and it's unlikely that I will have > connectivity. > > On Sat, Dec 09, 2017 at 08:39:54PM +0100, Andreas K. Huettel wrote: > > 3. Final review of GLEP 74 [4,5] > > -------------------------------- > > Full-tree verification using Manifest files > The implementation is done, some tweaks were made since the previous > month's version. > > > 4. Restricting gentoo-dev/-project posting [6] > > ---------------------------------------------- > > * Restricting posting to both gentoo-dev and gentoo-project, while > > creating a gentoo-experts list? > > * Restricting posting to gentoo-dev and moving all official > > business there? > > * Restricting posting to gentoo-dev and moving all official > > business to a revived restricted gentoo-council list? > > * Moderating lists instead? > I had not weighed in publicly on this before, but wish to make a > statement. > The original split of gentoo-dev to gentoo-project included > moderation of gentoo-dev, however that was never really implemented, > mostly for technical reasons, and a decreased need after the split. > > I oppose a further split of -dev/-project/-experts, and instead > propose better list policies of -dev. If it's technical, even coming > from an expert user, it probably belongs on -dev. If it's about the > organizational structures of Gentoo, it belongs on -project. > How do we keep the threads more on-topic? Moderation maybe, but I'm > not convinced that is best. > > I second this. I too do not want to see the lists split even further. There are far too many interested and competent users in it that can and do contribute in some ways. There has to be a better solution. Also: 1. Lack of enough package maintainers [1] ----------------------------------------- Anything that can be done? I am intending to set up a buildbot instance and develop some builder scripts for it to aid in regular package maintenance. It should be able to do basic version bumps and run the test suite, present it to the pkg maintainers for final Q/A and pushes to the tree. It should also be able to check/test on whatever arches that have a worker connected to it. So this should help take some of the pressure off the various arch teams. My first goal is for it to do many of the python pkgs I maintain to get the basic system up and running. Plus I should be able to leverage some of the g-sorcery/gs-pypi code. Once operational, it should be possible to add additional parsers to check for and update dependencies to add additional types of pkgs to its capabilities. I will be able to have it run on amd64, x86 and arm64 arches with the equipment I have. Plus I have had others say they could help with additional arches such as an armv7 cluster. So, this should also help with keywording demand. -- Brian Dolbec