On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein <jst...@gentoo.org> wrote: > > our concept of "Projects" (Herds in the past) maintaining packages has > several problems.
You might want to search the list archives as many of the issues you've raised have been discussed extensively. There was never a complete push to fix things, but most project removals/etc have been along the lines of what has been discussed. While tangential, I'll point out that there have been similar discussions around appropriate uses of eclasses and there are some loose parallels for when eclasses make sense. > * Many projects are too heterogeneous > Projects should only maintain either > a) many similar packages such as libraries (like Perl, Python) or > b) very few strong correlated packages (like KDE, Kernel, Xfce) > > It makes no sense to group packages by usage as in > Science, Games, Theology, Sound, Netmon, Video, Electronics... ...graphics... This is the gist of the outcome of previous discussions. Projects make sense when developers actually work TOGETHER to maintain things. Nobody who works on qt is going to just upgrade one component of qt without talking to the other maintainers. It makes sense for those packages to be managed by a project. Historically a lot of projects worked more like "tags" as an alternative way of grouping packages other than categories. While tags are a great idea projects are a terrible way to implement them. > I think we should first find a consent about the following questions > before someone deletes projects. In general I'm a fan of announcing things like this BEFORE doing them. However, I don't think they need pre-approval when they make sense. If anything we haven't been doing it often enough. I don't see any point in bringing back graphics though - if somebody who actually intends to lead such a project wants to speak up on that they should certainly do so, but it sounds like it is just a vestige of an old herd that probably never worked as an actual team. People reading the thread shouldn't think that this has anything to do with the importance of the individual packages. This is purely about how devs are organized around them. Some of what you wrote was more about our larger meta-structure and how devs maintain packages in general. That has also been discussed quite a bit, like having a core group of devs who don't maintain any individual packages and all they do is QA pull requests from a much larger pool of individuals who do care about packages. There are a lot of pros and cons to that and I won't rehash the previous discussions here. That isn't to discourage anybody from doing so - I mainly just want to point out that this stuff is in the archives. -- Rich
