Hello, going through the more minor points I would like to act upon.
Am Thu, Mar 26, 2026 at 11:02:03AM +0100 schrieb civodul: > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +186,4 @@ > +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. > > 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?). > > There are technicalities but I think they don't have to be addressed in the > GCD. For instance, when moving a variable outside of its module (meaning it's > the only package in this module), define-deprecated-alias/public is enough. Okay. I have changed the "Moving packages between modules" paragraph to make deprecations mandatory without explaining how, as this is still a bit mysterious to me. If this GCD is accepted, we need to translate this into a clear recipe in the manual. I have also changed the delay for *both* renamings and moves to 6 months; again a uniform procedure makes things easier (no need to distinguish between define-deprecated-package and define-deprecated-alias/public), and half a year is quite a lot. We can expect people to look at their Guix installation, channels and so on maybe twice a year. > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +92,4 @@ > +(non-)importance, obsolescence etc. of the package is welcome, but not > +required. Deprecation issues can easily be > +[consulted](https://codeberg.org/guix/guix/issues?q=&type=all&labels=445131) > +by channel administrators. > > Please keep in mind that removing a binding affects everyone, not just > third-party channel authors: those variables may appear in OS configs, Home > configs, manifests, and so on. > > So s/channel adminstrators/interested parties such as channel maintainers/ at > least. Okay, done. > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +94,4 @@ > +[consulted](https://codeberg.org/guix/guix/issues?q=&type=all&labels=445131) > +by channel administrators. > +Additionally, the Codeberg team `deprecation` will be created to which > +interested parties can subscribe (for instance, one participant per > > s/can subscribe/can ask to become a member of/ ? > > 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. This is indeed a bigger change. I had added it because I thought the notification question was a big pain point for channel maintainers, although I personally do not think it is askin too much to click on a link or open a bookmark once every two weeks. If people are fine with it, I can remove all this; we can always come up with better ways to inform people about upcoming changes (some where discussed around this GCD). So taking any additional notifications out from this draft. > 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. Okay, this seems to be okay with the people who have commented so far. Andreas
