Replying to the mailing list as I find it clearer and easier to cite; not yet on all topics, probably.
Am Thu, Mar 26, 2026 at 11:02:03AM +0100 schrieb civodul: > To me, it's more of a "fine tuning" phase as I don't foresee significant > disagreements. I am not sure about this... My main motivation is to make removals easier and faster. This is why I suggested 2 weeks (and longer for not so disturbing cases); then moved to 3 weeks for all cases. So if the fine tuning means that things become not easier for the janitors, but possibly even more complicated, then this GCD would not reach the desired goal. > A second change here compared to current policy is going from two months not > building + one month review (so three months) to three weeks (potentially > three > weeks after it first failed to build!). I would be more comfortable with a > middle ground, say two weeks not building + three weeks of review? In practice we do not check the two months (CI makes it often, but not always possible, and QA does not readily show the information; at the same time, recently it has been more a year than two months...); so it is one month from noticing something is off to removal. The 3 weeks are already a middle ground between 2 weeks and one month... I would definitely like to not use this potential three step procedure: something breaks, put it into a TODO list; two weeks later come back to it and file an issue or a PR; three weeks later come back to it to do the removal. This is worse than the current (in practice) two steps. Also, when we get closer to a 100% buildable distribution, it would be nice to act faster. > Overall, if I were to list cases where building packages may be removed, I > think "security issues" is the only tangible reason to do so. It would be an > addition compared to the current policy which lists two reasons: end-of-life/ > unmaintained, and failing to build for two months. Wording wise, I am not sure if old versions could be considered EOL/unmaintained. Maybe we should add security and the fact that we have a newer version? But this could also be quite radical; it is not because we add a newer version of boost, for instance, that we immediately want to remove all packages still requiring the older one. So I think the current text makes sense here with the different cases. > +candidate falls into the realm of a team, this team must be notified, > +and consensus shall be sought about the removal in particular with this > +team. Reasonable efforts shall be made beforehand to update or otherwise > +preserve dependent packages. > > I find the current wording slightly clearer: > If the package has many dependent packages—as is the case for > example with Python version 2—the relevant team must propose a > deprecation removal agenda and seek consensus with other packagers > for at least one month. It may also invite feedback from the > broader user community, for example through a survey. Removal of > all impacted packages may be gradual, spanning multiple months, to > accommodate all use cases. The new wording makes deprecation easier, so it is also a material change; it replaces "a deprecation removal agenda" and "at least one month" with "reasonable effort". And indeed it is a bit more vague. > +since it may lead to circular dependencies between modules and thus break > +compilation; also deprecating a package by one with the same name leads to > +nonsensical warning messages suggesting that a package is superseded by > +itself. > I sketched a mechanism to handle this. Would you mind proposing concrete wording? That would be helpful. > My suggestion would be to change this paragraph to suggest that the old > variable (not the package name) will be marked as deprecated with > define-deprecated or similar for at least X months (for renaming, the current > policy says "one year"; for variables moved, maybe 6 months is a good middle > ground, to leave time for people to update their code?). That sounds good to me. > +Additionally, the Codeberg team `deprecation` will be created to which > +interested parties can subscribe (for instance, one participant per > I'm skeptical about (1) the expected benefit of becoming a member (compared to > monitoring the deprecation label), and (2) the organization around it (would > everyone have to tag @guix/deprecation in addition to adding the deprecation > label? who would maintain the team members? now we'd have a team not managed > by > etc/teams.scm, unlike all the other teams? how would that affect team > membership transparency?). > I would lean towards dropping this idea of a "deprecation" team. The idea was to add an additional means of communication notably with channel maintainers, that would be more "push" (an email notification) than "pull" (visit a bookmarked page with all deprecation issues, which apparently people do not do). I think the weekly guix-science breakages you mention could be avoided if every three weeks, a channel maintainer went through the list of removal requests and did a "git grep" in their channel with the names of the affected packages. But indeed the team idea seems a bit complicated to put into effect. Tomas Volf suggested a script; we could have a webhook that reacted on deprecation issues/pull requests and sends a notification to an RSS feed or a mailing list. What do you think about the idea? We could also remove this passage completely, but then we would be back to the current situation that guix-science maintainers are unhappy with. > The deprecation policy currently reads: > If the package being removed is a “leaf” (no other packages depend on it), > it may be removed after a one-month review period of the patch removing it > [...] > So one is already supposed to file a pull request, but not an issue (I know > that this is often not what people have been doing). The proposed change is to > require both individual issues and catch-all pull requests. > Instead of the proposed change, I would proposed sticking to the existing > policy (for real this time :-)): filing individual pull requests with the > deprecation label. I think it's more efficient, somewhat more transparent (no > catch-all PR), and has the same effect in terms of publicity. Maybe. The idea was that not all removals go through, so a low-key initial message "hey, this breaks, please fix it or it will be removed" avoids having to do a pull request, which is a bit more work. (Every pull request has its own local branch and branch in my fork, which I cannot delete; so having many pull requests on Codeberg creates local chaos, where on debbugs one could even do a fire and forget approach since the patch was on debbugs and remained there.) So the idea was to create the PR only for things that most probably will be removed, and only one every week or so. (We constantly have about 50 removal requests filed by two or three people.) But well, maybe just PRs without issues are a comparable amount of work, and a simpler approach also has advantages. Hellseher, what do you think? > +Leaf packages that by their nature were used mainly as inputs to other > +packages (for instance libraries, but also older compiler versions) require > +build farm capacity and maintenance work for little to no gain; they may be > +removed following the above process. > > This is too broad. I mentioned one use case for old compilers recently. But > more generally, I think this paragraph makes very broad assumptions about use > cases, which may or may not hold. > > I think we should not decide based on guesses of how people might be using > packages. Thus I would suggest dropping this paragraph. This would make it impossible to remove even EOL packages; notice that the content of this GCD is supposed to be comprehensive and *replace* the current policy in the manual (this is exactly my argument for GCD 007 that if the "one year" wording is not repeated in the GCD, it is removed from policy). If the GCD is accepted, I would rewrite the manual to include the new provisions. So this paragraph is essential, otherwise we would never be able to remove ispell-for-linphone as long as it builds, even if linphone does not need it any more. Andreas
