churchyard commented

Hello,

I happen to maintain some applications in Fedora where I am strongly confident our users would prefer "latest and greatest" over 100 % "stability" of the user interface and/or results.

For some of them, I've been more or less silently breaking the Updates Policy hoping that nothing would break (nothing did so far). For others, I've requested FESCo exceptions for individual updates. I'd like to request a permanent exception to allow upgrading the following tools and apps to latest versions in stable Fedora releases.

For transparency reasons, I've decided to share the list of packages on this mailing list before approaching FESCo. It was 10 days ago:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4UK5JT6V6QFDHLW6Z7RQJCFK6AKHKYQ2/

PrusaSlicer and Cura (3D printer control apps)

prusa-slicer
cura (and dependencies):
- CuraEngine
- cura-fdm-materials
- libarcus
- libnest2d
- libsavitar
- python-pynest2d
- python-uranium

IMHO users want the latest features to support their latest 3D printers and having an outdated version only makes them reach for an alternate source of PrusaSlicer / Cura.

Black (Python code formatter)

python-black

Black is a code formatter with very strict rules. One of the benefit of using black is the determinism of its output. By running black on code twice, it is guaranteed (well, claimed) to produce no changes. When updating it however, new changes might appear on a codebase that was previously considered "OK".

With each release, there might be several subtle changes in formatting, however I expect users who install black from RPM to prefer the latest version of black over total stability of its output. Who needs 100 % stability can "pin" exact black version in their requirements / pipenv /poetry file and get it form PyPI.

Tox (standardized Python test executor)

python-tox

Tox aims to automate and standardize testing in Python.
As new standards happen, tox is adapted upstream. It very rarely breaks backwards compatibility. Unlike other Python development tools, it is much more beneficial to have tox installed in the system Python stack and not in a virtual environment. I'd like to always provide the latest and greatest tox to our users = Python developers.

Note that this exception would not apply to the planned entire rewrite (i.e. tox version 4), only to latest tox 3.

HTTPie (command-line HTTP client)

httpie

"HTTPie is a user-friendly command-line HTTP client for the API era. It comes with JSON support, syntax highlighting, persistent sessions, wget-like downloads, plugins, and more." The command line interface is generally very stable and the upstream developers are very interested in seeing the latest version in stable Fedora releases (and eventually also EPEL, but that is out of scope here).

ownCloud Desktop Client

owncloud-client

As OwnCloud serves are updated, users might need the latest version of the client installed to be able to use them. Hence, I'd like to be able to update this package freely.

OTOH I don't actually plan to do that often, because I maintain the package "to scratch my own itch" and I would only do that if the server used by our university requires client updates. However, if co-maintainers appear, this could happen more often.

Hello, I happen to maintain some applications in Fedora where I am strongly confident our users would prefer "latest and greatest" over 100 % "stability" of the user interface and/or results. For some of them, I've been more or less silently breaking the Updates Policy hoping that nothing would break (nothing did so far). For others, I've requested FESCo exceptions for individual updates. I'd like to request a **permanent exception** to allow upgrading the following tools and apps to latest versions in stable Fedora releases. For transparency reasons, I've decided to share the list of packages on this mailing list before approaching FESCo. It was 10 days ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4UK5JT6V6QFDHLW6Z7RQJCFK6AKHKYQ2/ # PrusaSlicer and Cura (3D printer control apps) - prusa-slicer - cura (and dependencies): - CuraEngine - cura-fdm-materials - libarcus - libnest2d - libsavitar - python-pynest2d - python-uranium IMHO users want the latest features to support their latest 3D printers and having an outdated version only makes them reach for an alternate source of PrusaSlicer / Cura. # Black (Python code formatter) - python-black See also https://pagure.io/fesco/issue/2259 and https://pagure.io/fesco/issue/2525 Black is a code formatter with very strict rules. One of the benefit of using black is the determinism of its output. By running black on code twice, it is guaranteed (well, claimed) to produce no changes. When updating it however, new changes might appear on a codebase that was previously considered "OK". With each release, there might be several subtle changes in formatting, however I expect users who install black from RPM to prefer the latest version of black over total stability of its output. Who needs 100 % stability can "pin" exact black version in their requirements / pipenv /poetry file and get it form PyPI. # Tox (standardized Python test executor) - python-tox Tox aims to automate and standardize testing in Python. As new standards happen, tox is adapted upstream. It very rarely breaks backwards compatibility. Unlike other Python development tools, it is much more beneficial to have tox installed in the system Python stack and not in a virtual environment. I'd like to always provide the latest and greatest tox to our users = Python developers. Note that this exception would not apply to the planned entire rewrite (i.e. tox version 4), only to latest tox 3. # HTTPie (command-line HTTP client) - httpie "HTTPie is a user-friendly command-line HTTP client for the API era. It comes with JSON support, syntax highlighting, persistent sessions, wget-like downloads, plugins, and more." The command line interface is generally very stable and the upstream developers are very interested in seeing the latest version in stable Fedora releases (and eventually also EPEL, but that is out of scope here). # ownCloud Desktop Client - owncloud-client As OwnCloud serves are updated, users might need the latest version of the client installed to be able to use them. Hence, I'd like to be able to update this package freely. OTOH I don't actually plan to do that often, because I maintain the package "to scratch my own itch" and I would only do that if the server used by our university requires client updates. However, if co-maintainers appear, this could happen more often.

zbyszek commented

2021-07-22 12:35:12 +00:00

Owner

+1

Such an exception would be applicable to plenty of packages, and I think many packagers do this without any discussion. I wonder if we should somehow relax the policy to remove the requirement of fesco tickets in various trivial cases. Something like this:

if the package is non-critpath, and can be safely updated without breaking other packages or user scripts using the package (either does not expose any API, or the API is always changed in a backwards-compatible way), and the maintainer deems this appropriate, they can push updates to stable branches.
if such a policy is adopted, it should be mentioned in the %description:
"This package follows an update policy where the major version updates also happen in stable branches."

With %autospec it's becoming even less work to push a version update to an older branch, even if there are some other differences between branches. For many packages which maintain strict backwards compatibility this will only make maintainer life easier and deliver a better user experience.

+1 Such an exception would be applicable to plenty of packages, and I think many packagers do this without any discussion. I wonder if we should somehow relax the policy to remove the requirement of fesco tickets in various trivial cases. Something like this: - if the package is non-critpath, and can be safely updated without breaking other packages or user scripts using the package (either does not expose any API, or the API is always changed in a backwards-compatible way), and the maintainer deems this appropriate, they can push updates to stable branches. - if such a policy is adopted, it should be mentioned in the %description: "This package follows an update policy where the major version updates also happen in stable branches." With %autospec it's becoming even less work to push a version update to an older branch, even if there are some other differences between branches. For many packages which maintain strict backwards compatibility this will only make maintainer life easier and deliver a better user experience.

fche commented

2021-07-22 19:14:43 +00:00

Can we get a pointer to the precise fedora packaging rule that we are talking about that would require a formal exception? (My understanding is that plenty of packages rebase versions during a stable/previous fedora release.)

zbyszek commented

2021-07-22 22:30:59 +00:00

Owner

Can we get a pointer

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

> Can we get a pointer https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

fche commented

2021-07-22 22:41:57 +00:00

Thanks. ISTM the text discourages but does not forbid packagers from routine rebases (that are local & compatible in all the desirable ways @zbyszek listed). It's not clear that the policy is mandating the requesting of formal permission from fesco. If that is (and remains) the intent, it should probably spell this stuff out via terms like SHALL? Do we have any idea how many packages routinely rebase? (cough cough some of mine do)

decathorpe commented

2021-07-25 10:08:17 +00:00

Owner

+1 to the exceptions.

I try to stick to "keep things working as best as possible for my users" for updates for my own packages, which I think is the intention of the Update Policy, even if it doesn't spell it out that way. It sounds like it was tailored to "traditional" stuff like libraries with APIs, ABIs, and sonames, and CLIs that might break user scripts, where breaking things with major updates is very disruptive. Keeping client software working for server software that we don't control doesn't really fall under either of those categories, but it has to be updated nonetheless to keep it working.

+1 to the exceptions. I try to stick to "keep things working as best as possible for my users" for updates for my own packages, which I think is the *intention* of the Update Policy, even if it doesn't spell it out that way. It sounds like it was tailored to "traditional" stuff like libraries with APIs, ABIs, and sonames, and CLIs that might break user scripts, where breaking things with major updates is very disruptive. Keeping client software working for server software that we don't control doesn't really fall under either of those categories, but it has to be updated nonetheless to keep it working.

ngompa commented

2021-07-27 23:44:23 +00:00

Owner

+1

churchyard commented

2021-08-02 08:54:41 +00:00

Author

Note that I am also +1 explicitly.

zbyszek commented

2021-08-02 12:55:08 +00:00

Owner

After a week:
APPROVED (+4, 0, 0)

After a week: APPROVED (+4, 0, 0)

zbyszek commented

2021-08-02 12:55:08 +00:00

Owner

Metadata Update from @zbyszek:

Issue tagged with: pending announcement

**Metadata Update from @zbyszek**: - Issue tagged with: pending announcement

churchyard commented

2021-08-02 13:02:29 +00:00

Author

Metadata Update from @churchyard:

Issue tagged with: document it

**Metadata Update from @churchyard**: - Issue tagged with: document it

zbyszek commented

2021-08-09 13:29:30 +00:00

Owner

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SQ6UOPROYBPINNEH2H4MPQQEVCWORZXD/

zbyszek commented

2021-08-09 13:29:30 +00:00

Owner

Metadata Update from @zbyszek:

Issue untagged with: pending announcement

**Metadata Update from @zbyszek**: - Issue **un**tagged with: pending announcement

zbyszek commented

2021-12-13 12:45:15 +00:00

Owner

Metadata Update from @zbyszek:

Issue assigned to zbyszek

**Metadata Update from @zbyszek**: - Issue assigned to zbyszek

zbyszek commented

2021-12-13 12:53:17 +00:00

Owner

https://pagure.io/fesco/fesco-docs/pull-request/56

zbyszek commented

2022-01-10 12:31:36 +00:00

Owner

Done now. The new text should be available after the next rebuild (1h?).

zbyszek commented

2022-01-10 12:31:36 +00:00

Owner

Metadata Update from @zbyszek:

Issue untagged with: document it
Issue close_status updated to: Accepted
Issue status updated to: Closed (was: Open)

**Metadata Update from @zbyszek**: - Issue **un**tagged with: document it - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)

Rows
Columns

Permanent Updates Policy exception for PrusaSlicer, Cura, Black, tox, HTTPie and ownCloud Desktop Client #2652

PrusaSlicer and Cura (3D printer control apps)

Black (Python code formatter)

Tox (standardized Python test executor)

HTTPie (command-line HTTP client)

ownCloud Desktop Client