Kevin Fenzi wrote:
> * It means things will likely be broken longer as there is less urgency
> to fix them quickly.
This means less stress for maintainers who are usually not working full time
on Fedora.
I don't see why a broken dependency in some leaf application that happens to
be included on a release-blocking Edition or Spin needs to block the whole
Rawhide compose. Such breakage is normal in a development version of a
distribution, it happens even in Debian sid/unstable that probably has more
daily users than Rawhide.
> * Shipping things out means we can't easily untag or revert packages
> with using Epoch's much more commonly.
That is due to the "Rawhide can never go backwards" policy, which I still do
not understand the point of, especially in the light of "distro-sync" having
been supported by both the old yum and the new dnf for years.
We allow even updates-testing to go backwards, so why not Rawhide? I think
the only place we should ever enforce upgrade paths in is stable releases.
Rawhide can go backwards just fine. The fix is simply to use dnf distro-sync
instead of dnf update. (Enforcing the upgrade path from stable releases to
Rawhide may make sense to prepare for when Rawhide will eventually be
branched into a release, but what is the point of enforcing the upgrade path
from Rawhide at day d to Rawhide at day d+1? Rawhide users can just be
taught to use distro-sync, and users of stable releases will never see this
upgrade path "breakage".)
Red Hat Linux and early Fedora had worked fine for years without that
policy, and Epoch was required less often back then.
So please let us just repeal that "Rawhide can never go backwards" policy.
> * It will mean we are not in fact always shipping alpha quality, we
> could be shipping anything.
Even if everything composes, that does not guarantee any level of quality
when you actually try to boot the composes.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
