V Thu, Feb 12, 2026 at 09:57:25AM +0100, Vít Ondruch napsal(a):
> 
> Dne 11. 02. 26 v 18:07 Petr Pisar napsal(a):
> > V Wed, Feb 11, 2026 at 05:48:52PM +0100, Vít Ondruch napsal(a):
> > > How about policy:
> > > 
> > > "When there is the-new-hotness ticket in Bugzilla unresolved for more 
> > > then N
> > > releases, orphan the package"
> > > 
> > > Although, if only maintainer is allowed to enable the monitoring, that 
> > > might
> > > not work. But I think we should also consider to have the monitoring 
> > > enabled
> > > for all components.
> > > 
> > What about components which cannot be upgraded (not allowed license,
> > unmet dependencies)?
> 
> 
> The "unresolved" is ambiguous, right. Maybe it could be "without activity of
> maintainers". There can also be other way to track some exceptions.
> 
> 
> > What about component whose upstream versioning is
> > incomprehensive for the-new-hotness?
> 
> 
> I don't have answer here. Neither I know how widespread issue this might be.
> 
> 
> > 
> > Or did you mean just one-time enablement, with a default on and keep
> > a permission for disabling it to the maintainer?
> 
> 
> I thought more about the opposite way. If I suspect there is component which
> is not properly maintained, there would be a way to enable the-new-hotness,
> which would request the update in consistent way (mainly for easy
> automation). Of course if the monitoring is enabled already, then there is
> likely such ticket. If there was not activity in the ticket from maintainers
> for N releases, the package would be orphaned.
> 
> And of course, there might not be upstream updates available, but I'd
> consider this different case.
> 
I wrote my reply with an idea that maintainers who find the-new-hotness not
helpful for them will tend to disable it instead of closing new and new
tickets.

-- Petr

Attachment: signature.asc
Description: PGP signature

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to