Question on the process of packge withdrawal

Question on the process of packge withdrawal

[Sharlatan Hellseher]

Hi Guix!

  I've noticed a tendency in core-updates and staging of withdrawing old
  packages, packages which were created from forks in the past or
  packages failing to build due to increased complexity of the package.

  If we check
  <https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=409ce1d939bc3b100e5965d2b4e17cb1f93bcac7>
  commit removing jrnl variable which has it's source pointing to
  <https://github.com/maebert/jrnl> which is an old fork of original
  active project <https://github.com/jrnl-org/jrnl>.

  Other example
  <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ba17b160ed7d09ef58183c22b6f1b10ee7ba926d>
  the reason it's not updated at <http://www.catb.org/~esr/> -
  development was moved to <https://gitlab.com/esr/reposurgeon>.

  That tendency concerns me as a packager it's not clear for me which
  criterias were used to make a division to withdraw the package(s). The
  age of project is not always a good measure for example example,
  [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
  touched since the last commit) but still in active use (check
  [pgloader])

  It's an open discussion to drag some attention to this case and
  compile some common seance checklist before removing package from Guix
  ecosystem. From my experience it's sometimes hard to have new package
  to be included :).

  Thanks, Oleg

--
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Question on the process of packge withdrawal

[Maxim Cournoyer]

Hi,

Sharlatan Hellseher <sharlatanus@gmail.com> writes:

[...]

>   Other example
>   <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ba17b160ed7d09ef58183c22b6f1b10ee7ba926d>
>   the reason it's not updated at <http://www.catb.org/~esr/> -
>   development was moved to <https://gitlab.com/esr/reposurgeon>.

The reason this one was removed was that it had not built since 2018,
and nobody offered to do the work to package the missing Go things to
update it.  It was discussed in the associated bug [0].

[0]  https://issues.guix.gnu.org/33614

>   That tendency concerns me as a packager it's not clear for me which
>   criterias were used to make a division to withdraw the package(s). The
>   age of project is not always a good measure for example example,
>   [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
>   touched since the last commit) but still in active use (check
>   [pgloader])
>
>   It's an open discussion to drag some attention to this case and
>   compile some common seance checklist before removing package from Guix
>   ecosystem. From my experience it's sometimes hard to have new package
>   to be included :).

I think packages removal should go to the patch tracker, with a CC to
guix-devel to give more visibility to let time for all parties to
comment or find a solution (perhaps a maintained fork exists, etc.)

-- 
Thanks,
Maxim

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Mon, Feb 27, 2023, at 12:12, Maxim Cournoyer wrote:
> I think packages removal should go to the patch tracker, with a CC to
> guix-devel to give more visibility to let time for all parties to
> comment or find a solution (perhaps a maintained fork exists, etc.)

I agree that removal should go through the patch tracker. However, for a case like this one, I don't think there's any reason to wait very long before pushing

From the users' point of view, the package is effectively already gone, because it does not build. 

It's confusing and frustrating for the list of available packages in the UI to include broken packages, so I suggest that speedy removal is best.

Re: Question on the process of packge withdrawal

[Simon Tournier]

Hi,

On dim., 26 févr. 2023 at 20:11, Sharlatan Hellseher <sharlatanus@gmail.com> wrote:

>   Other example
>   <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ba17b160ed7d09ef58183c22b6f1b10ee7ba926d>
>   the reason it's not updated at <http://www.catb.org/~esr/> -
>   development was moved to <https://gitlab.com/esr/reposurgeon>.

I proposed to remove the package because it was broken and no one was
willing to fix it.  What is the point to keep broken packages?

Here, the timeline:

Report broken:    4 Dec 2018 (4 years, 12 weeks, 1 day ago)
Try update:      13 Jul 2022 (32 weeks, 5 days, 20 hours ago)
Propose removal: 17 Oct 2022 (19 weeks, 14 hours, 57 seconds ago)
Send patch:      21 Jan 2023 (5 weeks, 2 days, 18 hours ago)
Commit patch:    21 Jan 2023

Well, the two “improvements“ here could be, IMHO:

 a) send patch to guix-patches instead of the bug report itself,
 b) wait some days between send and commit.


>   That tendency concerns me as a packager it's not clear for me which
>   criterias were used to make a division to withdraw the package(s). The
>   age of project is not always a good measure for example example,
>   [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
>   touched since the last commit) but still in active use (check
>   [pgloader])

From my point of view, the first rule is if the package still builds or
not.  If the package is broken, let try to fix and if it is not possible
because unmaintained or else, then let drop it.

The second rule is if the package is a leaf or not.  More dependants the
package has and more effort should be put in fixing it, IMHO.

The third rule is about security.  From my point of view, old packages
with known vulnerabilities are not appealing for working on fixing it.

Else, if the package still builds, I do not see why it would be removed.
Old unmaintained (or barely maintained) packages* are very common in
scientific context and they just still works very well. :-)

*as linear algebra libraries wrote long time ago using good ol’
 Fortran. ;-)  Still the state of art.


Cheers,
simon

Re: Question on the process of packge withdrawal

[Andreas Enge]

Hello,

Am Sun, Feb 26, 2023 at 08:11:52PM +0000 schrieb Sharlatan Hellseher:
>   If we check
>   <https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=409ce1d939bc3b100e5965d2b4e17cb1f93bcac7>
>   commit removing jrnl variable which has it's source pointing to
>   <https://github.com/maebert/jrnl> which is an old fork of original
>   active project <https://github.com/jrnl-org/jrnl>.

the reason is in the commit message:
    The last release of the package dates from 2019.
    It depends on the cryptography library python-pycrypto, which has had
    its last release in 2013 and "is unmaintained, obsolete, and contains
    security vulnerabilities" according to its homepage.

The github repository says
   This branch is 811 commits ahead, 1580 commits behind jrnl-org:develop
Difficult to know what is the good version... (We were two to think the
projet was dead upstream.)

I am happy to put it back in (the cryto apparently comes from
python-cryptography now). However, the previous version 1.9.7 was from 2014,
there was a version 2.0 in 2019, and the current version is 3.3.
Is there sufficient compatibility to "upgrade" (by reverting the removal
commit and updating as usual)? Or should it be treated like a new package?
Have you used the 1.9.7 package recently? Has anybody used it recently?
Otherwise I would be enclined to leave it out until someone wishes to put
it in again as a "new" package. Updating packages that noone is interested
in is an unnecessary drag on volunteers' time.


Concerning the process, I think we should have one :)
It would be nice to document the process in the manual.
This should differentiate between the different reasons for removal:
security problems, not building, etc.

Andreas

Re: Question on the process of packge withdrawal

[bokr]

Hi,

On +2023-02-28 11:30:21 +0100, Simon Tournier wrote:
> 
> I proposed to remove the package because it was broken and no one was
> willing to fix it.  What is the point to keep broken packages?
>

What is the purpose of a junk-yard for broken cars?

I think there is some use :) I kept an old VW going many decades
by more than once in my youth going with tools to a junk yard
where the deal was:
      Find what you need in some wreck, detach it with your own tools,
      bring it to the office, and negotiate a price.
      (the office guy could usually point you to the likely wrecks
      if you described what you needed, and would even offer to rent you
      some tools and help, all negotiable :)

IMO, it's a matter of storing the junk where it will not be a toxic liability
and nuisance, yet easily discovered by someone looking for "parts."

Software "parts" are a little different, but the R&R (remove & replace)
aspect seems similar ;-)

And it should be easy to keep an inventory of junk-yard contents by bug numbers.
Maybe somone would enjoy curating "junk" :)

Disclaimer: I am a terrible pack-rat ;/
(with no time to be junk curator, though I appreciate their work, along with
any{one,thing} helping me find what I want (rather than the other way around) :)

[...]
> Cheers,
> simon
> 
--
Regards,
Bengt Richter

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Tue, Feb 28, 2023 at 03:57:33PM +0100, Andreas Enge wrote:
> Updating packages that noone is interested in is an unnecessary drag
> on volunteers' time.

This is the key point, in my opinion.

Those who wanted to use this package were very welcome to do something
about it. And they are still welcome to contribute a working package.
They will even receive help and advice on IRC and the mailing lists :)
But they must lead the effort.

This whole conversation seems contrived because, clearly, nobody was
using jrnl in Guix, since it was broken for 4(!) years.

Guix is a distro for using programs. Not a graveyard, a junkyard, or a
collection of historical artifacts.

Re: Question on the process of packge withdrawal

[Simon Tournier]

Hi,

On Tue, 28 Feb 2023 at 17:26, <bokr@bokr.com> wrote:

> IMO, it's a matter of storing the junk where it will not be a toxic liability
> and nuisance, yet easily discovered by someone looking for "parts."

Well, I will not call that "junk". :-)

IMHO, this is discoverable since it is part of the Git history of
Guix.  The Git history of Guix also acts as an inventory.

Cheers,
simon

Re: Question on the process of packge withdrawal

[Bengt Richter]

On +2023-02-28 18:16:18 +0100, Simon Tournier wrote:
> Hi,
> 
> On Tue, 28 Feb 2023 at 17:26, <bokr@bokr.com> wrote:
> 
> > IMO, it's a matter of storing the junk where it will not be a toxic liability
> > and nuisance, yet easily discovered by someone looking for "parts."
> 
> Well, I will not call that "junk". :-)
>

Me neither. That's what I meant to say with my
wrecked-cars-as-broken-packages anecdotal metaphor:
broken ≠ worthless :)

> IMHO, this is discoverable since it is part of the Git history of
> Guix.  The Git history of Guix also acts as an inventory.
>

I agree, the git history probably has everything in it, but for me
discovery is not so easy.

I think I need a map like openstreetmap, that on a high level could
show a map of software component boundaries instead of city plots,
and alternate views showing e.g. dependencies as roads between
warehouses/packages.

Obviously, related collections of things would cluster on map representations,
and interaction could pop up synopses and descriptions and urls etc -- like
what happens finding your way to the right bar in Brussels ;-)

How about a street-view drive along thread executions from power on
to login? Zoom in for detail data from dmesg or sytemctl -b or straces?

How about a drive into gnome-control-center?
With trip-planning how to get there and back from various contexts,
showing zoomable detail from high level widget thumbnails or
down to the lowest gdb run step.

Well QGIS is free/libre UIAM, but it is BIG.
And BIG means a LOT to trust, and that worries me.

Maybe good software maps could make reviewing and verifying easier,
until it's all automated. But how can we verify the automation?
(isn't there an old Latin saying about guarding guard dogs :)

I am not sure how the database of software maps would have to be
represented. What would be analogous to satellite photography and automatic
vectorization of roads and river boundaries etc.?

Actually, maybe a game engine would be better than GIS.
Super Bughunter Tomb Raider avatars ;-)
Yeah, that sounds like more fun. VRML?

Well, that's a big fantasy about "discovery" :)

Hm, how to get that running as native RISC-V code on open silicon? ;-)

> Cheers,
> simon
--
Regards,
Bengt Richter