devel-announce July 2013

devel-announce@lists.fedoraproject.org

6 participants
56 discussions

F20 Self Contained Change: Ruby on Rails 4.0
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed Self Contained Change: Ruby on Rails 4.0 = https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 Change owner(s): Vít Ondruch <vondruch(a)redhat.com>, Josef Stříbný <jstribny(a)redhat.com>, ruby-sig(a)lists.fedoraproject.org Ruby on Rails 4.0 is the latest version of well know web framework written in Ruby. == Detailed description == The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all the Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on Rails. == Scope == Proposal owners: * The whole Rails stack has to be updated * New additional gems will have to be packaged * Some dependencies of the Rails stack will need update For the list, see [1] Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0#Scope

1 0

Reminder: Change Proposals Submission deadline is tomorrow!
by Jaroslav Reznik 15 Jul '13

15 Jul '13

Greetings! The Change Proposals Submission deadline is tomorrow, 2013-07-16 [1]. Please send your proposals for Wrangler's review (to be announced asap) and help us to coordinate Fedora 20 release! The final schedule will be based on the needs of accepted Changes. See How to's on https://fedoraproject.org/wiki/Changes/Policy After this deadline new Change Proposals would require FESCo exception. I can see a lot of Changes still being incomplete, don't forget to change the category by Tuesday! FYI: FESCo on the last meeting approved the Change Proposals escalation process. If you're asked by FESCo member(s) or Wrangler to change your Change Proposal to the System Wide category, please do so and fill in required details in the Change page. Thanks. Jaroslav [1] https://fedoraproject.org/wiki/Releases/20/Schedule

1 0

F20 System Wide Change: Visible Cloud
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed System Wide Change: Visible Cloud = https://fedoraproject.org/wiki/Changes/VisibleCloud Change owner(s): Matthew Miller <mattdm at fedoraproject org> With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and downloadable cloud images (in qcow2 and raw.xz format) produced and released together with the traditional desktop installer and and livecd images. Now, let's go to the next level and present the cloud images as equal options. == Detailed description == This involves three key changes. They are not significant changes to other packages, but since this has implications for the distribution as a whole, I thought it best considered as bigger than a self-contained change. 1. Refactoring of the Fedora web site to put the cloud image on equal footing with the desktop image download. The new F19 cloud images page [2] is very nice thanks to the hard work of the web team, but unfortunately, in order to find it, one has to go down into the cellar, into a disused lavatory with a sign on the door saying Beware of the Leopard. Let's put it on display in the metaphorical front lobby. 2. Creating specific release criteria and tests for basic cloud image functionality in, at least, Amazon EC2 and OpenStack. (Tests for smaller public cloud services could be added once those services gain the ability for us to provide official images directly. Tests for Eucalyptus and other IaaS software could be added as well.) 3. Building images in Koji using virtualization and Anaconda, rather than using a chroot-based appliance-creator. This will ensure that the cloud image is more in line with The Real Fedora. == Scope == Proposal owner: Coordination; working with web designers and documentation writers to develop the new presentation, working with QA to develop criteria and tests, and working with release engineering to land the changes to image building. I plan to be actively involved in all of these. Other developers: This will probably require a overhaul of the Get Fedora website, as that is current primarily focused on the desktop download. Release engineering: Yes, Jay Greguske, Andrew Thomas, and I are working on the improvements to the image build system and coordinating with Dennis Gilmore. Policies and guidelines: As noted, QA guidelines will need to be updated. [1] https://fedoraproject.org/wiki/Features/FirstClassCloudImages [2] http://fedoraproject.org/en/get-fedora-options#clouds

1 0

F20 Self Contained Change: Role based access control with libvirt
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed Self Contained Change: Role based access control with libvirt = https://fedoraproject.org/wiki/Changes/Virt_ACLs Change owner(s): Daniel P. Berrange <berrange(a)redhat.com>, Cole Robinson <crobinso(a)redhat.com> Allow role based access control with libvirt. == Detailed description == Libvirt role based access control will allow fine grained access control like 'user FOO can only start/stop/pause vm BAR', but for all libvirt APIs and objects. == Scope == Proposal owners: * 90% of the work is already in rawhide * Documentation needs to be written Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

F20 System Wide Change: SSD cache
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed System Wide Change: SSD cache = https://fedoraproject.org/wiki/Changes/SSD_cache Change owner(s): Rolf Fokkens <rolf(a)rolffokkens.nl> Using recent kernel (3.9 and later) features for (fast) SSD caching of (slow) ordinary hard disks. == Detailed description == Recent Linux kernels support the use of Solid State Drives as caches for rotational hard disks. Because the high cost per GB for SSD devices this feature may bring the best of both: fast end big yet affordable storage capacity. Linux kernel 3.9 introduced dm-cache, kernel 3.10 introduces bcache. == Scope == Proposal owners: Enable caching features in new kernels Other developers: Support the caching features in their respective packages. Special focus should be on making the system boot from a cached root FS. Release engineering: All packages should operate in close harmony te make this work. Only a rebuild of the relevant packages is required. Policies and guidelines: No changes I think.

1 0

F20 System Wide Change: No Default Syslog
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew Miller <mattdm at fedoraproject org> No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. == Detailed description == Let's change the default install to no longer install a syslog service by default — let's remove rsyslog from the "comps" default. The journal has been around for a few releases and is well tested. F19 already enabled persistent journal logging on disk, thus all logs have been stored twice on disk, once in journal files and once in /var/log/messages. This feature hence recommends no longer installing rsyslog by default, leaving only the journal in place. rsyslog will remain the recommended option to install if users require /var/log/messages, need support for the syslog network protocol, or need to enforce strict data lifecycle policies. It's sufficient to install and start rsyslog to get /var/log/messages and BSD syslog support. Also see previous attempt: [1] and previous mailing list discussion at [2] [1] https://fedoraproject.org/wiki/Features/systemd-journal [2] https://lists.fedoraproject.org/pipermail/devel/2012-October/172682.html == Scope == Simply remove "rsyslog" from all default install groups in "comps". Packages which strictly require /var/log/messages to exist might need updating to gain dependencies on some kind of syslog daemon (but they needed that before too, so this is mostly just bugfixing that's useful anyway). If any of the packages in the default install is one of those, we need to look at it in detail, and find a solution. However, currently no package of the default install is requiring a syslog implementation. Some tools such as logcheck might need to be updated to process data from the journal instead of /var/log/message. This should be fairily easy as "journalctl" generates the same output as "cat /var/log/messages" previously did. Proposal owners: Commit a change to "comps" to remove "rsyslog" from it. Drop in a file /var/log/README informing users where the log files went, and how do get to the same data as before. Other developers: logcheck needs updating to stay useful. It needs to grep through the output of "journalctl", rather than /var/log/messages. Release engineering: nothing really. Policies and guidelines: Guidelines should clarify that /var/log/message doesn't exist on many systems, but that was already the case before -- so little changes. QA should add a few tests and release criteria about journal functionality. Note that logrotate should stay in the default install, as it is required to rotate wtmp and btmp (the journal synchronously rotates before writing and does not require logrotate for operation).

1 0

F20 System Wide Change: No Default Sendmail
by Jaroslav Reznik 15 Jul '13

15 Jul '13

= Proposed System Wide Change: No Default Sendmail = https://fedoraproject.org/wiki/Changes/NoDefaultSendmail Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew Miller <mattdm at fedoraproject org> No longer install an MTA by default. (Specifically let's remove sendmail from @core and @standard comps groups.) == Detailed description == Let's change the default install to no longer install an MTA by default. Specifically, let's remove sendmail from the @standard and @core group. On today's Internet most SMTP hosts do not accept mail from a server which is not configured as a mail exchange for a real domain, hence the default configuration of sendmail is seldom useful. Even if the server is not tied to a real mail domain, it can be configured to authenticate as a user on the target server, but again, this requires explicit configuration on both ends and is fairly awkward. Something that doesn't work without manual configuration should not be in the default install. Most MUAs we ship (especially those we install by default) do not deliver to a local MTA anyway but rather include an SMTP client. Usually, they will not pick up mail delivered to local users. This means that unless the user knows about local mail and takes steps to receive local mail addressed to root, such messages are likely to be ignored. On top of that, sendmail has always been a quite surprising choice for an MTA, as most administrators tend to prefer mail systems such as Postfix or Exim these days, and Sendmail appears to be quite arcane to most. Administrators should install the MTA of their choice after installation (or via kickstart) and sendmail should not be the default anymore. Many other distributions do not install an MTA by default anymore, and so should we. Running systems without MTA is already widely tested. The various tools (such as cron) which previously required a local MTA for operation have been updated already to deliver their job output to syslog rather than sendmail, which is a good default. Also see the previous attempt: https://fedoraproject.org/wiki/Features/NoDefaultMTA == Scope == Simply remove "sendmail" from all default install groups in "comps". Packages which strictly require a MTA to run might need updating to gain dependencies on "server(smtp)" (but they needed that before too, so this is mostly just bugfixing that's useful anyway). If any of the packages in the default install is one of those, we need to look at it in detail, and find a solution. However, currently no package of the default install is requiring an MTA. Proposal owners: Commit a change to "comps" to remove "sendmail" from it. Other developers: logwatch/logcheck might need updating to not require an MTA for delivering log changes. Some packages might need a dependency on "server(smtp)" added. Release engineering: nothing really. Policies and guidelines: nothing really. Maybe the guidelines should clarify that /usr/bin/sendmail doesn't exist on many systems, but that was already the case before -- so little changes.

1 0

F20 Self Contained Change: VM Snapshot UI with virt-manager
by Jaroslav Reznik 11 Jul '13

11 Jul '13

= Proposed Self Contained Change: VM Snapshot UI with virt-manager = https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots Change owner(s): Cole Robinson <crobinso(a)redhat.com> Add UI to virt-manager for easily managing VM snapshots. == Detailed description == qemu and libvirt have all the major pieces in place for performing safe VM snapshots/checkpoints, however there isn't any simple discoverable UI. This feature will track adding that UI to virt-manager, and any other virt stack bits that need to be fixed/improved. == Scope == Proposal owners: * Verify that all the libvirt APIs are fully implemented, some pieces were missing at last check. *Implement virt-manager UI Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

F20 Self Contained Change: ARM on x86 with libvirt/virt-manager
by Jaroslav Reznik 11 Jul '13

11 Jul '13

= Proposed Self Contained Change: ARM on x86 with libvirt/virt-manager = https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86 Change owner(s): Cole Robinson <crobinso(a)redhat.com> Fix running ARM VMs on x86 hosts using standard libvirt tools libvirt virsh, virt-manager and virt-install. == Detailed description == qemu has an ARM emulator that works well and is actively used in the Fedora ARM effort. However libvirt and virt-manager currently have issues launching qemu-system-arm VMs, mostly by encoding x86 assumptions in the generated command line that cause qemu-system-arm to fail to start. Let's fix it! == Scope == Proposal owners: 1. Get fixed virt-manager and libvirt packages into Fedora by the feature freeze 2.Fix issues in libvirt with generating qemu-system-arm command lines * We may only target a single machine type for this, need to determine [1] 3. Fix virt-manager to not encode incorrect device types like 'ide' [2] 4. Optionally identify any UI defaults that can be improved to handle this case Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://bugzilla.redhat.com/show_bug.cgi?id=807538 [2] https://bugzilla.redhat.com/show_bug.cgi?id=806105

1 0

F20 Self Contained Change: Yesod Web Framework
by Jaroslav Reznik 11 Jul '13

11 Jul '13

= Proposed Self Contained Change: Yesod Web Framework = https://fedoraproject.org/wiki/Changes/YesodWebFramework Change owner(s): Jens Petersen <petersen(a)redhat.com>, Michel Salim, Ben Boeckel Yesod is a Haskell web framework for productive development of type-safe, RESTful, high performance web applications. == Detailed description == This is a packaging effort: the Yesod stack of packages requires quite a lot of new Haskell libraries to be added to Fedora. Some basic packages have already been done for a long time but there are a lot left to be added. == Scope == Proposal owners: Yesod stack of libraries will be packaged following package versions in latest yesod-platform (currently 1.2.2): * Package yesod-core and its dependencies * Package yesod and its dependencies Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2013