Re: Summary of the 2008-03-11 Packaging Committee meeting

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

 



Le Ven 14 mars 2008 11:02, Michael Schwendt a écrit :
> On Thu, 13 Mar 2008 23:27:03 +0100, Nicolas Mailhot wrote:
>
>> Le jeudi 13 mars 2008 à 22:51 +0100, Michael Schwendt a écrit :
>>
>> > I'd like to understand the goal/the purpose of permitting unusual
>> > characters in RPM package file names and how it relates to
>> i17n/l10n
>> > and file names in general.
>>
>> For the record: I care nothing for the rpm file name.
>
> The rpm file name is at the frontier. It is displayed to the user by
> the installer, by package tools, and it may need to be input at the
> command-line or in graphical apps.

Nope. You intentionally keep confusing the project name, the package
name, the filename, commands, data, display, storage, technical
artifacts, human communication, what is done Fedora-side with what is
done upstream, etc.

The filename is not the package name. It's a technical artifact,
plumbing.

The package name is not in the Fedora perimeter.
The package name is a pointer to upstream. It's about the only bit of
the package we have no say on with the License bit. Either we accept
upstream choices or we don't package the result at all. (modulo minor
tweaks such as capitalization, but none of the suggested transforms
are minor tweaks).

We can decide comment rules, naming rules, versionning rules etc for
stuff we produce ourselves. When we repackage other people's stuff we
have to accept their core choices and there's little more core than
how someone calls himself. You can regret them but that's about how
far you can go. If you don't like them you can write your own solution
yourself. That's basic ethics.

> If the name of a package contains
> non-ASCII glyphs or consists solely of non-ASCII characters, there is
> no
> "name" the user can refer to. It is a serious usability regression. It
> also makes community support more difficult. Translation or transition
> is
> needed to turn it into something recognisable. See unreadable command
> file names in system scripts, e.g., would be a nightmare.

It's up to the packagers to see if all the very real problems you
point out are sufficient reason not to package something. Lack of
translation is not a showstopper. Otherwise minefield would have been
kicked out of rawhide. I can assure you an English-only UI in the main
web browser is many orders of magnitude more user impacting than what
all you rant on. (in other words, get a grip)

>> No upstream is
>> going to complain about the package file name. Upstreams are
>> sensitive
>> to their project name, which we unfortunately map into filenames
>> when we
>> generate rpms.
>
> If upstreams are "sensitive", they choose a project name which, at the
> implementation level, is compatible with their target group. If the
> underlying file-system supports UTF-8, hardly anyone would care about
> data files that use multi-byte characters. But the user interface is
> what matters.
>
> We do have policies already about using American English in spec files
> as opposed to British English and other languages. Package
> descriptions
> must be in US English, too, and other languages are secondary only.

This is Fedora-produced material. Our level of control on
Fedora-produced material is higher than on upstream-produced material.

> What would happen during package review with an application that is
> completely in German without any English message object files?

It would be accepted. Period. As long as there are Fedora users and a
Fedora packager there is no reason to discriminate against
German-speaking users for the sake of English-speaking users. We have
many many apps which are not translated in all the languages Fedora
spans.

If you can't understand an app you don't have to install it. Same rule
for everyone. You question reeks of crass prejudice. What do you think
langpacks and dictionnaries are? They're locale-specific Fedora
components that can be totally uncomprehensible and useless to
English-only speakers.

>> > I have the feeling that at first the door
>> > for package names with multi-byte characters is opened, and as a
>> next
>> > step, file names in packages will use multi-byte characters, too.
>>
>> This ship has sailed long ago and our official policy already
>> explicitely allows this. In fact it goes further: filenames MUST be
>> UTF-8, so a latin-1 filename that goes beyond the core latin subset
>> common to UTF-8 and latin-1 is forbidden.
>
> Any ship can be sunk.

The factual argument being?

> A policy can be revisited/refined, because non-ASCII glyphs in file
> names
> are a problem in a default setup that doesn't display them correctly
> and
> that requires extra efforts to enter them.

These are bugs to be fixed.

>> We already ship lots of code commented in other languages than
>> English
>> (for example, OO.o IIRC) so this ship also sailed a long time ago.
>
> That's still only due to its Star Office history, isn't it?

No.

That's due to the fact Fedora is a *distribution*, built from *other*
*entities* material, material that may be produced by non-English
speakers at the destination of non-English speakers, using non-English
languages, and it's totally *useless* to rant on the choices those
entities should or should not have done since we benefit *hugely* from
not having to do the work ourselves alone.

With your logic OpenOffice.org would have no place in Fedora.
Fortunately others have been less dogmatic and admitted that valuable
material does not have to be English only (even if pure English would
have been more convenient).

The price of working with others is respect. Stomping on other people
naming choices is utter disrespect. That's not how you build an
healthy FLOSS community.

-- 
Nicolas Mailhot

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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