Input welcome on the proposed deprecation policy

Input welcome on the proposed deprecation policy

[Ludovic Courtès]

Hello Guix,

I realize I did not advertise the “Deprecation Policy” proposal here,
which is a mistake because it’s relevant to all of us as developers and
packagers, and it’s also a key element of our relation with the broader
user base.

So please, consider reading the proposal and joining the discussion:

  https://issues.guix.gnu.org/72840

Apologies for not mentioning it earlier!

Ludo’.

[bug#72840] [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> I realize I did not advertise the “Deprecation Policy” proposal here,
> which is a mistake because it’s relevant to all of us as developers and
> packagers, and it’s also a key element of our relation with the broader
> user base.
>
> So please, consider reading the proposal and joining the discussion:
>
>   https://issues.guix.gnu.org/72840

Thanks, looks good to me!  As a side remark: It would be nice if
upgrading of config.scm / home.scm could be automated.

Anyway, I do have a vaguely related question.  The Dezyne package comes
with a `guix.scm' that uses a package description in
guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'.

Recently, %gnu-build-system-modules was deprecated in

--8<---------------cut here---------------start------------->8---
28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.

9e4ce281dbd92e3c52b831824ebb1f77023c960c
build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.
--8<---------------cut here---------------end--------------->8---

Although the `guix.scm' has a comment like

--8<---------------cut here---------------start------------->8---
;; To use the canonical commit that has everything prebuilt:
;;
;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
--8<---------------cut here---------------end--------------->8---

documenting a commit that can be used for building the package and has
substitutes available, usage of the commit is not enforced.  After a
recent `guix pull', we now get this warning

--8<---------------cut here---------------start------------->8---
pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
--8<---------------cut here---------------end--------------->8---

and I'm wondering what the best moment would be to change the package
description.  Upgrading sooner (i.e., now) means that a future guix that
has this deprecated feature removed will be able to build more
hystorical releases of the package simply by doing `guix shell', so
that's probably the best choice?  It would mean that all developers have
to upgrade now (or use the time machine).

Of course, we can always(?) build hystorical release by doing

    $(grep -o 'guix time.*' guix.scm)

but you'd have to know about that and it probably only works for the
Dezyne package.  Is there a better way or should something like this be
advertised/recommended in the documentation?

Greetings
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#72840] [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

[Ludovic Courtès]

Hi Janneke,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>>   https://issues.guix.gnu.org/72840
>
> Thanks, looks good to me!  As a side remark: It would be nice if
> upgrading of config.scm / home.scm could be automated.

It would be great, indeed.

> Anyway, I do have a vaguely related question.  The Dezyne package comes
> with a `guix.scm' that uses a package description in
> guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'.
>
> Recently, %gnu-build-system-modules was deprecated in
>
> 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
> build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.
>
> 9e4ce281dbd92e3c52b831824ebb1f77023c960c
> build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.

I’m not convinced this was a worthwhile change BTW, looking at the
intended clarity improvement vs. cost ratio.

> Although the `guix.scm' has a comment like
>
> ;; To use the canonical commit that has everything prebuilt:
> ;;
> ;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
>
>
> documenting a commit that can be used for building the package and has
> substitutes available, usage of the commit is not enforced.  After a
> recent `guix pull', we now get this warning
>
> pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
>
> and I'm wondering what the best moment would be to change the package
> description.  Upgrading sooner (i.e., now) means that a future guix that
> has this deprecated feature removed will be able to build more
> hystorical releases of the package simply by doing `guix shell', so
> that's probably the best choice?  It would mean that all developers have
> to upgrade now (or use the time machine).

Yeah, that’s always a difficult choice, and I don’t have a good answer.
What’s sure is that the deprecated name will remain available for a
relatively long time, so there’s no urgency at this point.

> but you'd have to know about that and it probably only works for the
> Dezyne package.  Is there a better way or should something like this be
> advertised/recommended in the documentation?

I’m not sure we could recommend one approach that would work for
everyone because it really depends on the use case (for instance whether
building with an older Guix is important for your project.  But at
least, by setting expectations, the deprecation policy lets users making
informed decisions.

Ludo’.

Re: [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

[Ludovic Courtès]

Hi Janneke,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>>   https://issues.guix.gnu.org/72840
>
> Thanks, looks good to me!  As a side remark: It would be nice if
> upgrading of config.scm / home.scm could be automated.

It would be great, indeed.

> Anyway, I do have a vaguely related question.  The Dezyne package comes
> with a `guix.scm' that uses a package description in
> guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'.
>
> Recently, %gnu-build-system-modules was deprecated in
>
> 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
> build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.
>
> 9e4ce281dbd92e3c52b831824ebb1f77023c960c
> build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.

I’m not convinced this was a worthwhile change BTW, looking at the
intended clarity improvement vs. cost ratio.

> Although the `guix.scm' has a comment like
>
> ;; To use the canonical commit that has everything prebuilt:
> ;;
> ;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
>
>
> documenting a commit that can be used for building the package and has
> substitutes available, usage of the commit is not enforced.  After a
> recent `guix pull', we now get this warning
>
> pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
>
> and I'm wondering what the best moment would be to change the package
> description.  Upgrading sooner (i.e., now) means that a future guix that
> has this deprecated feature removed will be able to build more
> hystorical releases of the package simply by doing `guix shell', so
> that's probably the best choice?  It would mean that all developers have
> to upgrade now (or use the time machine).

Yeah, that’s always a difficult choice, and I don’t have a good answer.
What’s sure is that the deprecated name will remain available for a
relatively long time, so there’s no urgency at this point.

> but you'd have to know about that and it probably only works for the
> Dezyne package.  Is there a better way or should something like this be
> advertised/recommended in the documentation?

I’m not sure we could recommend one approach that would work for
everyone because it really depends on the use case (for instance whether
building with an older Guix is important for your project.  But at
least, by setting expectations, the deprecation policy lets users making
informed decisions.

Ludo’.

[bug#72840] Input welcome on the proposed deprecation policy

[Andreas Enge]

Hello,

I think we should not only remove packages that are unmaintained upstream,
but also packages that do not build.

Concretely I am thinking of a number of related packages that we have in a
version of 2019, and which has had releases since then. The project does
not build any more, just upgrading the source is not enough, and the package
definition is very complex. I have called out for help, but not received
any reply.

While I might be able to update the project, it feels like a waste of time,
since apparently no Guix user is interested in it right now.

A one-month notice period sounds appropriate to me for this.

So maybe replace:
  Packages that their upstream developers have declared as having reached
  ``end of life'' or being unmaintained may be removed.
by
  Packages that their upstream developers have declared as having reached
  ``end of life'' or being unmaintained, or that do not build in Guix,
  may be removed.

This may be a bit brutal (I would normally argue that one should try an
update first); but if during one month nobody steps in to carry out the
update, that is telling.

Andreas