From Fedora Project Wiki

< FWN‎ | Beats

Revision as of 17:01, 22 December 2008 by Ush (talk | contribs) (FWN #157 spellchecked pass1)

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Nautilus Spatial-mode Flamewar

The tired, old topic of whether nautilus should use "spatial-mode" as a default was re-opened[1] by MarkG85 in the form of a request for list subscribers to "vote" on the mailing list for a reversion to "browser-mode". In spatial-mode nautilus opens a new window for each directory unless one middle-clicks or holds the shift key down.

It was pointed out by several contributors that voting "+/- 1" was not a recognized way to achieve change within the Fedora Project. Chris Adams asked[2] if he and his friends "[...] should [...] all spam fedora-devel with +1' and metoo' to change the default background color? What if it is 20 friends, or 100, or 500?" A similar point was made[3] by Jef Spaleta.

Dimi Paun expressed[4] frustration with what he charcaterized as "lame community involvenment" and several personal attacks were made on both the maintainer and other contributors who had deprecated the attempt to take a mailing list vote. After tempers had flared Jeff commented[5]: "Noone has figured out how to write a markup language for human intention...and as a result any passionate discussion degrades severely as we are wired to read intention but without body language and vocal ques...we absolutely do it wrong when relying solely on written language. Even more so with English! If we mandated everyone encode thought into Lisp we'd be having more constructive discussions (and less of them). The productivity of the list would be through the roof."

In response to a challenge to detail some advantages of spatial-mode Tomas Torcz was among those who offered[6] that the persistent screen placement of directory windows was a major advantage. He also suggested a way to avoid leaving multiple windows open: "When I open new window and don't want parent directory open, I just open with middle button. Some people prefer Shift+click in this situation. I never has to use `Close all parent folder' (ctrlshift-w), but I aware it exist." Joonas Sarajärvi confirmed[7] the persistence as an advantage: "[...] the state of each folder is persistent. Every window opens in the same view that it had when I reopen them. I can have appropriate zoom levels and views for every directory I commonly use."

Very much later in the thread, after he had been referred to several times, the package maintainer Alexander Larsson replied[8] that he was unconvinced both by the tone and content of the argument that there was a case to be made for changing the default.

It is possible to choose which behavior one wants by at least two methods. One can either use the GUI

Nautilus -> Preferences -> Behavior -> Always open in browser windows

or else change the GConf setting using

gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true

As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others Matthias Clasen suggested[9] that anyone wishing to make permanent change to the default settings could create a sabayon profile.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html

Font Package Naming Guidelines

Nicholas Mailhot ensured[1] that everyone was made aware of the new font package naming rules for Fedora 11. These will help break up large font packages in order to allow users to obtain fonts from desired families without imposing a large download burden.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html

How to become a Co-Maintainer

Ray Van Dolson asked[1] for some information on identifying the current (co)maintainers of the proftpd package, the procedure to become a co-maintainer and the abilities to push bugfixes which this would confer upon him if the primary maintainer were absent.

A full answer was provided[2] by Patrice Dumas with links to PackageDB and the policies on the wiki regarding non-responsive maintainers.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html

Proposed Package Re-Naming Guidelines

Feedback was requested[1] by Kevin Fenzi on a draft guideline concerning the re-naming of packages either as a result of upstream action or locally to adhere to the NamingGuidelines.

Patrice Dumas and Dennis Gilmore remembered[2] that a re-review followed by EOL of the old package was the current practice.

Jason Tibbitts[3] and Jesse Keating[4] referenced IRC discussions of the practice and its advantages in checking the Obsoletes and Provides in discussion with Jochen Schmitt. Jochen was concerned[5] that the process be kept lightweight as opposed to a full review.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html

Exiv2 Bump in Rawhide

Rex Dieter announced[1] that a bump to exiv2-0.18[2] would occur soon including a soname bump. Jon Ciesla offered to help and Rex produced[3] a quick list of dependent applications.

When Matej Cepl struggled with some odd results Michael Chudobiak answered[4] that the API had changed a good deal.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02061.html

[2] Exiv is a command-line utility for examining EXIF and IPTC metadata of images.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html

= wxGTK2 to wxGTK Re-name

Michael Schwendt discovered[1] that a rename had been performed[2] some time ago so that there was no wxGTK2-devel package available. Dan Horák explained[3] that only audacity was affected. There was[4] some discussion about whether versioned Provides should be kept indefinitely.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html

RFC: Description Text in Packages

Follow-up action (see FWN#153[1]) was requested[2] by Richard Hughes for packagers to fix "isane descriptions" in their package summary text. Enlightenment was singled out as an example of an undesirable multi-page description. Richard also asked for comments on how bullet-points should be represented and the use of UTF-8.

A heated discussion followed[3] in which Nicolas Mailhot deprecated the possible development of a "broken application-side transcoding system". He advocated the use of UTF-8 over ASCII for several reasons including supporting the default Asian locales. Paragraph boundaries and lists were also mentioned[4] as a special area of concern.

This is a long and painful thread to read which expresses a conflict between constraints imposed by PackageKit and how things are currently done. Packagers should probably skim it to determine what final decisions are going to be made. Richard Hughes seemed[5] to decide to implement what seemed to him to be sane changes to gnome-packagekit in which "If you're [g]oing to use [UTF-8 representations of skull-and-crossbones and radiation-hazard symbols] in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it."


[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html