bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)

[Maxime Devos]

> [...]
> Maxime Devos<maximedevos@telenet.be>  writes:
>
> > > > The first part looks reasonable to me (though I would decrease 7 days
> > > > to daily or even hourly, as I don't see a point in the delay), but how
> > > > does the second part (removing packages) make sense at all?
> > > > I mean, if you do that:
> > > >    1. Build failures happen (independent of whether you do that).
> > > >    2. Hence, by doing that, the distro shrinks over time.
> > > >    3. Leading to frustrated users(*), because the packages they were
> > > >    using and which were working well were suddenly removed for no good
> > > >    reason (**).
> > > >    4. Leading to less people fixing build failures (because of the
> > > >    frustration).
> > > 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.
> > Please read the subject line of the original message, subject lines
> > aren't just fluff.
> Believe it or not, I actually did! :-) I was replying to the first part
> of your message, where you mentioned you were against packages removal.
> My reply was giving support to devising policy that would define when
> it's acceptable to prune the distribution of broken/unmaintained
> packages, which is tangentially related to the topic of reporting broken
> packages.  These are just ideas and if we decide to turn some of them
> into policy we could write it in a way that would favor resolving
> problems instead of just making them disappear.

OK sounds good.

> [...]
>
> > If maintainers check that no new build failures are created, then over
> > time the total amount of old build failures becomes roughly zero
> > (roughly, because of occasional mistake and new timebombs).
> You mean that the building vs failing ratio improves, right?

That too, but in relation to what I replied to, I meant what I wrote, 
which is a stronger statement.

> I'm all
> for giving a best effort to keep as many packages as we have the
> capacity to do, but at some point the Pareto principle kicks in and you
> realize there's not that much value in spending 3 days trying to fix a
> hardly maintained leaf package that has been failing to build for a year
> or two.
>
> [...]

The point is that this situation wouldn't happen if build failures were 
addressed soon after their introduction.

If it is noticed that Guix has exceeded its capacity to maintain its 
packages and needs to trim its package set to maintain the remaining 
packages effectively, then while that's unfortunate and possibly 
frustrating to users, I don't have any better option available, but the 
original (^) proposal did not have this ‘if capacity is exceeded’ 
qualifier attached.

(^) In a new e-mail, 宋文武 has amended it a bit.

(It fails the ‘distro ≃ reliable packages’ property since packages were 
removed, but with this approach, it could be a one-time intervention 
with a promise to in the future try to stay within capacity, and future 
package removals could have a nuanced deprecation policy that avoids 
making the packages unreliable(*).)

(*) I was searching for whatever Debian's package removal policy is (as 
an example to base things on), but I only found "apt-get remove" etc.. 
Actually I don't know if Debian has one, but probably I'm just looking 
in the wrong places.

It's important _how_ it is trimmed.  In the original proposal by 宋文武, 
packages are simply removed for failing to build -- there were no 
regards to how difficult it would be to fix the build failure, how 
popular the package is (or would be if it built and people knew about 
it), how useful it is, etc..

On that matter, I think it would be useful to set up a variant of 
something like Debian's popcon, in order to have actual statistics on 
what's popular (sure statistics would be flawed, but I'd think it's easy 
to do better than ‘package fails to build -> unpopular’).  I say 
variant, such that it could also count packages that aren't actually 
installed because they failed to build.  (Maybe have separate ‘desired’ 
and ‘used’ manifests?)

> > (*) Sometimes upstream is really not with the times instead of
> > slightly out of touch, sometimes the broken package has a good
> > replacement and often security updates need to be performed before
> > they existed, but the ‘remove packages’ proposal is not limited to
> > such exceptions.
> This is the kind of considerations that we could mention in a package
> removal policy (basically mention it's a last resort thing).

If there is an actual nuanced package removal policy instead of ‘fails 
to build -> remove it’, my objection pretty much goes away.

>> [...]
> The text of yours I quoted was to provide some context as to what I was
> answering to; I replied to the essence of your argument I synthesized
> from it, not point by point as I agreed with it and it wouldn't have
> added much to do so.

OK, but I don't share your optimism -- while I would (mostly) agree that 
_currently_ most contributors are acting in good faith etc., I would say 
that after the proposed change the frequency of such contributors could 
easily decrease, because:

  * the proposal has no actual ‘acting in good faith etc.’ clause, so
    it's quite vulnerable to rules-lawyering.  I mean, look at
    difference between how I interpreted the proposal and between what
    宋文武 actually wrote -- in retrospect I read too much in it and I
    didn't even try to rules-lawyer.

  * there is (indirectly) an incentive for breaking packages, because
    the motivation for changing a package and the motivation for fixing
    the consequences of that change are different.  (Whether
    motivation change <, = or > motivation fixing consequences depends.)

  * there is little to no incentive for fixing packages you aren't
    personally interested in

Maybe things would work out and people in it for self-interest also are 
in do enlightened self-interest ... (I don't know which way things would 
go.)

> > It's something I have encountered and pointed out (less explicitly) in
> > the past in other threads as well.
> I think it's a common reaction when faced with a detailed text -- some
> people may simply ignore it, feeling overwhelmed, or they may synthesize
> the essence of it to keep it high level and the discussion more fluid.
> I don't think it should be perceived as mean; a partial reply is still
> better than none.

k, but I'm ignoring the 'common' part -- common does not imply good.

Best regards,
Maxime Devos

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature