Hello,

Am Fri, Dec 26, 2025 at 06:43:30PM +0200 schrieb Sharlatan Hellseher:
> This topic occupied me for a while.
> I know there is some documented practice s, but I feel we missing some
> formalism and templates when the deprecation issue is open.
> Would it be any interest among community to have something like
> this as proper GCD?

thanks for the initiative! Of course I am interested in taking part and
sponsoring a GCD. Package removal is necessary to keep a healthy
software distribution, but of course creates a bit of friction. The
current practices are not fully documented, since we have implemented an
informal workflow on Codeberg; it will be good to have a discussion on
what works well and what can be improved in which direction. As a warning,
I think we should make package removal easier, which may not be a
mainstream opinion :)  But I hope that with a bit of discussion and
keeping the common goal of a healthy, buildable and up to date
distribution in mind, we will arrive at a consensus.

I think that the different cases of package removal could also be
discussed in more detail, potentially with different policies:
- package not building for a while (even immediate removal would not
  change the status quo);
- package building, but not working as expected (essentially the same
  situation, but maybe easier to fix?);
- package building, but "in the way" for other migrations (such as,
  depending on Python 2 or Qt 5, which we want to drop; depending on one
  of the older versions of helper packages; this requires a bit more
  definition);
- package building and working, but still dead upstream (we probably
  will want to keep it).

How about also including guidelines for package addition, such as not
adding packages that could immediately become a removal candidate?
Or that build and work (last case above), but are dead upstream, and
thus likely to become a liability in the future?

Andreas


Reply via email to