Re: Dealing with upstream issues

[Maxime Devos]

zimoun schreef op ma 27-06-2022 om 14:53 [+0200]:
> Maybe I misunderstand the point.  To me, the aim of the package
> submission is the inclusion in Guix.  AFAIK, the Guix project is not
> applying any standard audit on the upstream code before inclusion.
> 
> Therefore, if the upstream code is poor in some areas, then it is not
> blocking for the package adoption in Guix…

I think there should be some degree of standards (where I mean
standards in the non-shodyness sense of the word, not in the sense of
specs, though specs would be nice too) and of audit (bundling, malware,
non-free, bugs) -- some of which are blocking (bundling, malware, non-
free, some bugs), some of which aren't (some other bugs).

E.g., see removal of unmaintained Python, of some old SSL libraries

>>> However, AFAICT, none of that has happened yet.
> …and such adoption does not mean the upstream quality cannot be
> improved, by reporting or add a patch.

The problem is that this sometimes seems to be neglected unless people
are practically forced to make the issue be reported upstream.

> > My view is that such issues should be reported upstream but cannot
> alone
> > block package adoption in Guix.
> 
> I agree; we cannot fix the world. ;-) In the case of patch#55541, the
> issues of cross-compilation can be reported directly to upstream

Agreed -- I did not ask that explicitely in #55541, but the implied
question was to report it upstream (or fix local, that could be done
too).  But my point is that this should have been done _before_ merging
the patch.

> and another Debbugs number could be open.

Would be pointless.  Standard policy seems to be to leave the debbugs
issue unresolved forever, then someone does some cleanup in debbugs to
close the debbugs number due to lack of activity or such.  Things would
be delayed forever.

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part