Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Project Graphics was now deleted Inofficially a graphics@ maintainership of a package meant "fix the bugs yourself" for quite some time already. So I doubt the current state got worse via the removal of the project. That said, this is actually for a subset of the packages one of the cases where a project would really make sense. We have a lot of central libraries here that are used by many other software. libpng, jpeg, tiff, ... These are definitely worth a team of maintainers. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Now for the future, I wouldn't mind having a "last rite: XYV Project" or
> similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
> taken, so the project members/lead has one final chance to stop it.
Good plan.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On 6/7/20 9:14 PM, Jonas Stein wrote:
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.
>
> Thank you.
>
The "voting" and "discussion" happened in #gentoo-dev IRC channel. Every
participant was unhappy with the state of graphics project, and even
after pinging the project, no members responded. This "discussion" has
been ongoing for a while now. While I agree the outcome wasn't clean, in
my eyes attempts to contact project has been made.
Now for the future, I wouldn't mind having a "last rite: XYV Project" or
similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
taken, so the project members/lead has one final chance to stop it.
Maybe this even encourages us to go through some of the more inactive
projects currently?
-- juippis
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, Jun 7, 2020 at 2:14 PM Jonas Stein wrote: > > On 07/06/2020 03.43, Aaron Bauman wrote: > > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > > > I will happily revert my change on the graphics project Wiki [..] > > Glad to read your offer. Yes, please do so. > > I think it would hurt the Gentoo project if single developers delete > projects > > - without without informing the project members > - without prior discussion (on gentoo-dev for example), > - without vote/consent > - without an organized shutdown (reassign bugs, archive things...). > > However we should continue to find a general solution for the problems > discussed in this thread and find a general consent. While I get what you're saying, I think it would also be helpful if we just let people who feel they are actually impacted by changes like this speak up for themselves, instead of assuming that they must exist and that it is our duty to speak up for them. Are you, directly, impacted in any negative way by this change? If so it would probably be helpful if you just explained the issue. This really seems like a fairly uneventful change. I do think it is better to pre-announce changes. However, I suspect that most of the fuss is because a lot of people assume that a change like this must have some kind of big impact, and for whatever reason all the people who are being harmed by it are just afraid to speak up so we must do so on their behalf. I say this as somebody who used to raise a lot more hypothetical objections to changes in the past. I've since learned that it is easy to over-react, and that when others are actually impacted by a change they will tend to speak up. I'm pretty sure in this case there was an organized shutdown - I doubt they just removed the project without reassigning packages or bugs. They were effectively already assigned to nobody as it was, since the project was inactive. I guess my point is that while this probably could be done in a better way, I think it is likely to end up happening either way, so all undoing it is going to do is send a lot of people two more rounds of bugspam at best. Or, it will result in one more round of bugspam and then these packages continue to be unmaintained because nobody is going to bother doing all the steps you're suggesting to get rid of it in the future. Easier to just leave the dead project around and let users wonder why nobody pays attention to the bugs they open. -- Rich
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On 07/06/2020 03.43, Aaron Bauman wrote: > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > I will happily revert my change on the graphics project Wiki [..] Glad to read your offer. Yes, please do so. I think it would hurt the Gentoo project if single developers delete projects - without without informing the project members - without prior discussion (on gentoo-dev for example), - without vote/consent - without an organized shutdown (reassign bugs, archive things...). However we should continue to find a general solution for the problems discussed in this thread and find a general consent. Thank you. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, 7 Jun 2020 06:43:19 -0400 Rich Freeman wrote: > 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 was thinking perhaps instead of "group membership" oriented things, we could instead have a "developer proficiency" oriented system. Developers could choose skills from a defined list (like projects, but finely grained) Maybe with some WOT based proficiency rating thing. Then maybe the project system becomes used mostly for "primary ownership" of well maintained sets of things with great team structure, and the proficiency system becomes a defacto fallback for everything else. Packages are tagged with the sort of skills required to maintain them effectively, and people who have registered with said proficiencies get CC'd into the bug (somehow) and similar things. Like, for instance, when a package uses perl stuff, but isn't inherently owned by perl@, I still care, but registering that I care is tricky. And then potentially packages with above "good maintainer-ship" could indicate some sort of maintainer-ship grant to "people with proficiency > X in Y". Yes, I'm likely over-thinking everything here too much, but I suspect somebody could get some inspiration from something here :) pgpGDBplJU7XL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein 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
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > Hi, > > our concept of "Projects" (Herds in the past) maintaining packages has > several problems. [snip] Overall, projects work if the members are active. Of course, they don't if not. So, whether a package is assigned to a project, a sole-maintainer, or co-maintainers means others will *unlikely* attempt to fix or bump the package. Of course, we know that some devs will inevitably bump the package when it get's in their way or they use it directly. However, if the package is assigned to maintainer-needed then proxy-maintainers, random contributors, and other Gentoo devs will feel more comfortable touching it. I believe the system works... I will happily revert my change on the graphics project Wiki as you may want to remove the other inactive members or recruit some folks to join the project. Then possibly pick up the stray packages that others haven't taken. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] [RFC] Concept of Projects - How to proceed?
Hi, our concept of "Projects" (Herds in the past) maintaining packages has several problems. Which problems do you see? How can we improve the situation? How do we want to organize/cluster packages in the future? I see the following problems: * We have ten thousand packages for few hundred developers. Projects can not heal the lack of resources. If a developer is member in 10 projects, she/he can only contribute a fraction of the "Gentoo-time" to each project. * Someone added the project to a package many years ago and nobody is left in the project who knows/uses the package. I saw this problem for example in Project:Games, where we have games that need a CD, but there is no developer in the project left who has access to the CD. (If you want to help: https://wiki.gentoo.org/wiki/List_of_discs_by_developers) We have the same problem for hardware in Printing, Video, Sound. * 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... * We need something between one developer per package, who reacts on every bug within days and the package is unmaintained. * The members of a project are not paid by Gentoo or the lead and want to invest their (spare)time only to specific packages. However a project makes only sense, if all members are willing to maintain the packages of the project. Project Graphics was now deleted without discussion. Have a look at https://wiki.gentoo.org/wiki/Category:Gentoo_Projects there are many projects with the same problem of Graphics. I think we should first find a consent about the following questions before someone deletes projects. * How do we want to delete projects? Vote? Decision by a single dev? Based on statistics? Based on inactivity? Based on lack of manpower? Based on useful package selection? * What is a good structure for a project? * Should we group packages by requirements? (Specific hardware needed. Special skills required.) -- Best, Jonas signature.asc Description: OpenPGP digital signature
