Op 07-09-2023 om 13:32 schreef Simon Tournier:
Hi, On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer <[email protected]> wrote:It's frustrating for users when a package is missing, but it's also frustrating/inefficient for maintainers to stumble upon broken packages when checking if an upgrade broke dependent packages (it takes time to build them just to find out they fail, and researching they already did), so a balance is needed.There is nothing worse as an user to have this experience: guix search foobar oh cool, foobar is there, let try it, guix shell foobar … wait … … stuff are building … … laptop is burning … … wait … Bang! Keeping broken packages is just annoyances. Contributor are annoyed because as said by the paragraph above. And user are annoyed as described just above.
>
I am in favor to set a policy for removing then.
You don't need to keep broken packages, they can be fixed instead. Although given later e-mails, I suppose that this hypothetical policy for removing them would contain things about fixing them instead.
It's this focus on 'broken -> delete' that bothers me, why is the first reaction ‘delete them’, not ‘fix them’?
Op 11-09-2023 om 16:00 schreef Simon Tournier:If you care about one package that is marked to be removed soon, then you fix it or raise your concern. Else it means no one care and so what is the point to keep broken packages that no one uses?
It doesn't mean that. As I wrote previously:
[...] No, it doesn't mean that that the package is not used much, it could instead mean that the people using the package (or interested in using the package, if it was already broken when they discovered it) thought that the existence of ci.guix.gnu.org means that contributors doing Guix maintenance already know that the package is broken and assumed that it would be fixed, and that a new bug report would just be annoying the contributors because they already have a bug report: the build failure on ci.guix.gnu.org.We could bump the expiry time to 180 days, or even 365 days (a full year). If nobody opens an issue for a broken package in that amount of time, it's probably not used much if at all and may not be worth the maintenance burden.
---
> The more important question is (serious question and *not* for
> assigning blame, but to see whether we can improve processes): with
> the time we already spent in this discussion, we could have fixed a
> lot of packages. Why did we not do that?
Speaking only for myself:
* (because I chose to mostly not work on Guix anymore for reasons that
aren't relevant to this discussion)
* if I were to fix broken packages, I would like others to avoid
creating new breakage (and if breakage occurs, then fix it it
early). (Otherwise, not much point to it ...)
Hence, there needs be some discussion to ensure that other people
don't do that new breakage in the future.
* hearing ‘delete it’ as first reaction to ‘broken package’ is rather
demoralising to people fixing packages. It's so ... defeatist.
Sure people with this reaction add a few qualifiers to when it is
to _not_ be removed, but it sounds rather hollow.
Instead of having a ‘removal policy’ that lays down exceptions that
indicate when the package should instead be kept, I would rather have a
‘fixing policy’ that has exceptions indicating when the package may
instead be removed.
In a sense, those are technically equivalent, but the different framing makes a difference in motivation.
Best regards, Maxime Devos.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
