On Sun, Feb 02, 2025 at 03:44:28PM -0800, Felix Lechner wrote: > Okay, sorry about the sarcasm, although sometimes I think that's exactly > what a community needs. I meant to be a mirror.
Fair enough, although none of us old-timers think it's going to be a simple and easy fix for everything! Personally I think that sarcasm can be detrimental in a text-based environment, where there is too much diversity among participants for it to land properly. I think the your follow-up email is really useful and constructive, and I'm grateful that you took the time to write it. > There is no other way to close bugs than to actually work on them. If the problem is ultimately the backlog of bugs / patch tickets, then yes, there's no substitute for working on them. But I perceive the problem as going beyond that. We have a torrent of bug reports and contributions, which is fantastic. That's a good problem to have for a free software project. But how can we "actually work on them" if the number of people able and willing to do so is too small? It's not that easy, right? We get lots of bug reports, but not as many patches to fix them. Having been involved with Guix for many years, during several of which I performed a large proportion of the code review, I realized the hard way that it's always necessary to resolve issues properly. We'll never reduce the backlog and actually improve Guix (rather than just close tickets) if we commit buggy, unmaintainable, or unidiomatic code that breaks conventions and models. I'm sure you know that, I don't mean to be condescending. But my point is that I believe that we have to help contributors grow in their ability to make efficient contributions that pay off in the long run, so that they can commit code without oversight, and in turn mentor more committers. And that has to happen fast enough that the chain isn't broken when they inevitable leave the project for one of the reasons that we all eventually leave. I believe that the best way to do that is to cast a wide net, always bringing in more people and making it easier to get started, and to take the next step, and the step after that, and I hope that using a non-email workflow will help with that. I don't think the impact of web-based workflows like Github on overall participation in computer programming should be discounted (although maybe economic conditions can account for it instead). There are soooo many programmers these days, way more than population growth can account for. To put my cards on the table... I'd miss living in Mutt very much. But I think this change would be the right thing for Guix and any other project like it. > 1. Issues on code forges are hard to audit years later. Usually, I > can't even locate what I'm looking for. That would be bad. We'd need a solution to preserve the record in perpetuity in an accessible way. > 2. Forges like Codeberg can disappear like Freenode or sell > themselves to Microshaft like Gitflub. Yeah, it's a risk, but there's a risk of losing our platforms no matter what we use, whether to perfidy, exhaustion, or whatever. > In order to solve its problems, Guix needs to: > > A. Expand Git access to several hundred people. Yes, in conjunction with: > B. Stratify authorizations, perhaps based on an honor system, > according to people's area of expertise. I don't think the Guix maintainers would suddenly expand commit access without some kind of finer-grained authorization system. > It needs focus on solving user problems and be more granular > than teams instead of merely aligning with upstream tools or > packages. Can you clarify this suggestion? I'm not sure what you have in mind that is more granular than teams but not as granular as Debian's "package maintainers". I do think we need a way to let team members commit, perhaps to a team branch, as suggested in the GCD. > C. Develop a quality standard for packages higher than "it builds." > Many packaging errors show only at runtime, especially in Guix. Absolutely. Again, I think we need a lot more people who create high quality work but, to repeat myself, first we need to find / grow them. > My brief, cynical message was acceptable for the discussion (or so I > thought) but this longer message clearly does not belong into the > Codeberg thread. Sorry, Ludo', for hijacking. I think that it does belong, since the Codeberg proposal is about making it more attractive and easier to contribute to Guix, and the second-order goal of that is to grow able and trustworthy contributors, with the ultimate goal of improving the long-term health of the project. If Codeberg is the wrong thing, then okay, but I think we share a goal and it's fine to talk about that here. PS, a few numbers: I tried to compare two periods of roughly equal length, that post-date the "early days" of Guix. With Guix 0.8, there was a standalone functional package manager, an environment / shell creator, grafts, and an OS. Basically the same offering as today, but of course much smaller. Growth of active committers: ------ $ git shortlog -ncs v0.8..v0.9.0 | wc -l # ~23 months 20 $ git shortlog -ncs v1.4.0..HEAD | wc -l # ~25 months 51 ------ Growth of contributors in the same time period: ------ $ git shortlog -ns v0.8..v0.9.0 | wc -l 47 $ git shortlog -ns v1.4.0..HEAD | wc -l 570 ------ So, we are not growing our base of committers in proportion to contributors, and I think we've lost contributors as a result.
