On Tue, Mar 04, 2014 at 03:32:03PM +0100, Jaroslav Reznik wrote: I'm in favor, but I think we could use a little bit more in the release notes -- at least a link to the systemd documentation and a quick note on how to override locally (although people should be getting used to this with systemd by now), and I think people would appreciate a list of services that were migrated. -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org&gt;

Hello, 2014-03-04 15:32 GMT+01:00 Jaroslav Reznik <jreznik(a)redhat.com&gt;: (Everyone), please keep the explicit "Proposal owners"/"other developers"/"release engineering"/"policies and guidelines" split. Other contributors *need* to know what they are being asked to do by your Change. * Policies and guidelines: ** Adjust packaging guidelines to mention migration of cron jobs to timer > units for packages that already depend on systemd Last time this was discussed in http://meetbot.fedoraproject.org/fedora-meeting/2013-02-06/fesco.2013-02-..., there were concerns about "confusion of users/admins", specifically referring to the disabling a .service / disabling a .socket duality. So we will need packaging guidelines not only for the migration, but for the timer units themselves. (From the Change page:) This would also seem to require detailed packaging guidelines for the timer units. * Fix spec files in packages that are not applicable for migration [Fix Cron > Dependency Tracking Bug 2] > * Review and migrate if applicable cron jobs shipped in packages that > already > depend on systemd [Timer Migration Tracking Bug 3] How many packages (at least an of magnitude) are we talking about? Is it the 16+3 that are currently blocking the tracker bugs? Mirek

2014-03-04 18:34 GMT+01:00 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;: "System-wide" is defined "not self-contained", not "touching absolutely everything". It is likely appropriate in ths case. * Policies and guidelines: ** Adjust packaging guidelines to mention migration of cron jobs to timer > units for packages that already depend on systemd Last time this was discussed in http://meetbot.fedoraproject.org/fedora-meeting/2013-02-06/fesco.2013-02-..., there were concerns about "confusion of users/admins", specifically referring to the disabling a .service / disabling a .socket duality. So we will need packaging guidelines not only for the migration, but for the timer units themselves. > Not following here we already have packaging guidelines for systemd units Those guidelines don't contain the word "timer" at all. Perhaps they are already sufficient; if so, that's not immediately obvious. Mirek

On Tue, 04.03.14 15:54, Miloslav Trmač (mitr(a)volny.cz) wrote: It is probably time to port over these jobs now. With systemd 209+ we should have a somewhat comprehensive solution in systemd now that can do roughly what cron can do, plus some nice additional features (though minus a couple of others). I am looking into adding a couple of more things before the Fedora release, in order to make this functionality convincing enough that people can understand why this change is made. For example, I want support for timer events that can wake up the system, and simple anacron-like behaviour. I'd also like to make sure we sell this properly. While I think it should be a goal to port all cronjobs we *ship* over to this, I want to make sure that cron is advertised as a good solution for people who just want to queue a simple cronjob. This is because setting up a timer service is more complex than setting up a cronjob. A cronjob is a single line added to "crontab -e" or /etc/crontab. However, a systemd timer unit will always be two files, and they will have 2+ lines each. While the systemd way is certainly more uniform with the rest of service management, it is definitely a bit more work, and I don't want to be in competition here... Lennart -- Lennart Poettering, Red Hat

On Tue, 04.03.14 11:27, Pete Travis (lists(a)petetravis.com) wrote: Kinda no and kinda yes. PID 1 will not do user jobs. However, systemd user instances will do that for you. However, they don't run unless you are logged in or have enabled lingering (with "loginctl set-linger"). The idea is that this is strictly opt-in, and unless enabled via set-linger the user cannot take up resources while not logged in. And if the the user is logged in (or set-linger is used), then it will not enable time-based actviation for it, but also other kinds of activation like .socket, and so on...) So, we are different here, it's a lot more restricted, and you will have a per-user systemd instance around if you make use of this, but then again you get the real deal, not just timer based activation... Lennart -- Lennart Poettering, Red Hat

On 05/20/2014 12:47 PM, Jaroslav Reznik wrote: Apparently he forgot to mention the retraction of the sys V to systemd proposal in this mail as well as qoute my reason I guess somethings are two hard " Greeting Jaroslav With regrets I must say I feel we have grown so fat we are about to collapse under our own weight but instead of properly start dealing with that within the project, people chose to ignore that fact but instead chose to force some future vision of RHEL 8 upon the project under the names of .next, products and wg's and constantly attack the solid ground what our foundations have stood for and their meaning all those years and embark on multiproduct releases based on wrong fundamental assumption, without statistical backing up of what they considered being the underlying cause for some of their assumptions and without thoroughly thinking things through what needs to be done before being able to do that as well as the fact we lack the necessary community infrastructure and workflows being in place to remotely being able to achieve delivering multiple products in a useful and efficient manner based on the resources we have in the project. And as WG's slowy turn into tiny little empires fighting amongst themselves for components directions and maintenance while the owners of those components are scratching their head still trying to figure how the .next,product and wg proposal affects them, their maintenance and where they general fit into that future vision or simply are ignoring it which inevitably will result in them suddenly finding themselves being slapped by reality and waking up from their slumber when it finally does hit them. Unfortunately I'm not seeing much future or vision in Fedora and it's direction anymore and the fact is that I'm failing to convey what needs to be fixed in any useful and meaningful way and manner, with the end result being that I'm not being heard and at the same time being powerless in fixing things that need fixing within the community. makes me part of the problem not the solution for the project and those that still believe in it and the direction it is taking. Thus I here by official request the withdrawal of both of my features, sys V to systemd migration as well cron to timer migration where applicable due to how those processes have been handled by FPC and FESCo and their members and their expectation as well as the fact that envision of Fedora all those what 8+ years is proving to be the boulevard of broken dreams of what I hoped we could accomplish and achieve together as an community under the naive and false assumption that Fedora was a community sponsored project not community corporate owned one. My withdrawal should allow for those willing to continue with systemd migration and integration within the project submit *new proposal* to the feature process tailored to the expected and wanting of FESCo and FPC and continue the work that I'm leaving behind which is roughly above 1000 man hours by my estimations to properly integrate these things into the distribution. Best regards Jóhann B." Good luck with either Matt or Stephen as your new project leaders JBG