Pascal, Huzaifa I seem to have forgotten to sign my Fedora CLA and as a result can't log in to the wiki to make changes. Could one of you guys take care of this week's FWN. I attach my edited Developments beat and also inline below. Things are a bit hectic here with snow removal. I'm going to try and get a fax of the CLA off to Red Hat (I could swear I've already done this, but whatever) but probably I won't be able to log in for a bit. Apologies and Happy Holidays! === Nautilus Spatial-mode Flamewar === The tired, old topic of whether <code>nautilus</code> 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 <code>nautilus</code> 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. [[ChrisAdams|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 [[JeffSpaleta|Jef Spaleta]]. [[DimiPaun|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 [[TomasTorcz|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." [[JoonasSarajärvi|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 [[AlexanderLarsson|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 <code>GUI</code> <pre>Nautilus -> Preferences -> Behavior -> Always open in browser windows</pre> or else change the <code>GConf</code> setting using <code>gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true</code> As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others [[MatthiasClasen|Matthias Clasen]] suggested[9] that anyone wishing to make permanent change to the default settings could create a <code>sabayon</code> 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 === [[NicolasMailhot|Nicholas Mailhot]] ensured[1] that everyone was made aware of the new font package naming rules for <code>Fedora 11</code>. 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 === [[RayVanDolson|Ray Van Dolson]] asked[1] for some information on identifying the current (co)maintainers of the <code>proftpd</code> 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 [[PatriceDumas|Patrice Dumas]] with links to <code>PackageDB</code> 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 [[KevinFenzi|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]]. [[PatriceDumas|Patrice Dumas]] and [[DennisGilmore|Dennis Gilmore]] remembered[2] that a re-review followed by EOL of the old package was the current practice. [[JasonTibbitts|Jason Tibbitts]][3] and [[JesseKeating|Jesse Keating]][4] referenced <code>IRC</code> discussions of the practice and its advantages in checking the <code>Obsoletes</code> and <code>Provides</code> in discussion with [[JochenSchmitt|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 === [[RexDieter|Rex Dieter]] announced[1] that a bump to <code>exiv2-0.18</code>[2] would occur soon including a soname bump. [[JonCiesla|Jon Ciesla]] offered to help and Rex produced[3] a quick list of dependent applications. When [[MatejCepl|Matej Cepl]] struggled with some odd results [[MichaelJChudobiak|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 == [[MichaelSchwendt|Michael Schwendt]] discovered[1] that a rename had been performed[2] some time ago so that there was no <code>wxGTK2-devel</code> package available. [[DanHorák|Dan Horák]] explained[3] that only <code>audacity</code> was affected. There was[4] some discussion about whether versioned <code>Provides</code> 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 [[RichardHughes|Richard Hughes]] for packagers to fix "isane descriptions" in their package summary text. <code>Enlightenment</code> 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 <code>UTF-8</code>. A heated discussion followed[3] in which [[NicolasMailhot|Nicolas Mailhot]] deprecated the possible development of a "broken application-side transcoding system". He advocated the use of <code>UTF-8</code> over <code>ASCII</code> 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. [[RichardHughes|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 -- Oisin Feeley http://fedoraproject.org/wiki/OisinFeeley
=== Nautilus Spatial-mode Flamewar === The tired, old topic of whether <code>nautilus</code> 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 <code>nautilus</code> 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. [[ChrisAdams|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 [[JeffSpaleta|Jef Spaleta]]. [[DimiPaun|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 [[TomasTorcz|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." [[JoonasSarajärvi|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 [[AlexanderLarsson|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 <code>GUI</code> <pre>Nautilus -> Preferences -> Behavior -> Always open in browser windows</pre> or else change the <code>GConf</code> setting using <code>gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true</code> As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others [[MatthiasClasen|Matthias Clasen]] suggested[9] that anyone wishing to make permanent change to the default settings could create a <code>sabayon</code> 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 === [[NicolasMailhot|Nicholas Mailhot]] ensured[1] that everyone was made aware of the new font package naming rules for <code>Fedora 11</code>. 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 === [[RayVanDolson|Ray Van Dolson]] asked[1] for some information on identifying the current (co)maintainers of the <code>proftpd</code> 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 [[PatriceDumas|Patrice Dumas]] with links to <code>PackageDB</code> 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 [[KevinFenzi|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]]. [[PatriceDumas|Patrice Dumas]] and [[DennisGilmore|Dennis Gilmore]] remembered[2] that a re-review followed by EOL of the old package was the current practice. [[JasonTibbitts|Jason Tibbitts]][3] and [[JesseKeating|Jesse Keating]][4] referenced <code>IRC</code> discussions of the practice and its advantages in checking the <code>Obsoletes</code> and <code>Provides</code> in discussion with [[JochenSchmitt|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 === [[RexDieter|Rex Dieter]] announced[1] that a bump to <code>exiv2-0.18</code>[2] would occur soon including a soname bump. [[JonCiesla|Jon Ciesla]] offered to help and Rex produced[3] a quick list of dependent applications. When [[MatejCepl|Matej Cepl]] struggled with some odd results [[MichaelJChudobiak|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 == [[MichaelSchwendt|Michael Schwendt]] discovered[1] that a rename had been performed[2] some time ago so that there was no <code>wxGTK2-devel</code> package available. [[DanHorák|Dan Horák]] explained[3] that only <code>audacity</code> was affected. There was[4] some discussion about whether versioned <code>Provides</code> 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 [[RichardHughes|Richard Hughes]] for packagers to fix "isane descriptions" in their package summary text. <code>Enlightenment</code> 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 <code>UTF-8</code>. A heated discussion followed[3] in which [[NicolasMailhot|Nicolas Mailhot]] deprecated the possible development of a "broken application-side transcoding system". He advocated the use of <code>UTF-8</code> over <code>ASCII</code> 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. [[RichardHughes|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
_______________________________________________ Fedora-news-list mailing list Fedora-news-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-news-list
