(replying by email to guix-devel, as this allows me to arbitrarily
quote)
On the question of teams:
Am Wed, Mar 11, 2026 at 12:01:41PM +0100 schrieb gabber:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +Additionally, the team `deprecation` will be created on Codeberg to
>
> I don't think dubbing this "informal group" a "team" is very wise.
> Is it necessary to (ab-)use the teams.scm file and/or CODEOWNERS mechanism for
> people to notice when there are new removal candidates?
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +which interested parties can subscribe (for instance, one participant per
> +interested downstream channel), and the issue body should reference the
> +team so that their members get notified of the issue. The team is not a
> +Guix team in the sense that their members obtain voting rights for GCDs or
>
> I think it is a mistake to overload the team terminology within Guix. I see
> that it makes sense for interested parties to get notified via this label. Is
> there another way that people can subscribe to this label without the
> teams.scm
> / CODEOWNERS way?
I agree this is unfortunate, and your misunderstanding above confirms
this. As the text says, "is not a Guix team". So this is NOT a team that
would be mentioned in teams.scm and be related to files in CODEOWNERS.
The problem is that Codeberg also uses the notion of a team, which is
just a group of people that can be referenced/notified by @guix/xyz, for
instance. So that is why I wrote "team (...) on Codeberg"; it is really
Codeberg that overloads the team terminology. (And for our existing code
related teams, we have the two coincide, but this is a behind-the-scenes
additional action on Codeberg.)
If you have a good suggestion for clarifying this, I would be happy to
apply it, since I do not see any myself.
On the question of durations/delays:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +We follow the same removal process as above, but the initial removal
> +notification is prolonged from one week to three weeks.
>
> Why?
>
> IMO we could omit this paragraph (or include it in the previous one) since
> (working) "libraries" as you dub them will remain available through
> time-machine---or am i missing something here?
Here I have preemptively integrated a compromise on the delays,
as witnessed by this:
Am Wed, Mar 11, 2026 at 10:17:01PM +0100 schrieb civodul:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +So altogether, this leaves (at least) two weeks between filing a removal
> +issue and the actual removal, which leaves enough time to channel
> +administrators to react accordingly.
>
> This looks like a short time frame to me. It's probably common for people to
> upgrade once per month at best, or once every few months. If I read correctly,
> that leaves enough time for a package to break and be removed entirely.
Personally, I would like to shorten the procedure as much as possible,
to have a short as possible time where things are broken. (But this is
my perspective of someone removing things.) Others may prefer to keep
things for longer. So I have used a total time of two weeks where things
are broken and thus very disturbing for packagers, and a total time of
four weeks in less annoying cases as a compromise.
This is certainly an important point to discuss, and something where
consensus must be reached. I could live with anything that does not
lengthen the current delays, that is, keeps it possible to remove
packages within one month.
But nevertheless let me argument for the shorter timeframe of two weeks:
- During 4 weeks with about 50 packages on the removal list at all
times, I tend to forget the list. It has happened to me that I have
reexamined a broken package that was already on the list, and I have
almost filed a second removal request.
- In my experience, people react to removal requests in possibly two ways:
- Either in the days that follow, sometimes on the same day (where a
reaction can be as simple as "I like the package and will work on a
PR to repair it", which is enough to stop the removal process).
- Or after one month, immediately after the removal.
So essentially with the current rules, in weeks 2 to 4 after the
removal request nothing happens, and everybody just waits (there are
exceptions, but they are rare). I think we may as well drop these
weeks.
Am Wed, Mar 11, 2026 at 12:01:41PM +0100 schrieb gabber:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +at any time, provided that the old name is made available through the
> +statement `(define-deprecated-package old-package new-package)`.
> +The old name must remain available for one year, and to ease its removal
> +after the year, the deprecation date should be stated in a comment next
>
> I may not know a good example for this. Why is it a year? Isn't that very
> long?
> I am also unsure about adding date tags in comments into our source code
A year is quite long, but simply what the manual currently prescribes.
Personally I would be happy with a shorter delay, maybe 6 months.
Concerning comments in the code, what is the problem? It makes it easier
to remove the deprecation without having to use "git blame" to determine
the commit that added the deprecation. I see it as very similar to
"FIXME" or "TODO: Unbundle libxyz" comments.
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> In 006-package-deprecation.md:
> +## Package additions
>
> I don't understand what this paragraph has to do with the deprecation policy.
> Are you implying that we should not have/use/keep legacy software?
This is a bit of an afterthought to deprecation. Currently we do not
have any guardrails on package addition, and we may be a bit too lenient
with additions. (So it is about "adding", not "keeping".)
I noticed that some removal requests I file are for packages that were
added as a "drive-by", one-off contribution, then sometimes refreshed
by committers who (probably) are not using the package after the
original contributor has left for a long time.
And recently we have seen pull requests for package additions that
correspond to packages that could immediately become removal candidates,
for instance because they were clearly abandoned upstream.
The proposed paragraph is a (not very strongly worded) caveat to be careful
with package additions, that gives a reason to point to when committers
reject package additions.
For instance, we would not want to add new packages depending on Python 2
or Qt5 (or worse even, once these libraries have been removed, that add
such a package *together with* reinstating Python 2 or Qt5).
Concerning other points, I need to think about them and will reply
later.
Andreas
