On Wed, May 10, 2017 at 4:15 PM, Richard Ryniker <ryniker@xxxxxxxxxxxx> wrote: > I agree with you that Firefox is an important resource that Fedora should > deliver, but think a criterion that failure to supply the same default > package set for all (blocking) architectures will do more harm than good. > > Release criteria should focus on the quality of what is delivered in a > release. They should not be a specification for its content, or a > mechanism to allocate developer resources. > > The "critical path" concept already defines a set of resources considered > essential to a usable Fedora release. A Web browser (in workstation > builds) is an essential resource - Fedora could specify Firefox for this > role, or accept any usable browser to meet this need, even different > browsers on different architectures. > > The major problem with a heavy-handed "same default package set" We've aimed for a consistent experience across Fedora for numerous things whether it be spins (everything has to have SELinux for example) and I don't see why it should be any different for say an expected package set on an architecture for a particular Spin/Edition of Fedora and hence I don't see it as heavy handed. > criterion is the delay that might cause - especially if upstream > resources are required. While Fedora waits for the last "default set" > package to be fixed for some architecture, everything else in the frozen > release ages. Sure, more recent package builds can accumulate in updates > repositories, but then, when the release actually happens, users perform > their first upgrade and wind up with a system too much different from > what was actually tested for that release. > > In an extreme situation, a release could be nearly impossible due to > dependency cycles. You'd need to provide specific examples for "extreme" as this has not happened in recent Fedora history (at least back to F-21) > I think it better to agree the same default package set is desirable, but > not essential, in a release. Judiciously add packages to the "critical > path" set when a case is made that they are essential to Fedora. In > other situations, argue for an exception to be made to block a release > because, though perhaps not critical, some feature is so important to > such a large group of users that it causes more damage to release without > support on some architecture than to wait until it is fixed. > _______________________________________________ > test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
