Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

In the wild, I often see Fedora described as a "semi-rolling" release. 
As a policy matter, the distribution promises to be mostly stable, but I 
find it increasingly hard to honestly present it as such.

As a couple of quick examples, I'd point out that in Fedora 35, Blender 
updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs 
updated from version 27 to 28.  I've read in the KDE Matrix channel that 
KDE will be updated in Fedora 36 to 5.26, even though it has already 
been updated from 5.24 -> 5.25 (my reading of the KDE update policy is 
that Fedora used to update all releases with every KDE release, but 
decided to stop).  Firefox and Thunderbird get updates in most releases, 
even when they contain API-breaking changes  (those really should have 
an explicit exception, IMHO.)  I could offer more, but my point is 
simply that examples of updates in prominent packages isn't hard to find.

That's not necessarily to object to those changes (though I did have to 
do some minor fixes after the emacs update, and I grumbled quietly), and 
I don't want to disrupt users getting new features if that's what 
everyone actually wants.  But, it does bother me that the documentation 
doesn't seem to reflect reality.  I think that the documentation should 
offer users a realistic expectation of what they'll get from Fedora.

Does anyone else feel like the documentation should be updated, or am I 
making too much of this?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
>  In the wild, I often see Fedora described as a
> "semi-rolling" release. As a
>  policy matter, the distribution promises to be mostly stable, but I find it
>  increasingly hard to honestly present it as such.
>  
>  As a couple of quick examples, I'd point out that in Fedora 35, Blender
>  updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
>  updated from version 27 to 28.  I've read in the KDE Matrix channel that KDE
>  will be updated in Fedora 36 to 5.26, even though it has already been
>  updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
>  Fedora used to update all releases with every KDE release, but decided to
>  stop).  Firefox and Thunderbird get updates in most releases, even when they
>  contain API-breaking changes  (those really should have an explicit
>  exception, IMHO.)  I could offer more, but my point is simply that examples
>  of updates in prominent packages isn't hard to find. 
FWIW, I was sure that we have an explicit exception for Firefox. But
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
doesn't list it.

Yeah, I think that the way updates are managed has in practice changed a lot.
This is at least partially caused by the slow change in relationship between
upstreams and our packaging: the distro is inching ever closer to being a
thin delivery mechanism for upstream code and upstream build system and
upstream packaging decisions and upstream release cadence. Even a few years
ago it was fairly common for the packaging to be a big affair with tweaks
to the upstream build system or even a completely custom build, downstream
patches, and many modifications to the final layout. There still are packages
like this, but less and less. If the upstream is sane, there is no need to
deal with any of that.

Another aspect that has changed is that many upstreams are better at keeping
backwards compatibility. E.g. in Rust and Python ecosystems, semver is now
the norm, and in my experience the associated understanding that breaking API
is bad is more widespread. So there are less reasons for us not to update.
At the same time, software is ever more complicated and moves ever faster,
so maintaining multiple versions in parallel is a lot of work.

Combining all that (bigger and more complicated packages, saner upstream
updates, and our packaging being closer to upstream), just makes it less
work for the packager to release the same upstream version in all Fedora
releases.

Then there's the aspect that for fast-moving software, the latest version
may be the only usable version.

>  That's not necessarily to object to those changes (though I did
> have to do
>  some minor fixes after the emacs update, and I grumbled quietly), and I
>  don't want to disrupt users getting new features if that's what everyone
>  actually wants.  But, it does bother me that the documentation doesn't seem
>  to reflect reality.  I think that the documentation should offer users a
>  realistic expectation of what they'll get from Fedora.
>  
>  Does anyone else feel like the documentation should be updated, or am I
>  making too much of this? 
I think the documentation should be updated to follow the changing practice.
I'd change the policy to allow packages to update to latest versions
if deemed the best option by the maintainers. (Guidance when it is
actually the best option would need to be provided too of course.)

Zbyszek

[Tomáš Popela]

On Thu, Nov 24, 2022 at 2:34 PM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; wrote:

>  On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
>  > In the wild, I often see Fedora described as a "semi-rolling" release.
>  As a
>  > policy matter, the distribution promises to be mostly stable, but I find
>  it
>  > increasingly hard to honestly present it as such.
>  >
>  > As a couple of quick examples, I'd point out that in Fedora 35, Blender
>  > updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
>  > updated from version 27 to 28.  I've read in the KDE Matrix channel that
>  KDE
>  > will be updated in Fedora 36 to 5.26, even though it has already been
>  > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
>  > Fedora used to update all releases with every KDE release, but decided to
>  > stop).  Firefox and Thunderbird get updates in most releases, even when
>  they
>  > contain API-breaking changes  (those really should have an explicit
>  > exception, IMHO.)  I could offer more, but my point is simply that
>  examples
>  > of updates in prominent packages isn't hard to find.
>
>  FWIW, I was sure that we have an explicit exception for Firefox. But
>  https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
>  doesn't list it.
>
>  
Although not explicitly stated there, Firefox is mentioned as a first
example in
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#examples. Also
nearly all Firefox and Thunderbird updates there are the security ones
there really isn't another way (unless someone will package Firefox ESR
releases in Fedora, but that would need to be rebased yearly anyway).

Tom

[Gordon Messmer]

On 2022-11-24 05:50, Tomáš Popela wrote:
>  Although not explicitly stated there, Firefox is mentioned as a first
>
>  example in 
>  https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#examples. 
>  Also nearly all Firefox and Thunderbird updates there are the security 
>  ones there really isn't another way (unless someone will package 
>  Firefox ESR releases in Fedora, but that would need to be rebased 
>  yearly anyway). 

Yes, Firefox appears as an example, but my reading is that it's an 
example of the class of packages that fall under the "Security fixes" 
category, which states that "the package maintainer(s) MUST open a FESCo 
ticket for approval to rebase the package".  I don't think that's 
happening for each Firefox release (nor would that really be practical), 
which is why it stands out as weird that I can't find a FESCO ticket 
granting Firefox a permanent exception.

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes

Thunderbird is a case where I'd like to see a specific update policy 
decision.  It follows the Mozilla ESR schedule, so a release is 
supported for a little over a year.  Given Fedora's release schedule, it 
would need to be updated to a new major version in at least alternating 
Fedora releases.  But there's 12 weeks of overlap from one supported 
release to the next.  I see Thunderbird as a business productivity suite 
that offers an API for integrations (which can break from one release to 
the next), similar to LibreOffice (which, as far as I know, Fedora does 
not rebase during a release).  And because the API is not guaranteed to 
be compatible from one release to the next, I would much prefer to see 
Thunderbird updated early in Rawhide and releases that are not yet 
final, but to remain on the older stable version for as long as possible 
on any Fedora release that had included it.  As it is today, users get 
breaking changes in Thunderbird at unexpected times.

[Eike Rathke]

Hi,

On Thursday, 2022-11-24 10:41:45 -0800, Gordon Messmer wrote:

>   I would much prefer to see Thunderbird updated early in
>  Rawhide and releases that are not yet final, but to remain on the older
>  stable version for as long as possible on any Fedora release that had
>  included it. 
That'd be a problem though because ~every Thunderbird x.y.0 release
includes security fixes, which are not backported to older then
unmaintained ESR releases by Mozilla. Not upgrading/rebasing to the then
current ESR release would leave users of older releases vulnerable, or
shift the burden of backporting fixes to maintainers for a highly
divergent source code base; with an additional cost that the exact
changes to fix a CVE are not readily available and would have to be
peeled out if discoverable at all. I consider this impractical.

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A

[Gordon Messmer]

On 2022-11-28 07:36, Eike Rathke wrote:
> >   I would much prefer to see Thunderbird updated early in
> > Rawhide and releases that are not yet final, but to remain on the older
> > stable version for as long as possible on any Fedora release that had
> > included it.
>  That'd be a problem though because ~every Thunderbird x.y.0 release
>  includes security fixes, which are not backported to older then
>  unmaintained ESR releases by Mozilla. 

I don't understand... When I said that I'd prefer to see Fedora remain 
on the older stable version "for as long as possible", I meant "for as 
long as Mozilla continues publishing security fixes for that release", 
which should be at least 12 weeks after a new stable release series 
(x.y.0) starts.

[Eike Rathke]

Hi Gordon,

On Monday, 2022-11-28 08:21:31 -0800, Gordon Messmer wrote:

>  On 2022-11-28 07:36, Eike Rathke wrote:
>  > >   I would much prefer to see Thunderbird updated early in
>  > > Rawhide and releases that are not yet final, but to remain on the older
>  > > stable version for as long as possible on any Fedora release that had
>  > > included it.
>  > That'd be a problem though because ~every Thunderbird x.y.0 release
>  > includes security fixes, which are not backported to older then
>  > unmaintained ESR releases by Mozilla.
>  
>  I don't understand... When I said that I'd prefer to see Fedora remain on
>  the older stable version "for as long as possible", I meant "for as long
> as
>  Mozilla continues publishing security fixes for that release", which should
>  be at least 12 weeks after a new stable release series (x.y.0) starts. 
Maybe I misunderstood. So you're agreeing that once Thunderbird does not
support the N-1 ESR anymore then rebasing to N is wanted on release
branches?

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A

[Gordon Messmer]

On 2022-11-30 06:41, Eike Rathke wrote:
>  Maybe I misunderstood. So you're agreeing that once Thunderbird
> does not
>  support the N-1 ESR anymore then rebasing to N is wanted on release
>  branches? 

Yes.  In really explicit detail, see the message I sent at 2022-11-27, 
23:42 (Pacific).

[Adam Williamson]

On Thu, 2022-11-24 at 07:34 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
>  > In the wild, I often see Fedora described as a "semi-rolling" release. As
> a
>  > policy matter, the distribution promises to be mostly stable, but I find it
>  > increasingly hard to honestly present it as such.
>  > 
>  > As a couple of quick examples, I'd point out that in Fedora 35, Blender
>  > updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
>  > updated from version 27 to 28.  I've read in the KDE Matrix channel that KDE
>  > will be updated in Fedora 36 to 5.26, even though it has already been
>  > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
>  > Fedora used to update all releases with every KDE release, but decided to
>  > stop).  Firefox and Thunderbird get updates in most releases, even when they
>  > contain API-breaking changes  (those really should have an explicit
>  > exception, IMHO.)  I could offer more, but my point is simply that examples
>  > of updates in prominent packages isn't hard to find.
>  
>  FWIW, I was sure that we have an explicit exception for Firefox. But
>  https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
>  doesn't list it.
>  
>  Yeah, I think that the way updates are managed has in practice changed a lot.
>  This is at least partially caused by the slow change in relationship between
>  upstreams and our packaging: the distro is inching ever closer to being a
>  thin delivery mechanism for upstream code and upstream build system and
>  upstream packaging decisions and upstream release cadence. Even a few years
>  ago it was fairly common for the packaging to be a big affair with tweaks
>  to the upstream build system or even a completely custom build, downstream
>  patches, and many modifications to the final layout. There still are packages
>  like this, but less and less. If the upstream is sane, there is no need to
>  deal with any of that.
>  
>  Another aspect that has changed is that many upstreams are better at keeping
>  backwards compatibility. E.g. in Rust and Python ecosystems, semver is now
>  the norm, and in my experience the associated understanding that breaking API
>  is bad is more widespread. So there are less reasons for us not to update.
>  At the same time, software is ever more complicated and moves ever faster,
>  so maintaining multiple versions in parallel is a lot of work.
>  
>  Combining all that (bigger and more complicated packages, saner upstream
>  updates, and our packaging being closer to upstream), just makes it less
>  work for the packager to release the same upstream version in all Fedora
>  releases.
>  
>  Then there's the aspect that for fast-moving software, the latest version
>  may be the only usable version.
>  
>  > That's not necessarily to object to those changes (though I did have to do
>  > some minor fixes after the emacs update, and I grumbled quietly), and I
>  > don't want to disrupt users getting new features if that's what everyone
>  > actually wants.  But, it does bother me that the documentation doesn't seem
>  > to reflect reality.  I think that the documentation should offer users a
>  > realistic expectation of what they'll get from Fedora.
>  > 
>  > Does anyone else feel like the documentation should be updated, or am I
>  > making too much of this?
>  
>  I think the documentation should be updated to follow the changing practice.
>  I'd change the policy to allow packages to update to latest versions
>  if deemed the best option by the maintainers. (Guidance when it is
>  actually the best option would need to be provided too of course.) 
Well, I find your mail interesting, because...I agree with most of the
first paragraph, but at the same time, none of that is really in
conflict with the existing update policy as I read it.

The update policy is very keen on discouraging *compatibility-breaking*
updates. However it already allows exceptions when updating to a new
major release is necessary to maintain security (i.e. upstream doesn't
provide stable branches with security fixes, and backporting downstream
is too difficult).

The thrust of your argument is that the F/OSS ecosystem as a whole has
gotten better at doing updates that don't break compatibility. It's not
against the current policy, as I read it, to ship such updates, so it
doesn't really need any updating on that view...

On the whole, I'd say the policy is still sensible as-is, but it's
always been something that's kind of applied on request, like city
bylaws tend to be. If your garden fence is against the bylaws but none
of your neighbours complain, you'll probably get away with it. If you
update your package to a new major release but everyone who uses it is
fine with that, you'll probably get away with it...we tend to only
invoke the policy when an update gets "flagged" by negative feedback or
a failed test or whatever.

I also have a confession like msuchy's: I don't follow the policy for
openQA. None of the approximately three other people who actually use
the Fedora openQA package has ever complained about that, so I think
I'm getting away with it...:D

Going back to Gordon's original examples: I think Firefox should be
documented as having a permanent exception here, there is obviously no
other sensible policy for it. The Blender and emacs cases could use
looking into, it'd be interesting to hear what the maintainers say. The
KDE wiki page should probably just be changed - KDE maintenance has
turned over a bit lately and got more active and the current
maintainers probably just didn't know/remember to update that page to
current practice.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Gordon Messmer]

On 2022-11-24 09:28, Adam Williamson wrote:
>  The update policy is very keen on discouraging
> *compatibility-breaking*
>  updates. 

That's true, it does explicitly discourage compatibility breaking 
updates.  But it also says "Updates should aim to fix bugs, and not 
introduce features," and if that's not something we care about as a 
principle, then the policy shouldn't say that we do.  That's my 
argument: we should present users with realistic expectations of what 
the distribution will deliver.


>  However it already allows exceptions when updating to a new
>  major release is necessary to maintain security 

That's also true.  The policy does allow updating for security reasons, 
but it also says of those updates that "the package maintainer(s) MUST 
open a FESCo ticket for approval to rebase".


>  On the whole, I'd say the policy is still sensible as-is, but
> it's
>  always been something that's kind of applied on request, like city
>  bylaws tend to be. If your garden fence is against the bylaws but none
>  of your neighbours complain, you'll probably get away with it. If you
>  update your package to a new major release but everyone who uses it is
>  fine with that, you'll probably get away with it...we tend to only
>  invoke the policy when an update gets "flagged" by negative feedback or
>  a failed test or whatever. 

I'll keep beating the Thunderbird drum: On Sep 2, a thread started on 
this list re: "Thunderbird 102 pushed to F36 stable." As far as I know, 
no action was taken in response to users reporting that a major update 
pushed during a stable release broke their workflow.

[Vít Ondruch]

I think that the documentation is right and should be honored. Updates 
in stable should be exception, if there really is no other option. I 
don't think that the constant churn of the updates is good for users and 
I think it'd be better if maintainers spend their time making sure the 
next version of Fedora is much better then keeping the older versions 
updated with the most recent versions.

But I am Rawhide user, so what can I know :)


Vít


Dne 24. 11. 22 v 1:04 Gordon Messmer napsal(a):
>  In the wild, I often see Fedora described as a
> "semi-rolling" release. 
>  As a policy matter, the distribution promises to be mostly stable, but 
>  I find it increasingly hard to honestly present it as such.
>
>  As a couple of quick examples, I'd point out that in Fedora 35, 
>  Blender updated from 2.93 (an LTS version) to version 3.  In Fedora 
>  36, Emacs updated from version 27 to 28.  I've read in the KDE Matrix 
>  channel that KDE will be updated in Fedora 36 to 5.26, even though it 
>  has already been updated from 5.24 -> 5.25 (my reading of the KDE 
>  update policy is that Fedora used to update all releases with every 
>  KDE release, but decided to stop).  Firefox and Thunderbird get 
>  updates in most releases, even when they contain API-breaking changes  
>  (those really should have an explicit exception, IMHO.)  I could offer 
>  more, but my point is simply that examples of updates in prominent 
>  packages isn't hard to find.
>
>  That's not necessarily to object to those changes (though I did have 
>  to do some minor fixes after the emacs update, and I grumbled 
>  quietly), and I don't want to disrupt users getting new features if 
>  that's what everyone actually wants.  But, it does bother me that the 
>  documentation doesn't seem to reflect reality.  I think that the 
>  documentation should offer users a realistic expectation of what 
>  they'll get from Fedora.
>
>  Does anyone else feel like the documentation should be updated, or am 
>  I making too much of this?
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: 
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Michael J Gruber]

I guess there's (at least) two ways to understand "stable":

- things don't break
- things don't change

(... unless absolutely necessary, in each case)

To me, "things don't break" describes Fedora stable releases (as opposed to
rawhide), and "things don't change" describes RHEL.

A typical Fedora user wants the latest if it works and should be prepared to adjust to the
changes this brings with it (but not to rawhide-type breakage). A typical RHEL user wants
a stable environment for reproducible computing (short of containerizing and freezing for
reproducibility).

On a side-note: This is why Fedora packagers are sometimes hesitant to build for EPEL
because it means going by a different notion of "stable".

[Vít Ondruch]

Dne 24. 11. 22 v 12:13 Michael J Gruber napsal(a):
>  I guess there's (at least) two ways to understand
> "stable":
>
>  - things don't break
>  - things don't change
>
>  (... unless absolutely necessary, in each case)
>
>  To me, "things don't break" describes Fedora stable releases (as opposed to
> rawhide), and "things don't change" describes RHEL.
>
>  A typical Fedora user wants the latest if it works and should be prepared to adjust to
> the changes this brings with it
>  

I disagree here. And even if you are right at this point, then they 
could wait 6 months for next Fedora release, can't they?


Vít


>    (but not to rawhide-type breakage). A typical RHEL user wants a
> stable environment for reproducible computing (short of containerizing and freezing for
> reproducibility).
>
>  On a side-note: This is why Fedora packagers are sometimes hesitant to build for EPEL
> because it means going by a different notion of "stable".
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Gordon Messmer]

On 2022-11-24 03:13, Michael J Gruber wrote:
>  I guess there's (at least) two ways to understand
> "stable":
>
>  - things don't break
>  - things don't change 

True, but the policy document is explicit about which meaning is 
intended, reading, "Updates should aim to fix bugs, and not introduce 
features, particularly when those features would materially affect the 
user or developer experience"

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

[Stephen Smoogen]

On Thu, 24 Nov 2022 at 13:12, Gordon Messmer <gordon.messmer(a)gmail.com&gt;
wrote:

>  On 2022-11-24 03:13, Michael J Gruber wrote:
>  > I guess there's (at least) two ways to understand "stable":
>  >
>  > - things don't break
>  > - things don't change
>
>
>  True, but the policy document is explicit about which meaning is
>  intended, reading, "Updates should aim to fix bugs, and not introduce
>  features, particularly when those features would materially affect the
>  user or developer experience"
>
>  https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
>
>  
It has to do with differing opinions on that and in the first part of the
sentence. There is
A) Updates should aim to fix bugs, AND not introduce features.
B) Updates should aim to fix bugs, and not introduce features.

Reason A with a strong logical AND means that things should be backported
for any bug fix. In this case, you are probably never going to see any bug
fixes occur in the distro as most software projects will say that the bug
is only fixed in the latest version which of course added 9 features. Since
this is usually a large amount of work for someone who may only have taken
the package to keep it in for a dependency, you would then just see those
fixes in rawhide (if at all).

Reason B with a weak language 'and' means that you shouldn't do updates
just to introduce new features but in order to fix things. This means that
if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP,
etc are either a package set they say is LTS OR in the latest.. you are
going to see updates occur.

Whenever I have talked to FESCO members over any large change, they have
said it was the B form they meant and they were ok with updates if it was
the way to fix things.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Adam Williamson]

On Thu, 2022-11-24 at 16:26 -0500, Stephen Smoogen wrote:
>  On Thu, 24 Nov 2022 at 13:12, Gordon Messmer
> <gordon.messmer(a)gmail.com&gt;
>  wrote:
>  
>  > On 2022-11-24 03:13, Michael J Gruber wrote:
>  > > I guess there's (at least) two ways to understand "stable":
>  > > 
>  > > - things don't break
>  > > - things don't change
>  > 
>  > 
>  > True, but the policy document is explicit about which meaning is
>  > intended, reading, "Updates should aim to fix bugs, and not introduce
>  > features, particularly when those features would materially affect the
>  > user or developer experience"
>  > 
>  > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
>  > 
>  > 
>  It has to do with differing opinions on that and in the first part of the
>  sentence. There is
>  A) Updates should aim to fix bugs, AND not introduce features.
>  B) Updates should aim to fix bugs, and not introduce features.
>  
>  Reason A with a strong logical AND means that things should be backported
>  for any bug fix. In this case, you are probably never going to see any bug
>  fixes occur in the distro as most software projects will say that the bug
>  is only fixed in the latest version which of course added 9 features. Since
>  this is usually a large amount of work for someone who may only have taken
>  the package to keep it in for a dependency, you would then just see those
>  fixes in rawhide (if at all).
>  
>  Reason B with a weak language 'and' means that you shouldn't do updates
>  just to introduce new features but in order to fix things. This means that
>  if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP,
>  etc are either a package set they say is LTS OR in the latest.. you are
>  going to see updates occur.
>  
>  Whenever I have talked to FESCO members over any large change, they have
>  said it was the B form they meant and they were ok with updates if it was
>  the way to fix things. 
Thinking it over some more - I think Gordon's right that I hadn't
considered all the language - I think my personal opinion would be that
the policy should be adjusted to be less opinionated on this idea of
"introducing features", and concentrate more on "unexpected changes to
the user experience". There are a lot of cases where introducing
features is entirely benign, after all. If a CLI tool I use grows a
useful extra option while still supporting all the ones it had before
and behaving in the same way when using those, that just does not seem
like something to be concerned about. I'd happily send such an update
to stable.

If the update *removes* some existing argument, or changes the
behaviour of one, that's much more significant.

This is really kinda the rule about API/ABI changes, only for
applications, in a way. Adding new functions to a library doesn't
change the API, only removing or changing the behaviour of existing
ones.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Kevin Fenzi]

On Thu, Nov 24, 2022 at 01:42:20PM -0800, Adam Williamson wrote:
>  
>  Thinking it over some more - I think Gordon's right that I hadn't
>  considered all the language - I think my personal opinion would be that
>  the policy should be adjusted to be less opinionated on this idea of
>  "introducing features", and concentrate more on "unexpected changes to
>  the user experience". There are a lot of cases where introducing
>  features is entirely benign, after all. If a CLI tool I use grows a
>  useful extra option while still supporting all the ones it had before
>  and behaving in the same way when using those, that just does not seem
>  like something to be concerned about. I'd happily send such an update
>  to stable.
>  
>  If the update *removes* some existing argument, or changes the
>  behaviour of one, that's much more significant.
>  
>  This is really kinda the rule about API/ABI changes, only for
>  applications, in a way. Adding new functions to a library doesn't
>  change the API, only removing or changing the behaviour of existing
>  ones. 
I agree. I think this is something we have in the past for gui things
called 'changes in the user experence'. But yeah, we could clarify this
better. 

FWIW I think some cases were grandfathered in when the policy was first
aadopted. firefox and kde for sure. I know I requested a exception for
calibre. 

The policy is also a bit unclear (or just wrong as written) saying
exceptions need to file for every update or can be just 'you have an
exception for this package/collection of packages unless something
changes'. 

kevin

[Adam Williamson]

On Thu, 2022-11-24 at 14:08 -0800, Kevin Fenzi wrote:
>  
>  The policy is also a bit unclear (or just wrong as written) saying
>  exceptions need to file for every update or can be just 'you have an
>  exception for this package/collection of packages unless something
>  changes'.  
The way I read this bit is that the packages listed in the policy have
'permanent' exceptions; if you don't have one of those 'permanent'
exceptions, you must request a one-time exception from FESCo every time
you want to do a bump, and those one-time exceptions don't get written
into the 'permanent' list.

I agree it's not super clear, though. And clearly we aren't 100%
following those rules.

There's another point where we lack clarity, I think. The policy mixes
the words "must" and "should" a lot. But it doesn't make it very
clear
if it's really following a strict meaning for those, like the packaging
policy, or if some of the "shoulds" are really intended as "musts"...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Vít Ondruch]

Dne 24. 11. 22 v 22:42 Adam Williamson napsal(a):
>  On Thu, 2022-11-24 at 16:26 -0500, Stephen Smoogen wrote:
> > On Thu, 24 Nov 2022 at 13:12, Gordon Messmer <gordon.messmer(a)gmail.com&gt;
> > wrote:
> >
> >> On 2022-11-24 03:13, Michael J Gruber wrote:
> >>> I guess there's (at least) two ways to understand "stable":
> >>>
> >>> - things don't break
> >>> - things don't change
> >>
> >> True, but the policy document is explicit about which meaning is
> >> intended, reading, "Updates should aim to fix bugs, and not introduce
> >> features, particularly when those features would materially affect the
> >> user or developer experience"
> >>
> >> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
> >>
> >>
> > It has to do with differing opinions on that and in the first part of the
> > sentence. There is
> > A) Updates should aim to fix bugs, AND not introduce features.
> > B) Updates should aim to fix bugs, and not introduce features.
> >
> > Reason A with a strong logical AND means that things should be backported
> > for any bug fix. In this case, you are probably never going to see any bug
> > fixes occur in the distro as most software projects will say that the bug
> > is only fixed in the latest version which of course added 9 features. Since
> > this is usually a large amount of work for someone who may only have taken
> > the package to keep it in for a dependency, you would then just see those
> > fixes in rawhide (if at all).
> >
> > Reason B with a weak language 'and' means that you shouldn't do updates
> > just to introduce new features but in order to fix things. This means that
> > if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP,
> > etc are either a package set they say is LTS OR in the latest.. you are
> > going to see updates occur.
> >
> > Whenever I have talked to FESCO members over any large change, they have
> > said it was the B form they meant and they were ok with updates if it was
> > the way to fix things.
>  Thinking it over some more - I think Gordon's right that I hadn't
>  considered all the language - I think my personal opinion would be that
>  the policy should be adjusted to be less opinionated on this idea of
>  "introducing features", and concentrate more on "unexpected changes to
>  the user experience". There are a lot of cases where introducing
>  features is entirely benign, after all. If a CLI tool I use grows a
>  useful extra option while still supporting all the ones it had before
>  and behaving in the same way when using those, that just does not seem
>  like something to be concerned about. I'd happily send such an update
>  to stable.
>  

While I agree with the above, the update on itself is not free. It cost 
time. It cost bandwidth. And it sill might introduce breakage.


Vít


>  If the update *removes* some existing argument, or changes the
>  behaviour of one, that's much more significant.
>
>  This is really kinda the rule about API/ABI changes, only for
>  applications, in a way. Adding new functions to a library doesn't
>  change the API, only removing or changing the behaviour of existing
>  ones.
>

[Gordon Messmer]

On 2022-11-24 13:26, Stephen Smoogen wrote:
>  It has to do with differing opinions on that and in the first part of 
>  the sentence. There is
>  A) Updates should aim to fix bugs, AND not introduce features.
>  B) Updates should aim to fix bugs, and not introduce features.
>  ...
>  Whenever I have talked to FESCO members over any large change, they 
>  have said it was the B form they meant and they were ok with updates 
>  if it was the way to fix things. 

Sure, I think that's a good illustration of one of the ways the policy 
could be more clear.

But in the context of most of the examples I provided, I think the 
policy and practice diverge even when B is the intended meaning.  
Blender was updated from 2.93, which is *still* an actively supported 
LTS branch (until June 2023), to version 3; if there were critical bugs 
to fix, that could have been done with a much less drastic update.  
Emacs' changelog is fairly brief, but I'm not aware of any critical bug 
fixes that necessitated an update from 27 to 28.  Thunderbird seems like 
it's usually maintained upstream for slightly longer than it lives in 
Fedora. Those don't really fall into the category of updates that are 
required, in order to deliver bug fixes, where the upstream developer 
isn't providing them for the branch already in Fedora.

[Miroslav Suchý]

Dne 24. 11. 22 v 9:52 Vít Ondruch napsal(a):
>  I think that the documentation is right and should be honored. 
For the audience - the documentation is here:

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

>  Updates in stable should be exception, if there really is no other
> option. 
Yup. It is even documented there:

"Some classes of software will not fit in these guidelines. If your package does not
fit in one of the classes below, 
but you think it should be allowed to update more rapidly, propose a new exception class
to FESCo and/or request an 
exception for your specific update case."

I have to make confession. I am breaking this guidelines too. With releasing of new
version of Mock and 
fedora-license-data. The problem for me is that the list of these exception is not
available and not maintained. I 
inherited Mock from Clark and later gave it to Pavel and I am now merely co-maintainer. So
I really do not know if Mock 
has had the exception. And because no one enforce it I even did not apply for the
exception for fedora-license-data and 
I use common sense, becase it does not have sense to have old data in stable branches.


> > Does anyone else feel like the documentation should be updated,
> or am I making too much of this?  
+1 to update documentation. Or even better, document which packages has the exception. And
later ask QE to create tool 
which will warn if packages outside of this list bump up version.

Miroslav

[Petr Pisar]

V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a):
>  > > Does anyone else feel like the documentation should be
> updated, or
>  > > am I making too much of this?
>  
>  +1 to update documentation. Or even better, document which packages has the
>  exception. And later ask QE to create tool which will warn if packages
>  outside of this list bump up version.
>   
Checking for a version bump does not make sense unless you want to force
maintainers to backport each fix. (Nonpaid maintainers won't do it.)

Many upstreams release bug-fix only versions. It's easier for everyone to take
that new version and place it into stable Fedora than applying the difference
as a patch or cherry-picking various commits from an upstream version
controll sysmte (if there is some). Example is a Perl bump from 5.34.0 to
5.34.1. Also many times you cannot distinguish a bug-fix update from
a breaking change by looking at the version number. Example from perl-YAML
changelog:

    1.30 Mon 27 Jan 2020 11:09:46 PM CET
     - Breaking Change: Set $YAML::LoadBlessed default to false to make it more
       secure

    1.29 Sat 11 May 2019 10:26:54 AM CEST
     - Fix regex for alias to match the one for anchors (PR#214 TINITA)

    1.28 Sun 28 Apr 2019 11:46:21 AM CEST
     - Security fix: only enable loading globs when $LoadCode is set (PR#213
       TINITA)


It's not only about bug fixes. In the past I was strict in not adding new
version to stable Fedoras. But I was smashed by users and packagers requesting
rebases there. Either because of new features or just only because of the
version numbers because a third-party code checks for a minimal version.
So I ended up actively rebasing packages until a breaking change. I found it
less error prone to evaluate each update as it comes, than keep everything
boilig in Rawhide and than evaluate a lump of interdependent packages once
in a long time. Especially if the interdependencies are not obvious.

Based on these observations I'm against placing a machine blindly rejecting
version bumps.

That does not mean I encourage maintainers to blindly rabase in stable
Fedoras. If they don't feel confident, then they should not do the rebase.

However, to increase the confidence and quality of Fedora updates, I'd rather
see enforcing fedora-ci tests in Bodhi. They already checks changes in RPM
dependencies, changes in shared library ABI, breaking upgrade path etc. An
example <https://bodhi.fedoraproject.org/updates/FEDORA-2022-525152a5b5>;. It's
really pitty we do not have these tests globally enabled.

People do mistakes, but it does not mean we should stop updating
a distribution because of that.

-- Petr

[Richard Shaw]

On Thu, Nov 24, 2022 at 9:12 AM Petr Pisar <ppisar(a)redhat.com&gt; wrote:

>  V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a):
>  > > > Does anyone else feel like the documentation should be updated, or
>  > > > am I making too much of this?
>  >
>  > +1 to update documentation. Or even better, document which packages has
>  the
>  > exception. And later ask QE to create tool which will warn if packages
>  > outside of this list bump up version.
>  >
>  Checking for a version bump does not make sense unless you want to force
>  maintainers to backport each fix. (Nonpaid maintainers won't do it.)
>  
+1000...

Also, I think keeping the version the same and adding a bunch of upstream
commits that essentially makes it the new version is fundamentally
dishonest. Plus if you do need to report a bug upstream, which version is
it? There's not really an option for "Frankenstein".

My packaging philosophy has largely been, try not to perform soname bumps
in released versions unless absolutely necessary, and most people want the
latest version of user facing apps.

Also, most upstreams of my user facing app packages release incrementally
and frequently. If I didn't update them, I could easily be 10 releases
behind between Fedora releases. That doesn't make sense.

Thanks,
Richard

[Gary Buhrmaster]

On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:

>  I have to make confession. I am breaking this guidelines too. With
> releasing of new version of Mock and fedora-license-data. The problem for me is that the
> list of these exception is not available and not maintained. I inherited Mock from Clark
> and later gave it to Pavel and I am now merely co-maintainer. So I really do not know if
> Mock has had the exception. And because no one enforce it I even did not apply for the
> exception for fedora-license-data and I use common sense, becase it does not have sense to
> have old data in stable branches. 
Unfortunately, this discussion runs into a multidimensional
matrix of considerations, and different people may make
different choices at each checkbox.

* Type of update:
   - bugfix (only)
   - feature changing (adding/deleting)
   - API/ABI breaking

   "security" updates may be any/all of those
   depending on the specifics

* Package maintainer type (gross simplification)
   - Developer
      . can backport and write patches if needed
        and may even participate with upstream
   - "Casual" or "foreign" packager (bad terms, but..)
      . may not be familiar with the package,
        the use cases, or the language.

* Expected class of user of the package:
   - Developer
   - User

     Yes, one can be both while wearing
     different hats sitting in front of the
     same screen at the same time

* Type of package:
   - Tooling (only) which mostly impacts developers
   - Basic Infrastructure (systemd, glibc)
     . "critical path" packages?
   - General purpose use (firefox?)

* Expectation of the consumer:
   - Absolute stability (may be unobtainable)
   - "Best" available (best is overloaded)

* Maturity of the release
   - Current
   - Current - 1

   And the reason I tend to separate these
   is that I tend to expect that current is
   more likely to need fixes soon after the
   rubber meets the road (release), when
   the real QA happens, while current-1
   can be considered more towards stable.
   (i.e. critical fixes may need to be
   backported, but other types of fixes
   can be acquired by upgrading to
   current).


Some of the bullets end up overlapping
in different ways, but if one looks close
enough there are probably examples in
all the various dimensions.


And, of course, selection bias holds in
this discussion, as this list membership,
I would suggest, may not reflect the greater
communities desires.


For the (few) packages I maintain, I try
to only port targeted bugfixes to stable
releases, and new versions go into rawhide
(which eventually percolate to the next
release).  Security fixes can be (have been)
an exception, where an entirely new version
may be necessary everywhere in practice.



And then there is EPEL versions.  Another
bushel of worms.

[Kevin Fenzi]

On Fri, Nov 25, 2022 at 12:20:10AM +0000, Gary Buhrmaster wrote:
>  On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý
> <msuchy(a)redhat.com&gt; wrote:
>  
>  > I have to make confession. I am breaking this guidelines too. With releasing of new
> version of Mock and fedora-license-data. The problem for me is that the list of these
> exception is not available and not maintained. I inherited Mock from Clark and later gave
> it to Pavel and I am now merely co-maintainer. So I really do not know if Mock has had the
> exception. And because no one enforce it I even did not apply for the exception for
> fedora-license-data and I use common sense, becase it does not have sense to have old data
> in stable branches.
>  
>  Unfortunately, this discussion runs into a multidimensional
>  matrix of considerations, and different people may make
>  different choices at each checkbox. 
...snip...

Absoletely. There's a ton of variables that go into the decision, but I
think it's important for there to be some general guidance to err on the
side of not changing the user experence in stable releases if you can.

kevin

[Gordon Messmer]

I'd like to suggest specific updates (I'd feel more like I was 
contributing to a productive conversation and less like I'm merely 
complaining), but I'm a little unclear FESCo's point of view. I'll do my 
best.

Given the discussion so far, I feel like Fedora effectively allows at 
least leaf nodes to update without significant oversight, and I wonder 
if it would be useful to reflect that distinction more fully in the 
philosophy statement.  I am unclear on the general sentiment toward 
updates of packages that are not leaf nodes, and I tend to think that 
it's valuable to maintain minor-version stability (feature stability) on 
those packages even if leaf nodes are expected to maintain only 
major-version stability (compatible-interface stability).  If that's an 
acceptable point of view, perhaps replace the fourth sentence of the 
first paragraph with:

    Updates to shared dependencies should aim to only fix bugs, and not
    introduce features.  Updates to "leaf" nodes may introduce new
    features, but only when those features would not be disruptive to
    the user or developer experience.

It might also be helpful to express a preference for either stability or 
updates when the upstream vendor is actively supporting two stable 
releases of a leaf node.

In the third paragraph, the phrase "ABI changes in general are very 
strongly discouraged" could be prefixed with "Any" or
"Incompatible" in 
order to further clarify whether Fedora releases are supposed to 
maintain Major-version or Minor-version stability in dependency packages.

The Exceptions section says "If your package does not fit in one of the 
classes below..." is confusing, but probably only because the exceptions 
list is disorganized.  It starts with specific packages that have 
exceptions (the kernel, KDE, and other packages), and then "Security 
fixes" -- which looks like a class of packages with an exception, except 
that it requires a FESCo ticket as packages without an exception do (and 
then lists the kernel, again), and finishes with two classes of packages 
with an exception to the policy.  Here, I'd suggest some minor 
reorganization: classes of packages that have exceptions generally, and 
then specific packages with exceptions.  Security fixes seems like it 
belongs at the end, possibly noting that security fixes do not have an 
exception from the stable release policy, but approval of rebase updates 
is fast-tracked.  Or, if they do have an exception because of the nature 
of the update, then generally reword all of this.  Possibly to note that 
a ticket is required in order to organize rebuilding any related 
packages that require it, if packagers are not required to wait for 
FESCo approval.  (And, remove the duplicate reference to the policy 
exception for the kernel)

The first Example describes a Firefox security update and indicates that 
it would be allowed, but does not describe filing the FESCo ticket that 
the "Security Updates" section states as a requirement.  These two 
things should be made consistent.  Maybe use a different package as an 
example, since I think this is intended to illustrate something that 
would require a Major version rebase in order to fix a security problem, 
and which doesn't have an exception.

As a final suggestion, while I hate making the policy any longer, 
perhaps the policy could start with an extremely brief "TL; DR", along 
the lines of:

    "Leaf" nodes MUST be Major-version stable.  Everything else MUST be
    Minor-version stable.  Any more significant rebase MUST have a
    standing exception from FESCo, or request a one-time exception from
    FESCo.

If such a short summary is possible, then maybe the current bugzilla 
remainders to "check the policy" before pushing an update can be improved.



While I expect that the majority of Fedora's maintainers understand 
Semantic Versions and interface stability well, it might be helpful for 
new packages (and occasionally for users) to add a footnote or sidebar 
somewhere to provide background on why a stable interface is desirable, 
and to provide definitions that help clarify what level of stability is 
desirable for dependencies and for leaf nodes.

Definitions and rationale:

In order to understand why a stable interface policy is desirable, it is 
necessary to understand the basics of Semantic Versioning.

In the Semantic Versioning system (https://semver.org/), the Major, 
Minor, and Patch version numbers represent different types of changes as 
they increment.  When only the Patch level increments, users should 
expect no interface changes, only backwards-compatible bug fixes.  When 
the Minor level increments, users should expect that new features or 
interfaces may have been added, but all of the interfaces from prior 
versions with the same Major version are still present and compatible.  
When the Major version increases, then users should expect that 
interfaces may had been removed or changed in incompatible ways.

When an application is built, it will use definitions provided by the 
packages it depends on, and an application's source code and build 
system may detect and use features that are present in the version of 
the dependencies available at build time.  That means that an 
application's source code may be compatible with a wider range of 
versions of its dependencies than the compiled version. Effectively, 
assuming the correct use of semantic versions, a compiled application 
should be compatible with any version of its dependencies are are equal 
to or greater than the version present in its build environment, but 
less than a version with a higher Major version number.

Because rpm package dependencies don't include the version of each 
dependency present in the build environment, some dependency information 
may be hidden.

In a distribution that is Major-version stable (or "compatible interface 
stable"), the only supported configuration is fully patched.  It is not 
guaranteed to be safe to install or update an individual package without 
also patching all installed packages. It is possible to install a new 
package and find that it does not work because it depends on a package 
that was already installed, which satisfies the rpm dependency 
information, but which is older than the version that was present in the 
new application's build environment and does not provide all of the 
features and interfaces defined during that build.

    As an illustration, assume that on the day a Fedora release is
    published (day 0), a repository is fully consistent. Everything has
    been built together, so every package that expresses a dependency is
    implicitly a dependency on a package of the correct version. On day
    1, an update is published for libFoo; it is updated from version
    1.1.0 to version 1.2.0, which adds some new library functions and
    changes some macros to use them. That update does not, however,
    change the soname, and the library does not provide a symbol map for
    internal versioning. On day 2, an update is published for appBar; it
    is updated from version 1.0.1 to version 1.0.2. appBar depends on
    libFoo.

    Is it safe for users who installed appBar on day 0 to update from
    version 1.0.1 to 1.0.2?

    Most users would conclude that it is, because that update is a
    patch-update meant to address a security problem. However, appBar
    has a hidden dependency. It visibly depends on libFoo, but it
    invisibly depends on version >= 1.2.0. Users who update appBar and
    don't fully patch their system at the same time might see errors as
    a result.

In a distribution that is Minor-version stable (or "feature stable"), it 
is reasonably expected to be safe to selectively install individual new 
packages and updates.  All of the dependencies should match the Major 
and Minor versions that were present in the build environment, because 
those are stable during the life of the release.

[Gordon Messmer]

As a practical example, if Fedora prefers stability for application 
packages over early updates, I'd like to use Thunderbird as an example 
because the upstream vendor supports two releases concurrently for a 
predictable period of ~ 12 weeks.

In practice, maintaining that package might look like this:

Thunderbird update policy:

Thunderbird releases follow the Mozilla ESR calendar [1] relatively 
closely.  Each stable release series is supported for a little over a 
year, and each release lifecycle overlaps with the subsequent release 
for at least 12 weeks to allow users a transition period that provides 
time to test and adapt to breaking API changes.

For Fedora releases, Thunderbird should rebase to a new stable release 
in Rawhide as early as possible, while stable Fedora releases should 
remain on the old stable series for as long as possible.

Firefox ESR releases occur every four weeks (five in some cases), on 
Tuesday, and Thunderbird will release shortly thereafter.  The release 
cadence makes package maintenance fairly predictable.

Roughly every four weeks, the newest release [2] should be built in 
Rawhide, and in any branched but not yet final Fedora release.

If that release is a new release series, a self-contained change 
announcement should be added to the upcoming Fedora release proposals, 
possibly referring to the changes documented in the webextension API 
guide [3].

If there was also a release from the previous release series, that 
release should also be built in each active Fedora release. However, if 
there was no release from a prior release series, then the newest 
release should also be built in each active Fedora release.

1: https://wiki.mozilla.org/Release_Management/Calendar

2: https://www.thunderbird.net/en-US/thunderbird/releases/

3: https://webextension-api.thunderbird.net/en/latest/index.html

[Adam Williamson]

On Sun, 2022-11-27 at 23:35 -0800, Gordon Messmer wrote:
>  I'd like to suggest specific updates (I'd feel more like I
> was 
>  contributing to a productive conversation and less like I'm merely 
>  complaining), but I'm a little unclear FESCo's point of view. I'll do my 
>  best.
>  
>  Given the discussion so far, I feel like Fedora effectively allows at 
>  least leaf nodes to update without significant oversight, and I wonder 
>  if it would be useful to reflect that distinction more fully in the 
>  philosophy statement. 
I'm not sure I agree with this, because practically speaking, there's
very little "oversight" of anything in Fedora. Fedora is heavily trust-
based; we do not have the resources (or, really, the inclination) to
have a Fedora Police Force running around enforcing policies. To say
this in *every* policy is kinda redundant, and may give the wrong
impression. People are supposed to follow the policies because the
policies are there and we expect folks to work in good faith. If that
doesn't happen, the whole system has kinda broken down, and writing
down notes about what gets "enforced" and what doesn't might give the
wrong impression.

There are also leaf nodes we care about a lot. Firefox is a leaf node,
more or less, but we do care about updates to it because it's an
*important* leaf node. Ultimately you use Fedora to *do stuff*, and a
lot of the doing-stuff packages are leaf nodes...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Gordon Messmer]

On 2022-11-28 08:51, Adam Williamson wrote:
>  I'm not sure I agree with this, because practically speaking,
> there's
>  very little "oversight" of anything in Fedora. 

Is that a disagreement, though?  When I say that packages are allowed to 
update without oversight, what I mean is that while the policy says that 
should or must request approval from FESCo for some types of updates 
(oversight), that doesn't happen in practice.  The changes I suggested 
reflect the current practice, I think.

But, again, I'm not entirely sure, and I'm also not entirely sure that 
current practice is what we actually want as a project.


>  writing
>  down notes about what gets "enforced" and what doesn't might give the
>  wrong impression. 

Right.  And that why I'm proposing that some of the language that 
currently suggests enforcement and oversight be removed.


>  There are also leaf nodes we care about a lot. Firefox is a leaf
> node,
>  more or less, but we do care about updates to it because it's an
>  *important*  leaf node. Ultimately you use Fedora to*do stuff*, and a
>  lot of the doing-stuff packages are leaf nodes... 

Firefox might not be a good example of your intent in this case because 
it gets Major-version updates (in the semver sense: API-breaking 
updates) essentially as early as possible, without any FESCo approval.  
Yes, of course we care that it works, but it's an example of a package 
that doesn't reflect the policy in any way.  And I think everyone agrees 
that it shouldn't.  For the non-ESR release branch, the current practice 
is the only workable one.