Re: Defining the future of the packager workflow in Fedora

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

 



Vít Ondruch wrote:
> It depends how you maintain your packages. My guess is (and I am sorry
> if I am mistaken) that you don't follow the
> 
> https://fedoraproject.org/wiki/Updates_Policy#Philosophy
> 
> If you followed this policy, then you would touch the stable branches
> just rarely and therefore keeping them fast forwardable would be just
> waste of time.

It depends on what, how, and when upstream releases.

If we have different upstream releases in different Fedora releases, then of 
course those releases should have different specfiles. But if we are 
shipping the same upstream release, I don't see why I should clone the 
specfile n times.

There are many possible reasons for shipping the same upstream release 
across different Fedora releases:
* There might just not have been a newer upstream release in this time.
* Heck, there might even not be any new upstream releases at all anymore,
  which is typical for compatibility libraries such as qt3.
* The newer upstream releases might be bugfix-only releases applicable to
  stable Fedora releases just fine. (In other words, there might just not
  have been a newer upstream feature release in this time.)
* It can be necessary for security reasons to upgrade to a newer feature
  release. (E.g., this is the case for browser packages such as firefox or
  chromium. Also for qt5-qtwebengine to some extent, though at least Qt
  maintains LTS branches including QtWebEngine security backports these
  days.)
* It can be necessary to upgrade a library to a backwards-compatible feature
  release because applications are depending on a newer version. (The main
  example there is KF5 (KDE Frameworks 5), which does not maintain bugfix
  branches at all. But, e.g., Qt also sometimes needs to be upgraded to meet
  application demands.)
* There can be other reasons why backporting the newer feature release is a
  good idea. (E.g., if it only adds features and does not remove or break
  anything, and if it has been thouroughly tested for regressions without
  any being found, why would it not be OK to push?)

That said, I am not a fan of the Updates Policy as written because it is 
written in the form "do not push new feature releases as updates unless X, Y 
or Z", whereas I think it should be "do push new feature releases as updates 
unless X', Y' or Z'". Still, I think we all agree that some feature releases 
just need to go out (e.g., because they include security fixes that are 
impractical to backport) whereas some definitely must never go out as 
updates (e.g., anything that breaks user configuration).

        Kevin Kofler
_______________________________________________
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




[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