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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux