From Fedora Project Wiki

< FWN‎ | Beats

(Development beat 167 pass 1)
Line 6: Line 6:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Orphans Purged ===
=== GSoC InstantMirror ===


It sounded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00093.html</ref> like Dickensian cruelty when [[User:Jkeating|Jesse Keating]] announced that he would be purging the orphans. All that it meant however was that those packages which were not blocked and had no owners would be "[...] blocked, and will not be shipped with F11." The initial list mistakenly listed <code>EPEL</code> packages and a shorter revised list was posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00103.html</ref>.
[[WarrenTogami|Warren Togami]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00873.html</ref> for any interested parties to get involved with a GSoC<ref>http://code.google.com/soc/</ref> project to improve repository replication to mirrors.


A follow-up posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00474.html</ref> states that packages listed therein will be removed on 2009-03-09 unless volunteers are found to maintain them.
<references/>
 
=== Enhance Anaconda to Enable Repositories As Needed ? ===
 
[[JudCraft|Jud Craft]] reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00921.html</ref> that installing from the <code>Fedora 10</code> DVD with the <code>fedora-updates</code> repository enabled resulted in a broken <code>NetworkManager</code> due to a missing dependency on <code>libudev.so.0</code>. Jud pointed out<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00929.html</ref> that although he could install the missing library from the DVD the situation would present a serious problem to anyone that tried "[...] a network install with updates [...] the result (a system without network access) can't be fixed without A) network access, or B) another Fedora image (also possibly requiring more network access)."
 
In answer to questions from [[User:Jspaleta|Jef Spaleta]] Jud revealed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00938.html</ref> that: "[libudev.so.0] doesn't seem to actually be installed by the stock F10 image.  If I do a plain install (no updates), NetworkManager works fine.  Running a `yum update' then pulls down all the updates, as well as `Install libudev0'.  So at some point I suppose NetworkManager picked up a dependency on libudev0, but for some reason updating during the installation process doesn't pull this new package in." [[User:Kkofler|Kevin Kofler]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00944.html</ref> and [[User:Jkeating|Jesse Keating]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00947.html</ref> both pointed out that: "[T]he updates repo isn't the Everything repo.  To really do a proper install with updates you have to enable both the Updates repo and the Everything repo." Kevin added that this was why the install from DVD with updates enabled was not an officially supported method.
 
Several people, including [[User:Thl|Thorsten Leemhuis]], suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00953.html</ref> that modifying the <code>anaconda</code> installer to be aware of which repositories depend on each other would be useful. [[User:Jkeating|Jesse Keating]] was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00955.html</ref> not averse to the idea as long as it could be done in a "[...] distro agnostic way. Avoiding hardcoded hacks specifically for Fedora is one of the goals of anaconda upstream."


<references/>
<references/>


=== Fedora 11 to Ship Tiger VNC ===
=== Password Resets and Inactive Accounts ===
 
When [[User:Mmcgrath|Mike McGrath]] was perturbed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00509.html</ref> that so many FAS account holders had failed to reset their passwords recently a discussion of the entanglement of active account status and passwords followed.
 
Many respondents posted that they had received the email notifications but had not needed to, or had not had time to, perform their password reset.


[[AdamTkac|Adam Tkac]] wrote<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00213.html</ref> to explain why he had decided "one minute before the beta freeze" to replace <code>TightVNC</code> with the <code>TigerVNC</code> fork. Adam has a history of very actively seeking to merge improvements upstream which in the past led<ref>http://fedoraproject.org/wiki/FWN/Issue119#Baracuda_To_Replace_VNC_.3F</ref> to the replacement of <code>RealVNC</code> with <code>TightVNC</code> when it seemed that the latter was more willing to evolve. The glacial pace of <code>RealVNC</code> development seemed to be correlated with the presence of a non-Free enterprise edition. Adam reported that unfortunately a lack of co-ordination of the <code>TightVNC</code> project had led to the <code>TurboVNC</code> and <code>TightVNC</code> projects deciding that a fork was necessary. An initial mail posted<ref>http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.LFD.2.00.0902271116020.25749%40maggie.lkpg.cendio.se&forum_name=tigervnc-users</ref> by PeterÅstrand on @tigervnc-users provides some more details.
[[https://bugzilla.fedora.us/wiki/TomLane|Tom Lane]] worried that forcing periodic password resets caused people to weaken security by writing down their passwords but [[User:Bruno|Bruno Wolf III]] argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00612.html</ref> that a potentially bigger threat might be "[...] someone forging messages from Mike with deceptive URLs that trick people into changing their passwords using a hostile proxy. Doing things in the current manner is training people to get fooled." He added that cryptographically signing the reset messages was important.  


One specific outcome anticipated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00217.html</ref> by KingInuYasha was a "[...] proper implementations of VNC 4 for UNIX like systems [...] Having a VNC implementation that actually is kept up to date with the VNC protocol and is optimized with extensions is something I have been waiting for awhile now."
[[User:Till|Till Maas]] requested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00710.html</ref> consistent titling of the password reset notification emails, suggested extending the grace period beyond two weeks and asked that the notification contains the information that the contents of the user's fedorapeople.org home would be moved.


Another hint of good things which may come from a more rapid pace of development was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00221.html</ref> when Daniel Berrange asked about Adam's plans to include the <code>VeNCrypt</code> server-side SSL/TLS extension. This would result in a "[...] consistent TLS extension that's inter operable across all the VNC clients & servers in Fedora." Daniel also mentioned that he had "[...] recently defined & implemented another VNC auth extension based on SASL. This provides for a good extendable authentication capability, most importantly including GSSAPI Kerberos for single sign on. I've got it implemented for QEMU, KVM, GTK-VNC and VINO already, so again it'd be good to plan for adding it to TigerVNC too so we have a widely interoperable strong authentication system."
[[User:Mmcgrath|Mike McGrath]] and others explored<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00779.html</ref> possible grace periods and numbers of warning emails.


All in all it looks as though contrary to their slogan "The VNC that bites" TigerVNC will be superb.
[[User:Pertusus|Patrice Dumas]] asked why there was a password reset at all and was answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00658.html</ref> by [[User:Jkeating|Jesse Keating]] that it was "[...] the best way Infra has today to discover all the active and inactive accounts." In response [[User:Toshio|Toshio Kuratomi]] pointed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00677.html</ref> to an open ticket which nominally deals with how long accounts should be left open if passwords have expired but had become<ref>https://fedorahosted.org/fedora-infrastructure/ticket/1237</ref> an investigation of how account inactivity can be determined.
 
After [[User:Mmcgrath|Mike McGrath]] explained that "[...] we've got thousands of contributors, relatively few of them actually commit to cvs.  So we could go around to figure out how to make all of our various auth points report back but that's a lot of work.  The account system is the only common point of entry for every contributor [...]" [[ChristopherAillon|Christopher Aillon]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00812.html</ref>: "So let's require to them to simply _log in_ to FAS to reset the timer (you need to do that to change passwords, anyway!)."


<references/>
<references/>


=== Ready for a New RPM Version ? ===
=== Mono Conflagration Jumps to Blog ===


On 2009-02-26 [[PanuMatilainen|Panu Matilainen]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02117.html</ref> if it would be possible to introduce <code>RPM-4.7</code> at this late stage of the <code>Fedora 11</code> release cycle. This new version decreases memory use and improves performance. Panu emphasized that it was not as large an upgrade as the "[...] 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year [.]"
Following the FESCo decision not to replace <code>rhythmbox</code> with <code>banshee</code> as the default media-player in <code>Fedora 11</code><ref>https://fedoraproject.org/wiki/FWN/Issue166#Fedora_11_Default_Mediaplayer_Not_Banshee._Mono_to_Blame_.3F</ref> some follow-up clarifications were made by parties to the discussion and the conflagration jumped between @fedora-devel and the personal blog of [[User:Dnielsen|David Nielsen]], the <code>Banshee</code> ex-maintainer and perhaps the main force behind the Mono SIG<ref>https://fedoraproject.org/wiki/SIGs/Mono</ref>.


[[User:Notting|Bill Nottingham]] was among those who expressed concern that <code>rpm-4.7</code> would be completely ready for the final release of <code>Fedora 11</code>. He also wondered if there would be incompatibilities with previous <code>rpm</code> version. Panu answered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02161.html</ref> that <code>rpm-4.7</code> was expected to be ready for the final release and that incompatibilities would only result if packagers used the <code>POSIX</code> file capabilities. This latter is protected against with an <code>rpmlib()</code> dependency.
[[User:Notting|Bill Nottingham]] put forward<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00529.html</ref> a concise time-line which attempted to show that the proposal had been handled in a straightforward and usual manner. Bill noted that the Desktop SIG had expressed<ref>https://www.redhat.com/archives/fedora-desktop-list/2009-February/msg00063.html</ref> a lack of enthusiasm early in the process and that the imminent beta-freeze meant that the decision had to be taken without further prolonged discussion.  


A certain amount of disquiet at the idea of "[g]oing with a beta version of critical infrastructure like RPM [...]" based on the recent changes to RPM was voiced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02134.html</ref> by [[TomLane|Tom Lane]]. Upon a challenge from [[User:Skvidal|Seth Vidal]] some problems with the process of upgrading <code>rpm</code> to handle stronger hashes were listed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02142.html</ref> by [[User:Notting|Bill Nottingham]]. These included including "No solution for handling packages natively on F9" and [[TomLane|Tom Lane]] expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02146.html</ref> on the point: "I'm personally still ticked off that I'm being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages.  I don't have time for that right now.  Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?" The general response seemed to be that developers need to use one of the virtual machine solutions in order to be able to build for <code>rawhide</code>.
[[User:Adamwill|AdamWilliamson]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00526.html</ref> that because <code>Mono</code>'s Microsoft links worried many F/OSS developers it would have been a good idea to address such concerns: "[...] explicitly rather than just pretend they don't exist in your initial proposal (the word 'Mono' does not actually occur a single time in the initial version of the Wiki page you posted)."


A substantial sub-thread on the rate of change in <code>rawhide</code> and whether or not developers should use it or stick to the current stable release with a virtualized instance of <code>rawhide</code> developed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02213.html</ref> following some thoughts from [[User:Adamwill|Adam Williamson]].  
A question put by [[User:Johannbg|Jóhann B. Guðmundsson]] wondered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00523.html</ref> whether there was anything preventing the Mono SIG from creating their own Fedora spin in which <code>banshee</code> was given pride of place as the default media-player. [[User:Rdieter|Rex Dieter]] confirmed that there were no obstacles on this path.


[[User:Sundaram|RahulSundaram]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02156.html</ref> for more information on the use of <code>LZMA</code> compression as this is one of the new features of <code>rpm-4.7</code>. Panu replied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02173.html</ref> <code>LZMA</code> will not be used by default as it would make even the current <code>Fedora 10</code> <code>rpm</code> unable to read packages produced with such compression.  
A proposal to adopt a Code of Conduct modeled upon Ubuntu's was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00498.html</ref> made by [[RichardJones|Richard W.M. Jones]]. He also expressed regret that David was leaving Fedora and apparently moving to <code>Ubuntu</code> as referenced<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/</ref> by a blog entry. Reading the blog suggest that <code>Foresight Linux</code> seems more to David's taste although one comment does point out<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-285</ref> that Ubuntu "[...] head community people have been calling for volunteers to increase the work surrounding Mono and have a huge love for banshee<ref>http://castrojo.wordpress.com/2009/01/11/monodevelop-rockstar-needed-inquire-within/</ref> and Canonical isn’t anti-mono since some of their new job postings desire Mono as a skill<ref>http://webapps.ubuntu.com/employment/canonical_GDOS/</ref>."


A FESCo decision made on 2009-03-06 confirmed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-06.html</ref> that <code>rpm-4.7</code> would be the version shipping in <code>Fedora 11</code>.
[[User:Skvidal|Seth Vidal]] was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00504.html</ref> among those who wondered specifically how such a code could be enforced and also where specifically the Fedora Project could be alleged to have engaged in misconduct on this issue. Reading David's blog seems to suggest both that any rudeness was privately exchanged and that his perception is<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-297</ref> that "[...] Mono isn't welcome in Fedora, and will always be a second class citizen[.]"


<references/>
<references/>


=== Windows Cross-compiler Added to comps.xml ===
=== Documentation Betas ===
 
[[User:Jjmcd|John J. McDonough]] posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00835.html</ref> that owners of major features should review the Beta release notes. [[ScottRadvan|Scott Radvan]] posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00823.html</ref> that the Security Guide<ref>http://sradvan.fedorapeople.org/Security_Guide/en-US/</ref> would benefit from the scrutiny of any interested @fedora-devel readers.


Following from a FESCo 2009-03-06 decision [[RichardJones|Richard W.M. Jones]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00365.html</ref> to add a "Windows cross-compiler" group to <code>comps.xml</code> before the rapidly approaching 2009-03-10 string freeze.
<references/>


[[User:Kkofler|Kevin Kofler]] asked why Richard did not call it "MinGW cross compiler" and Richard responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00384.html</ref> that he wanted to avoid trademarks and leave open the possibility to broaden support to other non-embedded platforms. He came up with either "Consumer cross-compilers (CCC) or Consumer cross-compiler collection (CCCC)." Kevin had some other interesting questions about the legality of possible <code>OS X</code> cross-compilers and the desirability of one group per OS. Richard pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html</ref> to an earlier thread on the latter question.
=== Provenpackager Re-Seed ===


=== Anaconda Default of Separate / and /home Partitions ===
[[User:Jstanley|Jon Stanley]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00555.html</ref> that everyone read the process by which the "provenpackager" group will be repopulated.


A long-standing bugzilla entry was referenced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01903.html</ref> by Lex Hider as background for the idea that <code>anaconda</code> should support separate <code>/home</code> and <code>/</code> partitions in order to support clean installs during upgrades. Lex's detailed post included links to relevant previous discussion.
A request by [[RalfCorsepius|Ralf Corsepius]] for some definitions led [[User:Pertussus|Patrice Dumas]] to post<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00571.html</ref> that: "provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora." Further discussion led<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00581.html</ref> [[User:Mschwendt|Michael Schwendt]] to voice a concern that non-responsive maintainers might be shielded from feedback if provenpackagers step in to update and upgrade packages. [[User:Kkofler|Kevin Kofler]] offered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00718.html</ref> the non-responsive maintainer process as a way to rectify any problems with Bugzilla tickets being ignored.


[[User:Adamwill|Adam Williamson]] was very much in favor of the idea and in response to [[User:Jkeating|Jesse Keating]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01960.html</ref> some heuristics which might allow <code>anaconda</code> to determine the relative sizes of the <code>/</code> and <code>/home</code> partitions. [[User:Bruno|Bruno Wolff III's]] <code>/</code> partition size (circa 40GB) proved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01976.html</ref> to be surprisingly large due to multiple languages installed. [[MichelSalim|Michel Salim]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02167.html</ref> and [[CallumLerwick|Callum Lerwick]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02021.html</ref> both brought up the necessity to have a large <code>/</code> partition in order to be able to run <code>preupgrade</code>.
[[User:Mschwendt|Michael Schwendt]] questioned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00591.html</ref> [[User:Pertussus|Patrice Dumas]] in greater detail as to why provenpackagers and sponsors are not equal sets.


Lex elaborated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02356.html</ref> on possible space requirements for such a scheme.
Further details on how to apply to FESCo to become a provenpackager were elicited<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00594.html</ref> from [[User:Jwboyer|JoshBoyer]] by [[StepanKaspal|Stepan Kaspal]].


In a separate thread MichelSalim asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00871.html</ref> about the preferred way to become a sponsor.
<references/>
<references/>


=== Beta Freeze and String Freeze this Tuesday 2009-03-10 ===
=== Closing Bugs NEXTRELEASE ===


[[User:Ausil|Dennis Gilmore]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00430.html</ref> a heads up on 2009-03-06 that "[...] anything that needs translations needs to be done by COB [Tuesday]. This is a blocking Freeze any packages you need included in the Beta release must be requested via release engineering [.]"  
[[User:Cwickert|Christoph Wickert]] requested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00552.html</ref> that all maintainers (and especially Red Hat developers) would "[p]lease fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!"


A brief amount of confusion occurred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00425.html</ref> due to the misnaming of the day of the week.  [[User:Till|Till Maas]] also wondered exactly what Close Of Business meant exactly for an international project like <code>Fedora</code>.
When [[User:Rsundaram|Rahul Sundaram]] responded that it depended on the seriousness of the bug and complexity of back-porting [[DanielBerrange|Daniel P. Berrange]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00575.html</ref> and [[User:Rakesh|Rakesh Pandit]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00572.html</ref> acknowledged that such complex cases might exist but that suggested that this was often a cop-out which could discourage users.


<references/>
[[User:Katzj|Jeremy Katz]] responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00622.html</ref> "[...] as the person who has apparently pissed you off this morning [...]" and described the case in point as much more complex than Christoph had claimed. It seemed that Christoph's ability to create <code>LiveCD</code> images of <code>Fedora 11</code> using <code>Fedora 10</code> as the development platform had been stymied by changes to <code>syslinux</code>. Jeremy added that even if this single change were reverted Christoph would need a newer <code>kernel</code> and <code>squashfs-tools</code> and more.


=== Fedora 11 Default Mediaplayer Not Banshee. Mono to Blame ? ===
Later Jeremy clarified<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00777.html</ref> that the combination of <code>livecd-creator</code> + <code>mock</code> were complicated by <code>SELinux</code> but that this had been addressed by recent work.


A summary of FESCo deliberations posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00417.html</ref> by BillNottingham stirred DavidNielsen to object that he had not been alerted (as maintainer) that discussion of the <code>Banshee</code> media player was to occur. David also objected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00426.html</ref> that the onus had been placed on him to convince the maintainer of the competitor <code>Rhythmbox</code> package to allow the replacement. He also suggested that the use of the <code>Mono</code> language was a stumbling block due to <code>RHEL</code> eschewing <code>Mono</code>: "[...] RHEL does not ship Mono, if RHEL wants to ship Rhythmbox that is their decision but what Fedora ships should not be. What else are we going to be dictated from above.. who else should bother to make proposals for what they preceive to be improvements?"
One complication is that <code>Bodhi</code> uses NEXTRELEASE even for updates to stable releases. After some confusion on this point LukeMacken posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00672.html</ref> that anyone wanting to change the behavior should file a ticket.


[[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00428.html</ref> that his understanding was that the desire to avoid <code>mono</code> in <code>Fedora</code> is to avoid bloating the <code>LiveCD</code>s with dependencies. The IRC logs bore out<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-06.html</ref> this interpretation with FESCo members explicitly stating that "[...] what its written in should have no bearing on what goes in[.]" It was also clear however that <code>RHEL</code>, as the largest downstream distributor of an OS directly derived from <code>Fedora</code>, would not be ignored.
<references/>

Revision as of 20:00, 15 March 2009

Developments

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

Contributing Writer: Oisin Feeley

GSoC InstantMirror

Warren Togami asked[1] for any interested parties to get involved with a GSoC[2] project to improve repository replication to mirrors.

Enhance Anaconda to Enable Repositories As Needed ?

Jud Craft reported[1] that installing from the Fedora 10 DVD with the fedora-updates repository enabled resulted in a broken NetworkManager due to a missing dependency on libudev.so.0. Jud pointed out[2] that although he could install the missing library from the DVD the situation would present a serious problem to anyone that tried "[...] a network install with updates [...] the result (a system without network access) can't be fixed without A) network access, or B) another Fedora image (also possibly requiring more network access)."

In answer to questions from Jef Spaleta Jud revealed[3] that: "[libudev.so.0] doesn't seem to actually be installed by the stock F10 image. If I do a plain install (no updates), NetworkManager works fine. Running a yum update' then pulls down all the updates, as well as Install libudev0'. So at some point I suppose NetworkManager picked up a dependency on libudev0, but for some reason updating during the installation process doesn't pull this new package in." Kevin Kofler[4] and Jesse Keating[5] both pointed out that: "[T]he updates repo isn't the Everything repo. To really do a proper install with updates you have to enable both the Updates repo and the Everything repo." Kevin added that this was why the install from DVD with updates enabled was not an officially supported method.

Several people, including Thorsten Leemhuis, suggested[6] that modifying the anaconda installer to be aware of which repositories depend on each other would be useful. Jesse Keating was[7] not averse to the idea as long as it could be done in a "[...] distro agnostic way. Avoiding hardcoded hacks specifically for Fedora is one of the goals of anaconda upstream."

Password Resets and Inactive Accounts

When Mike McGrath was perturbed[1] that so many FAS account holders had failed to reset their passwords recently a discussion of the entanglement of active account status and passwords followed.

Many respondents posted that they had received the email notifications but had not needed to, or had not had time to, perform their password reset.

[Lane] worried that forcing periodic password resets caused people to weaken security by writing down their passwords but Bruno Wolf III argued[2] that a potentially bigger threat might be "[...] someone forging messages from Mike with deceptive URLs that trick people into changing their passwords using a hostile proxy. Doing things in the current manner is training people to get fooled." He added that cryptographically signing the reset messages was important.

Till Maas requested[3] consistent titling of the password reset notification emails, suggested extending the grace period beyond two weeks and asked that the notification contains the information that the contents of the user's fedorapeople.org home would be moved.

Mike McGrath and others explored[4] possible grace periods and numbers of warning emails.

Patrice Dumas asked why there was a password reset at all and was answered[5] by Jesse Keating that it was "[...] the best way Infra has today to discover all the active and inactive accounts." In response Toshio Kuratomi pointed[6] to an open ticket which nominally deals with how long accounts should be left open if passwords have expired but had become[7] an investigation of how account inactivity can be determined.

After Mike McGrath explained that "[...] we've got thousands of contributors, relatively few of them actually commit to cvs. So we could go around to figure out how to make all of our various auth points report back but that's a lot of work. The account system is the only common point of entry for every contributor [...]" Christopher Aillon suggested[8]: "So let's require to them to simply _log in_ to FAS to reset the timer (you need to do that to change passwords, anyway!)."

Mono Conflagration Jumps to Blog

Following the FESCo decision not to replace rhythmbox with banshee as the default media-player in Fedora 11[1] some follow-up clarifications were made by parties to the discussion and the conflagration jumped between @fedora-devel and the personal blog of David Nielsen, the Banshee ex-maintainer and perhaps the main force behind the Mono SIG[2].

Bill Nottingham put forward[3] a concise time-line which attempted to show that the proposal had been handled in a straightforward and usual manner. Bill noted that the Desktop SIG had expressed[4] a lack of enthusiasm early in the process and that the imminent beta-freeze meant that the decision had to be taken without further prolonged discussion.

AdamWilliamson suggested[5] that because Mono's Microsoft links worried many F/OSS developers it would have been a good idea to address such concerns: "[...] explicitly rather than just pretend they don't exist in your initial proposal (the word 'Mono' does not actually occur a single time in the initial version of the Wiki page you posted)."

A question put by Jóhann B. Guðmundsson wondered[6] whether there was anything preventing the Mono SIG from creating their own Fedora spin in which banshee was given pride of place as the default media-player. Rex Dieter confirmed that there were no obstacles on this path.

A proposal to adopt a Code of Conduct modeled upon Ubuntu's was[7] made by Richard W.M. Jones. He also expressed regret that David was leaving Fedora and apparently moving to Ubuntu as referenced[8] by a blog entry. Reading the blog suggest that Foresight Linux seems more to David's taste although one comment does point out[9] that Ubuntu "[...] head community people have been calling for volunteers to increase the work surrounding Mono and have a huge love for banshee[10] and Canonical isn’t anti-mono since some of their new job postings desire Mono as a skill[11]."

Seth Vidal was[12] among those who wondered specifically how such a code could be enforced and also where specifically the Fedora Project could be alleged to have engaged in misconduct on this issue. Reading David's blog seems to suggest both that any rudeness was privately exchanged and that his perception is[13] that "[...] Mono isn't welcome in Fedora, and will always be a second class citizen[.]"

Documentation Betas

John J. McDonough posted[1] that owners of major features should review the Beta release notes. Scott Radvan posted[2] that the Security Guide[3] would benefit from the scrutiny of any interested @fedora-devel readers.

Provenpackager Re-Seed

Jon Stanley asked[1] that everyone read the process by which the "provenpackager" group will be repopulated.

A request by Ralf Corsepius for some definitions led Patrice Dumas to post[2] that: "provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora." Further discussion led[3] Michael Schwendt to voice a concern that non-responsive maintainers might be shielded from feedback if provenpackagers step in to update and upgrade packages. Kevin Kofler offered[4] the non-responsive maintainer process as a way to rectify any problems with Bugzilla tickets being ignored.

Michael Schwendt questioned[5] Patrice Dumas in greater detail as to why provenpackagers and sponsors are not equal sets.

Further details on how to apply to FESCo to become a provenpackager were elicited[6] from JoshBoyer by Stepan Kaspal.

In a separate thread MichelSalim asked[7] about the preferred way to become a sponsor.

Closing Bugs NEXTRELEASE

Christoph Wickert requested[1] that all maintainers (and especially Red Hat developers) would "[p]lease fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!"

When Rahul Sundaram responded that it depended on the seriousness of the bug and complexity of back-porting Daniel P. Berrange[2] and Rakesh Pandit[3] acknowledged that such complex cases might exist but that suggested that this was often a cop-out which could discourage users.

Jeremy Katz responded[4] "[...] as the person who has apparently pissed you off this morning [...]" and described the case in point as much more complex than Christoph had claimed. It seemed that Christoph's ability to create LiveCD images of Fedora 11 using Fedora 10 as the development platform had been stymied by changes to syslinux. Jeremy added that even if this single change were reverted Christoph would need a newer kernel and squashfs-tools and more.

Later Jeremy clarified[5] that the combination of livecd-creator + mock were complicated by SELinux but that this had been addressed by recent work.

One complication is that Bodhi uses NEXTRELEASE even for updates to stable releases. After some confusion on this point LukeMacken posted[6] that anyone wanting to change the behavior should file a ticket.