On Fri, Dec 26, 2025 at 06:43:30PM +0200, Sharlatan Hellseher wrote:
> I hope to boost some coordination between related channel, > I also may be useful to attract some attention when help to fix > is wanted. I started commenting and then saw that this is your goal. My belief if that we don't deprecate 'broken' packages fast enough. I would like to make it easy to deprecate packages AND provide clear guidance on when to do so. > I know there is some documented practice s, but I feel we missing some > formalism and templates when the deprecation issue is open. The main formulism I think is missing is clear guidance on when a package can be deprecated. It would be great to have simple, clear guidance that could be put into an Issue template. Such as: - Package has security issue that hasn't been resolved upstream for greater than 3 months - Package doesn't build on primary architectures ... > > Would it be any interest among community to have something like > this as proper GCD? > > - an agreed template for package deprecation issue > > Title: Remove <package-name>@<version>: Breaf reasoning. > Body: > More detailed reasoning > Guix git history of the package updates > Any open upstream issues > Any alternative if there is any > List of other channels informed about depression > Attached full build log (...) I think I disagree with this because it's making it more onerous. Can you give a rationale for why each one is needed? I can see the value of the 'detailed reasoning' and referencing any upstream issue. I could probably get behind adding the failed build log so there's an archive. I'm not sure why a git history is needed, or why I have to research alternatives (that's for someone who's adding an alternative). > - agreed list of the channels to be informed (guix-science, guix-past, ...) > Again, this all seems like 'work' when more friction is not really in our interests given how much work there already is ... Presumably, I would have to install guix-science and check if this package has a dependent there and then I have to open an issue etc. At the moment we should deprecate with the macro and open an issue, surely someone maintaining the their channel can be expected to pick this up over the 3 month window? Maybe opening an issue on guix-past is useful so that someone could pick up the package if they cared. > - document when to add : -next, -bootstrap, -minimal, or apply graft > and when/how to remove them > Is this part of the same thing? I would be interested in some general advice as I don't know the rules/thoughts here either. Steve / Futurile
