On 05/21/2009 04:31 AM, Josh Boyer wrote:
On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote:
That's the problem with email threads that are so large. People miss things
because they don't always read every single email, regardless of what position
in the thread it was. Even if they do, they might be busy replying to flames
and other useless junk instead of important stuff.
[...]
https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html
Note, as mentioned there, the questions I raised in the original
ticket[1]_ still weren't answered either. Those questions were about
applying the policy to real packages to delimit the intended scope.
Here's a summary:
The policy contains:
"""
* Flags used for gaming purposes, such as a game that uses flags to
represent country/language selection
In this specific case, the flag usage is not acceptable. The flag use
here is almost certainly not essential.
"""
Is the flag usage not-acceptable because the flag is being used for
language selection? Or is it not-acceptable because the flag is being
used in a game? If it's because it's in a game the example is broader
than the policy. A WWII simulation would have a real justification to
use flags from the countries involved. freeciv gives the player the
option to play as a historical leader from an actual country with
appropriate background. These seem to be technically (user interface
requires something that denotes a specific country) and substantively
(other information linking to real geopolitical entities is given)
necessary.
I go on to ask about games which need to have team identifiers and
presently use flags but don't have other identifying elements as a followup.
[...]
>> 7. What to do with a package that wont work without flags?
7) As FESCo for an exemption under the current guideline.
Note, the policy portion of the current document and the examples are in
conflict over whether FESCo needs to be asked for an exemption and
should be clarified along with the other changes made to it:
The policy says this:
"""
When a package contains flag images [...] where such use is not
technically or substantively essential to the package, those flag images
must be placed in an -flags subpackage.
"""
In this section the policy is saying which packages it applies to.
Packages not covered by this statement should not be handled by the
policy. (ie, if flag usage is technically or substantively essential
than the policy does not apply to it).
However, in the Examples area it says:
"""
Flags used for educational purposes, [...]
In this specific case, the flag usage would be acceptable. Instances
like this must be examined on a case-by-case basis by FESCo, but they
will often be acceptable because they are substantively essential to the
core function of the package.
"""
Instead of saying that those types of packages are not covered by the
Policy, it is saying that those types of packages are covered by the
Policy but are likely candidates for an exemption due to the technical
and substantive clause. There are two ways to fix that:
1) Change the example to say "In this specific case, the flag usage
would be acceptable because they are substantively essential to the core
function of the package."
2) Move the technical and substantive clause into the exceptions section
of the policy:
"""
== Exceptions ==
Any packager who feels that they should be granted an exception to this
policy should escalate the issue to FESCo for review. Common reasons
for exceptions are that the flag usage is technically and substantively
required by the package.
"""
When designing Fedora Packaging Guidelines we try to avoid having
guidelines that require exceptions to be granted if we can elucidate the
reasons that an exception would be granted. This leads to less of a
burden on FESCo to review the exceptions and better expectations by
packager and reviewer of what is meant by the guidelines. For those
reasons, #1 seems like the better option to me. Since this is a FESCo
policy, not a Packaging Guideline, you'll need to decide if that's a
goal for yourself, though.
.. _[1]: https://fedorahosted.org/fesco/ticket/110
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
