all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	guix-devel <guix-devel@gnu.org>
Subject: Re: Merging the purge-python2-packages branch
Date: Wed, 01 Jun 2022 21:51:57 +0200	[thread overview]
Message-ID: <86zgiwi2le.fsf@gmail.com> (raw)
In-Reply-To: <87y1yguzfn.fsf@gnu.org>

Hi,

On Wed, 01 Jun 2022 at 18:21, Ludovic Courtès <ludo@gnu.org> wrote:

> The question boils down to: how can we maintain a general-purpose
> package collection?

I agree and I never said that we have to maintain packages EOL since 2
years.

As I pointed, many packages of these set are not broken… yet.

Any user of Guix, scientist or not, can be surprised that their
perfectly working packages are suddenly removed without a period of
grace.  Yes, these packages could have been removed before today since
they are EOL since 2 years.  It does not change my concern.

What is the emergency in the maintenance burden that we cannot publicly
announce the purge and wait a grace* period?  For the broken packages, I
understand.  I am sorry but I am still missing for the perfectly working
packages.

Again, I agree with the purge, I disagree with the process.

*grace period: it could have been short as couple of weeks.


> It’s great that you’re voicing the concerns of the scientific community.
> At the end of the day though, someone has to maintain all this code.
> We’re removing packages from Guix proper, letting interested users
> either pin their software environment or maintain those packages in a
> channel of their own.  In the latter case, the maintenance burden is
> transferred.

My concern is mainly about the process, not the purge.  As you can read
in the Git log, I have removed many broken Python 2 packages.  And as
you can also read in the mailing list archive, I have been concerned by
this topic and I tried to propose (many times) a plan for a smooth
transition because package removals.

Maybe I am wrong but I see a difference in a transition plan between
collectively maintain all this code for 2 years and remove many working
packages without a public announce.

I agree with the purge and it is nice that it happens.  But I am
surprised by the abrupt process.  A grace period could have smoothed the
transition for the few interested users, if any. :-)

Maybe my ideal world is wrong, but to me, the collective process would
have somehow been on Guix side: patches, branch and CI, announce on
guix-devel, announce on info-guix and publish a blog post (because the
script is unique, awesome and really worth), then done.  In my ideal
world, we were at the announce on guix-devel step.  Hence my surprise.


> The transition can be difficult; surely, some user out there will
> discover all of a sudden that their favorite package disappeared.  As
> engineers who support scientific users, you and I (and others) can help
> smooth that by pasting package definitions that we know are still used
> into Guix-Past or some other channels.

It is a bit more than pasting; whatever. :-)

It is really interesting: so much care about “guix environment” to avoid
any breakage of any workflow vs a massive purge without even an announce
on guix-devel: be aware, many Python 2 will be dropped on <date>.
Anyway.

As I said, I am surprised.  But the world is not exploding. :-) Come on,
it is Python 2 EOL since 2 years!

Even, I am very grateful that this boring janitor task of purging is
almost done.  Many thanks to Maxim for the hard and not fun work!

The script and various tools around are really great materials exposing
how Guix is powerful.  Awesome and thanks!


> In the end, it can have a good side effect: getting scientists aware of,
> and ideally involved in, the maintenance of their own infrastructure.
> Maybe you have an argument to recruit an new engineer on your team?  :-)

Too much optimism? :-)

To be honest, I get two kind of feedback:

 1. from scientists end-user, a) they do not have the packages they need
 when these packages are easily available elsewhere, b) many tiny
 annoyances which do not make daily usage smooth compared to others;

 2. from “sysadmin”, Guix is not enough stable and not ready for production.

Both are not technical but are most about perception. I will not drift
off topic. ;-)

About “my team”, do you mean recruit myself?  Even, I am probably the
only potential recruit in my complete Institute. ;-)


Bah yeah optimism!  I am surprised and surprised are often fun! :-)


Cheers,
simon


  reply	other threads:[~2022-06-01 19:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-30 13:25 Merging the purge-python2-packages branch Maxim Cournoyer
2022-05-30 15:18 ` zimoun
2022-05-30 15:32   ` Maxim Cournoyer
2022-05-30 16:49     ` zimoun
2022-05-31  7:39       ` Reza Housseini
2022-05-31 19:07       ` Maxim Cournoyer
2022-05-31 20:54         ` zimoun
2022-06-01 16:21           ` Ludovic Courtès
2022-06-01 19:51             ` zimoun [this message]
2022-06-01 20:30               ` Maxime Devos
2022-06-02  7:25                 ` zimoun
2022-06-02  9:36                   ` Maxime Devos
2022-06-02 14:04               ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86zgiwi2le.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.