On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
