Re: Should the policy documents better reflect real package maintenance practice?

[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).

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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 

Re: Should the policy documents better reflect real package maintenance practice?

[Kevin Fenzi]

On Fri, Nov 25, 2022 at 12:20:10AM +, Gary Buhrmaster wrote:
> On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý  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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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 
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.


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Gary Buhrmaster]

On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Adam Williamson]

On Thu, 2022-11-24 at 16:26 -0500, Stephen Smoogen wrote:
> On Thu, 24 Nov 2022 at 13:12, Gordon Messmer 
> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Stephen Smoogen]

On Thu, 24 Nov 2022 at 13:12, Gordon Messmer 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Adam Williamson]

On Thu, 2022-11-24 at 07:34 +, 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 

Re: Should the policy documents better reflect real package maintenance practice?

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Richard Shaw]

On Thu, Nov 24, 2022 at 9:12 AM Petr Pisar  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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 . 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Tomáš Popela]

On Thu, Nov 24, 2022 at 2:34 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue