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" 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. 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
