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

[Miro Hrončok]

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. If you see potential problems, do let me 
know.


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.



Thanks for any feedback.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Kevin Fenzi]

On Mon, Jul 12, 2021 at 01:30:19PM +0200, Miro Hrončok wrote:
>  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. If you see potential problems, do let
>  me know. 
...snip...

I think these are all reasonable and make sense why they need to be
excepted from the normal policy. 

kevin

[Otto Urpelainen]

Miro Hrončok kirjoitti 12.7.2021 klo 14.30:
>  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. If you see potential 
>  problems, do let me know. 
(snip)

>  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. 
I wonder if Updates Policy should have general wording that would allow 
you to update this package without asking for exceptions, or at least 
"make it more likely to grant a request"? It does not make much sense to 
disallow client program updates because they contain "new features" when 
the remote backends it is connecting to require those features.

Web browsers are another example of this, and maybe also your 3d printer 
control apps.

Otto

[Dan Čermák]

Otto Urpelainen <oturpe(a)iki.fi&gt; writes:

*snip*

>  I wonder if Updates Policy should have general wording that would allow 
>  you to update this package without asking for exceptions, or at least 
>  "make it more likely to grant a request"? It does not make much sense to 
>  disallow client program updates because they contain "new features" when 
>  the remote backends it is connecting to require those features.
>
>  Web browsers are another example of this, and maybe also your 3d printer 
>  control apps. 
Agreed, I think we should not prevent upgrades to new major versions for
end user applications where it is highly desirable to be able to use the
new version. This is especially important for programs that connect to a
backend that might be using a newer version outside of the user's
control.

I am however unsure what the exact rules are, because I also pushed an
upgrade of Emacs from 26 to 27 to Fedora 33 and received a few
complaints there (to my surprise).


Cheers,

Dan

[Richard Shaw]

On Sat, Jul 17, 2021 at 7:00 AM Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
wrote:

>  Otto Urpelainen <oturpe(a)iki.fi&gt; writes:
>
>  I am however unsure what the exact rules are, because I also pushed an
>  upgrade of Emacs from 26 to 27 to Fedora 33 and received a few
>  complaints there (to my surprise).
>  
I guess I am too. I haven't looked at the guidelines at this very moment,
but I thought it only strongly discouraged major updates within a release,
but did not forbid it.

I typically don't do API breaking updates of library packages unless
there's a good reason, but I tend to keep all user facing applications up
to date across all supported releases. I'm pretty sure a lot of packages
work that way.

Thanks,
Richard

[Miro Hrončok]

On 12. 07. 21 13:30, Miro Hrončok wrote:
>  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. If you see potential problems, do let me 
>  know. 
The FESCo ticket is https://pagure.io/fesco/issue/2652

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok