For the 2014-03-12 meeting as the Change Proposal was announced on devel-announce list on 2014-03-04.
Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units.
Arguably this is not a system wide change since the migration itself affects less then half of total shipped cron jobs and for those that aren't it only updates the components specfile to current packaging guidelines.
Affected packages that might be migrated depending on the functionality of the cron script and outcome from collaboration with maintainer(s)
amavisd-new apt arm4 atop bcfg2 clement cyrus-imapd dbmail denyhosts dspam exim fetch-crl freeipa hylafax+ inn leafnode ltsp mailman mcelog mdadm mldonkey newscache nsd opendnssec openvas-scanner ovirt-engine ovirt-node polipo sagator sipwitch spamassassin squidGuard subscription-manager sysstat vdsm vnstat yum-cron
Those components that wont definitely be migrated already contain a spec file patch which fixes those components to depend on crontab as specified by the FPG
FPG already contains section on how to package systemd unit packaging timer unit's are no different.
Now there is that question if you ( FESCO ) want to deny/prevent packages that dont already depend on systemd from shipping timer units.
Would you mind adding a link on the Change page to a guide on how to convert an existing cron specification to systemd timer units, please? Also, a list of the affected packages would be nice to have here.
In general, I'm +1 to this Change, but I'd like to see more hand-holding provided to the owners of affected packages.
One nitpick: Creation of bz991679 did not follow the mass bug filing policy[1]. It should probably be redone if this Change is approved.
[1] https://fedoraproject.org/wiki/Mass_bug_filing
Replying to [comment:2 sgallagh]:
Would you mind adding a link on the Change page to a guide on how to convert an existing cron specification to systemd timer units, please?
That should neither be a requirement nor is it doable no more than it was with init scripts. The fact for this as it was for the init script is they need to be migrated on case by case bases and we do want anything outside the list I provided in comment 1 to be migrated
Also, a list of the affected packages would be nice to have here.
The list of affected packages is there in comment 1
No it should not follow that policy I file bugs once I have migrated the timer units I'm not a lazy feature owner that expect package owners to do that work in fact I dont expect the maintainer to do anything but to review, provide feedback and apply the patches I provide.
Replying to [comment:3 johannbg]:
Replying to [comment:2 sgallagh]: Would you mind adding a link on the Change page to a guide on how to convert an existing cron specification to systemd timer units, please? That should neither be a requirement nor is it doable no more than it was with init scripts. The fact for this as it was for the init script is they need to be migrated on case by case bases and we do want anything outside the list I provided in comment 1 to be migrated
Sure, but a few simple example comparisons would be a big help, if at all possible. I want to make this as easy as possible for maintainers to accomplish.
Also, a list of the affected packages would be nice to have here. The list of affected packages is there in comment 1
Sorry, I missed that. I was looking only at the Change page. I'd still like to see it added there, though. FESCo tickets aren't a great place to share information.
One nitpick: Creation of bz991679 did not follow the mass bug filing policy[1]. It should probably be redone if this Change is approved. No it should not follow that policy I file bugs once I have migrated the timer units I'm not a lazy feature owner that expect package owners to do that work in fact I dont expect the maintainer to do anything but to review, provide feedback and apply the patches I provide.
Sure, but a tracker bug isn't terribly useful if it only shows the work that's already been done. I'd rather see bugs mass-filed against all the components, with the assignee set to you and the bug description explaining that the implementation will be provided, so they don't need to take action until that patch appears.
That way, we can use the Tracker BZ to actually see how far along we are and judge its status when we get to Alpha Freeze.
Replying to [comment:4 sgallagh]:
It does not get any easier then reviewing and apply the provided patch(es)
List of components that contain cron jobs that might be migrated added to the feature page.
Sure, but a tracker bug isn't terribly useful if it only shows the work that's already been done.
It does, it's shows the bug which contains the patch and the bugs which the patch has been applied to (bugs in status closed )
I will be using the workflow I know that works and is the same one I have used and continue to use for the sysv to systemd migration.
It was good enough for previous FESCo members for the past 2+ years it should be good enough for this FESCo
cron to systemd time units change accepted (+7,0,1)
From today's FESCo meeting: For cron-to-systemd-time-units, please make sure the necessary packaging guidelines are approved before commiting the patches.
The packaging guidelines already have approved the packaging of systemd units, packaging timer unit is no different...
You need to clarify precisely what changes to the packaging guidelines you are expecting as in why you think handling timer units is different from https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29 ???
In anycase once you ( as in fesco ) that are supposed to be the experts can explain to me why we should be packaging timer units differently from the other 13 systemd unit types we have, I can try to write somekind of proposal to the FPC but as I see it all of the 14 unit types have the exact same build requirements, the same requirement, the same file locations, the same files section etc. What am I missing here?
On the mailing list, you [https://lists.fedoraproject.org/pipermail/devel/2014-March/196291.html articulated a policy] something like:
It's my understanding that you want one of those options to be the policy, and as such, it needs to be in the guidelines so that new packages are consistent.
Second, the guidelines at https://fedoraproject.org/wiki/Packaging:Systemd ''does'' have specific guidelines for service units. Adding a small section to that on timer units would be nice polish but I don't think a hard requirement. (Note that that document does give some guidance on which options are recommended and which are better avoided in Fedora service units. I don't think there is anything applicable for timer units, but if you know of any, this document seems like the place to put such recommendations.)
Finally, on the mailing list, I suggested expanding the release notes section with a simple link to the upstream documentation, and particularly with a note on how to override locally. I know that's a general systemd thing, but let's make the transition as smooth as possible through good communication. It might also be nice to have a quick note about related journalctl commands, for the same reason.
Replying to [comment:11 mattdm]:
On the mailing list, you [https://lists.fedoraproject.org/pipermail/devel/2014-March/196291.html articulated a policy] something like: All packages with timed execution which already depend on systemd (for example because they contain service units) SHOULD (or MUST?) use timer units instead of cron jobs Packages which do not already depend on systemd SHOULD NOT (or MUST NOT, or, actually, MAY) use timer units
You yourself deferred that discussion on the relevant acceptance meeting of this feature and last time I submitted proposal to FPC it took 3 months before it could make the schedule ( the proper cron dependency which I needed to fix after that Red Hat employee that was responsible for the cronie feature did not do so ) and be accepted which is just nuts and I'm still waiting for them to decide upon the the subpackaging of files relevant to syslog-ng/rsyslog in components which I filed 2 years ago so if FESCo wants somekind of changes to the packaging guidelines by all means go ahead I literally dont have time to deal with FPC incompetence.
As I said there on the FESCo meeting, the discussion you yourself deferred was an decision that belongs with the Fedora Engineering <-- committee ( not FPC that can be sorted after FESCo makes that decisions and the guidelines updated accordingly) that components that ship cron jobs but dont already depend on systemd unit's must not be allowed to be migrated to timer units and the reason ( beside the obvious zero gain for those components ) for doing that is we do not want to have hard dependency for components that aren't relevant to the bootup process one way or another on systemd.
It's my understanding that you want one of those options to be the policy, and as such, it needs to be in the guidelines so that new packages are consistent. Second, the guidelines at https://fedoraproject.org/wiki/Packaging:Systemd ''does'' have specific guidelines for service units. Adding a small section to that on timer units would be nice polish but I don't think a hard requirement. (Note that that document does give some guidance on which options are recommended and which are better avoided in Fedora service units. I don't think there is anything applicable for timer units, but if you know of any, this document seems like the place to put such recommendations.)
We would need to rewrite the entire systemd unit section and make it generic to accommodate all the 14 types unit.
Finally, on the mailing list, I suggested expanding the release notes section with a simple link to the upstream documentation, and particularly with a note on how to override locally. I know that's a general systemd thing, but let's make the transition as smooth as possible through good communication.
I can add the the link to upstream documentation sure but multiply defining the overwrite section for all the units type is just stupid. It's a generic thing just like how you "package" all the 14 type units.
It might also be nice to have a quick note about related journalctl commands, for the same reason.
What related journal command?
I guess you saw Peter Hutterer G+/Blog post and decided now to blindly apply it here at least going through the last meeting log no one mentioned any related journal command requirement. The fact is much better administrator command is using journalctl -e_COMM=Xorg then what Peter Hutterer proposed on his blog and the administrative command to use in conjunction with type timer unit is "systemctl list-timers" which is available in v209+
Replying to [comment:12 johannbg]:
Replying to [comment:11 mattdm]: On the mailing list, you [https://lists.fedoraproject.org/pipermail/devel/2014-March/196291.html articulated a policy] something like: All packages with timed execution which already depend on systemd (for example because they contain service units) SHOULD (or MUST?) use timer units instead of cron jobs Packages which do not already depend on systemd SHOULD NOT (or MUST NOT, or, actually, MAY) use timer units You yourself deferred that discussion on the relevant acceptance meeting of this feature
You yourself deferred that discussion on the relevant acceptance meeting of this feature
Right -- I am in favor of this feature and don't think that hashing out the specifics of the policy should block its acceptance.
and last time I submitted proposal to FPC it took 3 months before it could make the schedule ( the proper cron dependency which I needed to fix after that Red Hat employee that was responsible for the
FPC is often slow. They go through a lot of things with... extreme attention to detail. If you would like help in dealing with that, I can to some degree. Finding someone on the FPC to help advocate is another worthwhile approach. I don't think this particular change is going to be a big problem, though, especially since we have FESCo acceptance of the change.
In any case, going through that process is part of how getting change to actually happen works. Let me refer you to one of LWN's [https://lwn.net/Articles/591842/ quotes of the week this week], from our friends over at Debian:
''Yes, this is to some extent hair-splitting, but, well, welcome to free software. :) Doing this stuff requires a lot of hair-splitting, since it involves quite a bit of, as the saying goes, "tepid change for the somewhat better." '' — Russ Allbery
Second, the guidelines at https://fedoraproject.org/wiki/Packaging:Systemd ''does'' have specific guidelines for service units. Adding a small section to that on timer units would be nice polish but I don't think a hard requirement. (Note that that document does give some guidance on which options are recommended and which are better avoided in Fedora service units. I don't think there is anything applicable for timer units, but if you know of any, this document seems like the place to put such recommendations.) We would need to rewrite the entire systemd unit section and make it generic to accommodate all the 14 types unit.
Some parts of it could be made generic, but other parts of the existing document clearly are specific to service units. Getting rid of those parts seems like a step backwards. Adding a small part about timer units — and it could be very small if there is nothing more than the policy above — seems like a step forward.
Finally, on the mailing list, I suggested expanding the release notes section with a simple link to the upstream documentation, and particularly with a note on how to override locally. I know that's a general systemd thing, but let's make the transition as smooth as possible through good communication. I can add the the link to upstream documentation sure but multiply defining the overwrite section for all the units type is just stupid. It's a generic thing just like how you "package" all the 14 type units.
Note that this is a ''separate'' request for some text for the release notes, not the packaging guidelines.
It might also be nice to have a quick note about related journalctl commands, for the same reason. What related journal command? I guess you saw Peter Hutterer G+/Blog post and decided now to blindly apply it here at least going through the last meeting log no one mentioned any related journal command requirement. The fact is much
I guess you saw Peter Hutterer G+/Blog post and decided now to blindly apply it here at least going through the last meeting log no one mentioned any related journal command requirement. The fact is much
I have no idea what you mean about this G+/Blog post. Also, just now, I said "would be nice"; I'm not adding a requirement. But here is what would be nice:
''I am a sysadmin who is used to looking in /var/log/cron when I suspect something is up with a scheduled task. With this change, where should I look now? What else do I need to know?''
It doesn't need to be a big production number, just a little bit of help. That's why we have a "release notes" section. If you say that it is ""systemctl list-timers", ''awesome'': put that there. Since that's not in the systemd in f20, that's very useful and relevant release notes information.
I'm honestly not sure what the answer to the other part is; on my rawhide system, I don't see anything in the journal that relates to the timer execution. Just some from the resulting services, which is different. Well, actually, only from dnf-makecache.service; systemd-tmpfiles-clean.service is listed as activated by systemd-tmpfiles-clean.timer but nothing seems to be logged. I don't mean to go too far into the weeds there, but were I looking into this in a working sysadmin context, I might be frustrated because this seems to be a decrease in transparency into what is going on my system. In fact, I may totally be missing something which should be obvious but for whatever reason isn't to me. That's exactly why we need it in the release notes.
FESCo (and Fedora overall!) relies on the expertise of feature owners for these details; that's why we're asking you rather than telling you.
Talked with Jóhann on IRC. He thinks it would be best if FESCo sent a complete policy recommendation to FPC. The specific proposal is:
I recommend we vote on this in-ticket for expediency, and resolve at the next FESCo meeting if there are not enough votes to pass before then.
(Note that this isn't in any way rescinding the approval of the feature overall, just clarifying the intended policy.)
Also, Jóhann is already planning to work with Pete on the docs team on the release notes, so that should be good. (Thanks Jóhann)
Replying to [comment:14 mattdm]:
I don't see how FESCo voting on a proposal helps but I won't stand in the way. Consider this a vote with the majority == reducing quorum.
... to expand on this: the usual process in any case is to bring a wording proposal to FPC, and then discuss it with them. Since the quoted proposal above already exists, and FESCo will presumably not be as a committee be conducting negotiations (between two voting bodies) about it, I don't see a difference between Jóhann submitting the wording by himself and Jóhann submitting the wording with a FESCo ACK.
The general idea has already been approved with the Change, so a second ACK for the initial proposal is redundant. the specific wording/implementation is up FPC's review, so FESCo voting on the initial proposal doesn't help with any adjustments suggested/requested by FPC either.
I dont see this being mine to submit et all
Replying to [comment:18 johannbg]:
Historically FESCo has neither been submitting guideline proposals for approved Changes, nor blocked Change approval on FPC agreeing; usually we want to approve the Change early to give the owners a definite decision, without duplicating the FPC review or waiting or FPC's decision.
FESCo playing a middle man between the Change owners and FPC is very rarely useful, and in most cases FESCo unfortunately cannot contribute too much to the implementation effort—neither with code/patches nor with guidelines; that is up to the Change owners.
The Change page specifically includes
Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemd so naturally FESCo is assuming that some guidelines need to be added. Though, perhaps, the right thing to do would might be to just drop that from the Scope section.
I have filed [1] but based on experience and swiftness of the FPC you ( FESCo ) should not expect this being dealt with by the FPC until last quarter 2014 or later.
Agreed on 2014-04-02 FESCo meeting: FESCo reccomends that FPC work with change owner to come up with suitable guidelines and we move forward with them (5+1 0-1)
Can this ticket be closed now to correspond with Wiki/bug state?
Please overwrite https://fedorahosted.org/fpc/ticket/412 decision in changing the wording from "MUSTs to SHOULD in timer to "MUST NOT (without an FESCo exception)"
FPC cant realize that systemd.timer IS NOT CRON, IT'S BEHAVIOUR IS NOT LIKE CRON ( other then it triggers based on timed event ), IT'S LOG OUTPUT IS NOT CRON, IT'S NOT BACKWARD COMPATABLE WITH CRON ( you cannot reuse existing cron files ), IT'S CONFIGURATION IS DIFFERENT FROM CRON, IT'S NOT INTENDED TO REPLACE CRON FOR END USER OR ADMINISTRATOR CREATED TASKS NOR FOR COMPONENTS NOT ALREADY DEPENDING ON SYSTEMD!
It's a new technology people need to get it through their thick heads and approach it as such.
Some of us are actually trying to cleanup the core/baseOS to make it agile,prepared for containers so can you pretty please ensure that unnecessary dependency on it at least not without FESCo going through the justification of having to do so.
Thanks
Replying to [comment:22 johannbg]:
Could you please link or point to the ''specific'' text of the decision, and say what precisely you want the text to read?
I'm afraid I just don't see any decision in that ticket, let alone a decision that contains the text you quoted.
"18:02:41 <abadger1999> Okay, MUSTs changed to SHOULDs."
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-04-03/fpc.2014-04-03-16.02.log.html
FPC members are showing profound lack of understanding what systemd timer units are and which problem they solve by expecting timer units to behave and act like thus essentially be cron which is precisely why I was trying to avoid having spesific systemd timer sections added to the FPG.
"16:16:40 <notting> there was the thing i mentioned on list, but if there's not quorum, there's not quorum"
As usual the ridiculousness of FPC continues no summary from the meeting and not enough quorum so again as I asked on the meeting can I get FESCo to vote on this themselves which will overrule whatever and whenever FPC finally manage to reach decision.
Btw for the sake of efficiency just vote on this ticket so I dont have wait weeks for another meetings and whatnot
Jóhann, I'm not seeing a crisis here. The change is approved, so you shouldn't be blocked on doing anything.
I'm also not really worried about a practical problem with dependency creep here; I'm having trouble coming up with an example of something without an existing systemd dependency already (for service units) where it wouldn't be most natural to use cron than systemd timer triggers. So I'm not seeing the urgency. If something specific comes up and is a problem, we can address that.
Matt I'm going to retract this feature request if the benefits Í see for doing it as in cleaning, correcting thus fixing part of the core/baseos as well as better integrate components with systemd where it belongs hence it is very important that components that do contain cron jobs and already depend on systemd must be migrated while components that do not contain cron jobs and do not depend on systemd must not be migrated. ( this will allow for example complete removal of crontab for containers/servers without loss of functionality thus shrinking the core/baseos )
If FPC or FESCo are going have this open to wild wild west maintenance as in having this "should" or "optional" which in turns allows everything or nothing to be migrated since they know better then it's best that they contribute their time and effort in migrating this in their own time or do so on Red Hat dime and I will happily sit the sidelines to see how well that plays out.
Please, remember that this is a project with a lot of different people involved ("community"!) , and we can't get anything done if everyone always demands that things be done 100% their way or nothing. That really just wastes everyone's time. Your idea is good, your help is welcome, and I'm happy to put time and effort into supporting it, and so are others, but it's frustrating if you threaten to pull the rug out from everything whenever you feel it's not perfect. Remember the adage "The perfect is the enemy of the good?" Let's go for "good", and move towards perfection in that way. It feels more painful but is more actually effective in the end.
I do think it's important for the the core dependencies to be clean, and from the ticket and the log, it looks like Bill is working on communicating that to FPC. It just takes time and I have confidence that it'll work out right.
Let's focus on the key part -- cleaning up the core/baseos -- and deal with any problematic edge cases if they ever come up. I don't want bloat in container and server cases either, and from other comments I've seen recently I think FPC could use some clear guidance that FESCo sees this as technically important and the Board these as strategically valuable too. So, I'll work on that. And Bill is working on communicating the reasoning for "must" to FPC. But I don't want to work under the threat that you're going to quit behind us, please. A little patience goes a long way.
And in the meantime, there's plenty of not-worrying-about-politics and just doing the actual thing that needs to be done, to do.
You do realize that unlike other features owner I sign up to actually do the work required to see this through that means for this particular part of the feature an 2 full working weeks as in 80 hours of contributing my free time ( with the inclusion of the anacron cleanup in the process ) and zero load on maintainers with the exception of potentially any back and fourth regarding the migration itself and having to apply the patches that I submit in bugzilla ( but that added work goes strictly to FESCo members add that time since they refused to accept me as a proven packager ).
That 80 hours is without the time I spent fixing and providing patches to 60 components correcting the dependency on crontab which should have been done when we as an community defaulted cronie and arguably by the cronie maintainer himself.
And I as an contributor is entirely within my rights to retract features if FESCo or FPC makes a bad judgment call which pulls the rug right under my feets with what I'm trying to achieve with the feature and the work I put in that feature.
With the exception of Bill Nottingham I seriously doubt that many understand as well as grasp how much work we have ahead of us cleaning up the core/baseOS to move it out of "generic" to "targeted" or spesific product and make that part of the distribution agile again.
And it's rather interesting being accused of not remember that this is a project with a lot of different people involved ("community"!) when the fact is at one point in time or another those driving or supporting the .next and wg effort have to come clean and explain to the community that when they elevated those products to direct the project into the next rhel vision, above the community maintained ones everything outside those products have effectively become none choice or rather the act of elevating regardless if it's single or plural, brings the critical path of build order which automatically result in removal of choice ( and by removing choice innovation at the same time cannot take place ) out of the equation hence there exist only the illusion of should in the project.
It was not without reason when I was part of the serverWG that I proposed that the entire effort and vision of .next and wg should be kept separated and implemented separately and branded separately from Fedora as people have known and contributed to for the last 10 years as well as to provide the necessary place for those that fall outside the realm of any of the WG to continue to exist, to make this clear but people chose to burn me on the stakes for pointing out obvious and telling the truth, screaming I was wanting to fork Fedora and what not.
Well those same people will have to explain to maintainers and the community in less then two years by my guesstimation when it will start effect their maintainership and most likely change our foundations in the process as well as this being Red Hat community sponsored project to Red Hat dictated and decided project as well so perhaps it's best that they focus on reminding themselves not others about what involves in community.
I don't mean to impugn your community credentials. All I mean is that I don't see any reason to foment a conflict between FPC and FESCo or anyone else, when we can instead just work together to make Fedora better. That takes more patience, and it sometimes takes compromise, but in the end it will get us further.
It has been 2 years since I filed this [1] in preparation for unavoidable emerging of this [2] so excuse me if my patience is non existent regarding the FPC.
My experience with them has been less then pleasant meeting after meeting they cant reach quorum
From my perspective FESCo should just dissolve it and replace the procedure with something more efficient after all the FPG is a living document and you get rid of any potential conflicts with FESCo by removing FPC.
The fact is there is nothing to compromise here timer units are not a complete replacement for cronie thus we should not give maintainers the false impression that they could or should migrate components that do not already depend systemd but contain cron job to timer units.
Allowing it will force me to create 5 new targets etc and submit them to be included in the initscript package which we are working hard to get rid of as well as add well most likely hard dependency for those components on the initscript component rather then systemd directly for less then zero benefit.
Cronie has it's purpose for those components that do not depend on systemd as well as serving administrative and end users cron jobs handler and we should keep it that way since both components ( systemd-timers and cronie ) complement each other.
I have about 1000 man hours left to complete and cleaning up and preparing systemd units for containers.
And now additional cleanup after Dan, Lennart and Kay because you know as well as I do they dont have any time necessary to do the work for their feature so it winds up to be a drive by tagging maintainers and flagged 100% complete once done expecting them to implement their feature for them. ( Quite frankly i'm amazed that the feature process allows for this )
So if FESCo and FPC insist on allowing free for all migrate everything or nothing scenario for timer units I will not be part of it and will retract this feature since as you can see my work is better spent elsewhere then being part of that kind of nonsense.
From 2014-04-16 FESCo meeting: AGREED: wait until next week (+:all) (notting, 17:15:24)
Leaving as meeting item.
FESCo this cant go on like this, endlessly punting again and again in the faint hope that enough FPC members show up on meetings to reach quorum leads to nowhere. It wastes my time, it wastes your time as well as every other individual that wants to make changes to the FPG guidelines time and grinds everything to halt until quorum can be reached by the FPC.
You ( FESCo ) have to accept the fact that the process you came up with so many years ago is not working for the distribution and you cannot endlessly evade the responsibility having to deal with this issue.
Afaikt you tried to increase the number of FPC members to increase the likely hood of FPC being able to reach quorum and that has not panned out.
We have a lot to clean up on the core and base OS which will bring a lot of changes to FPG and we cannot have that work grind to halt on a whim of few people showing up to a meeting or not, so you are faced with two options either replace the entire members of the FPC with people that understand and accept their responsibility and do have the time necessary to commit to it and act accordingly and those individuals start cutting down the number of issues in fpc issue tracker preferably starting with oldest first or dismantled it altogether and implement another process that better deals with constantly live document like the FPG is in the distribution.
"<geppetto> #info systemd timer guidlines wording change to use MUST (+1:6, 0:0, -1:0)" [1]
Given that Bill managed to use his power of persuasion and enough members of FPC were present this time to reach quorum I'm closing this ticket.
There is no need for any of us spend more time on this ticket when there is actual work to be done.
No wait this turned out to be bullshit they changed the wording last minute to "Packages MUST not depend on both cron and systemd." which is equivalent to should
FPC seems to be under the assumption that it is fine to introduce a new package or a sub package and have that sub package depend on systemd when neither that nor the original package contained systemd units or otherwise has or had an existing hard dependency on systemd.
So basically they introduce an dependency on systemd where there should be none which at that point you could just as well migrate everything from cron to systemd unit which requires a completely different implementation ( thus completely differently constructed section in the guidelines ) and is absolutely not the intention of my proposal since cron is not 1 to 1 replacement for systemd.
I thought I had been very clear on this but apparently that message is not getting through hence I give up I formerly retract this feature.
Reopening to put back on the agenda. I think this is, at its heart, a good proposal, and if Jóhann isn't interested in working on it, I'd like to at least try to see if anyone else has interest in picking it up.
For the first this is my feature proposal so dont you dare qo bypassing the feature process by going around and hijack it for your own gain in the hopes someone does the require work for you.
Secondly systemd is not a one to one replacement to cron that is a fact hence we cannot nor should we allow the possibility for everything to be migrated which apparently FPC thinks should be done.
If it would make remote sense to migrate every cron job I would not have spent fixing ca 60 components and their dependency and waiting 3 months for that bloody proposal to pass FPC.
I take very good care that systemd integration is done properly and I would have migrated every cron job to timer units if it really would have made sense period.
If FESCo will overrule FPC and ensure that components that do not already depend on systemd wont get migrated and closes any goddam word loops wholes they try to put in the guidelines in the process or by some other means manage to knock some sense into FPC I'll happily reopen this feature and work on it.
If not then FESCo should block timer migration because the alternative will lead to a mess that later on needs to be cleanup.
Replying to [comment:40 johannbg]:
That's not how it works. It's a good idea. If you want to keep working on it, awesome. That would clearly be the best case.
But if you don't -- and you said you don't! -- you can't demand that no one else continue where you left off. If you give it up, you're giving it up.
It really does not seem like the doom and gloom situation you are painting. The first case was changed to "MUST". The second case does allow for the possibility of some package to decide to use timer units when cron might have been a better choice, but that seems like an obscure situation, and certainly not the case that "everything will be migrated". Although I do think that the new wording is worse than "SHOULD NOT", if some obscure package wants to switch to systemd timers for some possibly valid, possibly silly reason... eh. Not the end of the world, and no reason to stop from doing the more important work.
Replying to [comment:41 mattdm]:
Replying to [comment:40 johannbg]: For the first this is my feature proposal so dont you dare qo bypassing the feature process by going around and hijack it for your own gain in the hopes someone does the require work for you. That's not how it works. It's a good idea. If you want to keep working on it, awesome. That would clearly be the best case. But if you don't -- and you said you don't! -- you can't demand that no one else continue where you left off. If you give it up, you're giving it up.
Why dont you file your own competing feature timer migration with what you consider "valid" implementation in the distribution and man up you to sign up to do the 80+ hour job yourself instead of dumping it on the maintainers to do it for you or stealing other features proposals.
If not then FESCo should block timer migration because the alternative will lead to a mess that later on needs to be cleanup. It really does not seem like the doom and gloom situation you are painting. The first case was changed to "MUST". The second case does allow for the possibility of some package to decide to use timer units when cron might have been a better choice, but that seems like an obscure situation, and certainly not the case that "everything will be migrated".
It really does not seem like the doom and gloom situation you are painting. The first case was changed to "MUST". The second case does allow for the possibility of some package to decide to use timer units when cron might have been a better choice, but that seems like an obscure situation, and certainly not the case that "everything will be migrated".
This just shows that you have profound lack of understanding what benefits systemd brings over cron jobs, how the timer units are implemented and what shortcomings they have compared to cronie and cron job otherwise you would not want to put the distribution and administrators on the path you are proposing but I will be eagerly awaiting to see what you will be proposing in your own systemd timer cron to timer migration feature proposal, how you implement the timer units and how you are going to solve some of the integration administration and usability problems problems with the path your propose forward while doing so.
I will gladly forward all the Reindhl Haralds, their comments and bug reports in your direction when shit start hitting the fan as a result of that.
Replying to [comment:42 johannbg]:
It really does not seem like the doom and gloom situation you are painting. The first case was changed to "MUST". The second case does allow for the possibility of some package to decide to use timer units when cron might have been a better choice, but that seems like an obscure situation, and certainly not the case that "everything will be migrated". This just shows that you have profound lack of understanding what benefits systemd brings over cron jobs, how the timer units are implemented and what shortcomings they have compared to cronie and cron job otherwise you would not want to put the distribution and administrators on the path you are proposing but I will be eagerly awaiting to see what you will be proposing in your own systemd timer
This just shows that you have profound lack of understanding what benefits systemd brings over cron jobs, how the timer units are implemented and what shortcomings they have compared to cronie and cron job otherwise you would not want to put the distribution and administrators on the path you are proposing but I will be eagerly awaiting to see what you will be proposing in your own systemd timer
Nah. It just means what I already said: I don't think that changing the guidelines which currently don't forbid systemd timer units to ''continue'' to not forbid systemd timer units will result in a mass migration to them. It's not like there will suddenly be a timer unit vacuum that people currently using cron will be compelled to rush into.
I do note that Arch Linux is experimenting with moving logrotate, man-db, and a few other things which did not previously have other systemd unit files to timer units. That seems completely fine to me, and probably even beneficial. There are a number of other packages which have cron scripts but which really only make sense when coexisting with some base package which does already have systemd service files. Maybe you disagree with this, but it doesn't seem worth tossing out the whole effort over.
Replying to [comment:43 mattdm]:
Replying to [comment:42 johannbg]: It really does not seem like the doom and gloom situation you are painting. The first case was changed to "MUST". The second case does allow for the possibility of some package to decide to use timer units when cron might have been a better choice, but that seems like an obscure situation, and certainly not the case that "everything will be migrated". This just shows that you have profound lack of understanding what benefits systemd brings over cron jobs, how the timer units are implemented and what shortcomings they have compared to cronie and cron job otherwise you would not want to put the distribution and administrators on the path you are proposing but I will be eagerly awaiting to see what you will be proposing in your own systemd timer Nah. It just means what I already said: I don't think that changing the guidelines which currently don't forbid systemd timer units to ''continue'' to not forbid systemd timer units will result in a mass migration to them. It's not like there will suddenly be a timer unit vacuum that people currently using cron will be compelled to rush into. I do note that Arch Linux is experimenting with moving logrotate, man-db, and a few other things which did not previously have other systemd unit files to timer units. That seems completely fine to me, and probably even beneficial. There are a number of other packages which have cron scripts but which really only make sense when coexisting with some base package which does already have systemd service files. Maybe you disagree with this, but it doesn't seem worth tossing out the whole effort over.
The arch implementation of timers is nothing to be proud over and they went a bit ahead of themselves there as I have mentioned to them.
I have already spoken with the man-db maintainer in the distribution and he informed me that they were working on an rpm trigger to replace the cron job it shipped ( being solve in similar manner as info pages ) and at the same time he added the missing dependency on crontab, logrotate serves no purpose anymore and should be moved to "optional" distro package along with logwatch, ( which despite love of many covered only 1/5 of the daemon/services we shipped. I checked when I was looking at fixing the log implementation in the distribution an effort which got thwarted/stalled by FPC and "Lumberjack" and still is stuck in FPC queue years later ) I can go on it's not like have not been spending the last what 4 years crawling in the core/baseOS layer getting all muddy while discovering all the dirt we got buried under that carped through broken packaging policy's which in all righteousness should be left to clean up by those that created those policy's in the first place,to teach them a lesson or two in accepting responsibility for their actions and decision making.
In anycase in your cron to timer feature counter proposal supporting components which do not already depend on systemd to accommodate FPC "Should", you will need outline how you plan on exactly implementing that in the distribution and which component is supposed to carry that base line implementation ( I'm not so sure the systemd maintainers in the distribution will accept that implementation nor will Lukáš in initscripts as well as at that point you can just as well go ahead and migrate everything and get rid of cronie/crontab from the core/base) since my feature does not outline that or take that into account since it does not make sense add et all heck it even adds double maintenance work on maintainers if implemented ( if they plan on supporting both timers and cron )
As discussed on the FESCo meeting I here by call for votes on FESCo overwriting the latter part of the FPC decision "Packages MUST not depend on both cron and systemd" to some wording in the English language that limits specifically the cron to timer migration to components that already ship systemd units which will provide the proper dependency cycle on top of the fact administrates should never manually enable timer units since those are bound to the startup of the service itself which apparently FESCo to certain extent ( Bill seemed to have realized this since he specifically mentioned presets as the determining factor if an timer unit is enable or not, which is true since if the preset already enables the service unit the timer unit is enabled as well since it's bound to that unit ) as well as FPC have failed to realize since the mindset seems to be mapping one to one timer units behaviour to cron behaviour when we are dealing with two completely different technology's and their implementations which again complement each other not replace.
Based on the output from that voting I can either start submitting patches or Jaroslav will officially announcing the retraction of this feature by me due to FESCo/FPC decision making or lack there of, opening up the possibility from Matt to submit a new cron to timer feature proposal which he outlines how the plan is to accommodate that "should" the FESCo/FPC is fixating on allowing in the distribution first place.
I eagerly await for him to submit that proposal since the implementation of that will require additional changes to the FPG along with creation of several new systemd targets in the distribution to properly cover that "should" and at the same time allow the entire shipped cron job to be migration and cronie and similar components be retired in the process.
I don't think overruling the FPC is the right way to go, when we can still talk nicely.
I also continue to not see a problem with the second statement being a "SHOULD NOT" (or again, "MUST NOT without exception"), because I can see cases where it actually might make sense. It continues to seem like you are arguing that "SHOULD NOT" means "SHOULD" (or even "automatically will!"), which... I don't understand.
But, I also don't think FPC's last minute change to the second statement ("Packages MUST NOT depend on both cron and system systemd directly") makes sense. It's really just a rephrasing of the restriction in the ''first'' clause (which already says that packages which depend on systemd must not depend on cron). In other words, they really just dropped the second clause. It's completely reasonable to ask that the earlier second clause be put back.
But I don't think that's a blocker for the change. My point continues to be: even if that second "don't do this" clause isn't there, this change can still go ahead with the packages that '''ought''' to be changed by the first clause. People are unlikely to go out of their way to migrate packages that shouldn't be migrated -- inertia is on the side of no action.
And, to be super-clear: I never said I was going to submit a new proposal. I'm interested in finding someone who would like to work on this one if you decide not to.
Replying to [comment:46 mattdm]:
You are not going to hijack my proposal and assign it to someone else.
That's maybe something that is condoned and you get away with within Red Hat all in the name of cloud and containers but not in a community driven distribution and certainly not with myself.
The proper feature proposal procedure to do is to formally announce the retraction of this feature which in turn will allow a completely new counter cron to time proposal (not based on mine or my work ) to be written and announced which can be based on the illusion and assumption that systemd timers and cronie and cron jobs are interchangeable components and submitted, which will address the short comings of this one ( since the work that I have put in this is based on these two components and their functionality to be used to complement each others shortcomings ), which components that ship cron job will be migrated to timer units as well as add any requirement FPC deems to be necessary, based on this should or what ever other wording that adhere to the illusion that timers and cron jobs are completely interchangeable and will require introduction of new systemd targets and bigger changes to the FPG guidelines to be implemented) as illogical they might be ( like continue to ship legacy sysv initscripts in a separated sub-package o_O ).
Replying to [comment:47 johannbg]:
Replying to [comment:46 mattdm]: And, to be super-clear: I never said I was going to submit a new proposal. I'm interested in finding someone who would like to work on this one if you decide not to. You are not going to hijack my proposal and assign it to someone else.
No one is hijacking anything (except perhaps you hijacking FESCo's time with unnecessary demands). We're also not assigning anything.
Try to look at this from our perspective. Someone came to us with an idea that we would like to see implemented. We (FESCo) agreed and approved that idea. Later, due to other circumstances, the person who initially was going to perform the implementation backed out for their own reasons. Since we still want to see this happen, we are asking for volunteers to pick it up and continue.
To use a packaging analogy, you created a package, then orphaned it. Instead of dropping the package from the distribution, we went and looked for another owner or comaintainer to carry it forward.
I think you're missing the entire concept of community here. Involving yourself in a community means that sometimes the community will not do exactly what you want. In this case, the community is opting to take a good idea and run with it because you are refusing to do so.
The proper feature proposal procedure to do is to formally announce the retraction of this feature which in turn will allow a completely new counter cron to time proposal (not based on mine or my work ) to be written which can be based on the illusion and assumption that
This is just simply ridiculous. You have no claim to "your work" because you have submitted it under the terms of the Fedora FPCA, which states unequivocally that it is under an acceptable open-source license. This means that while you are perfectly welcome to retain your copyright, we are also perfectly welcome to fork it and proceed. (EDIT: to clarify, what I mean here is that we have embedded in the FPCA a mechanism for ensuring that good ideas can continue, even if the original person does not want to pursue it, as well as a specific counter to your assertion that you can withdraw your proposal and thereby force that no one may work on it or from it).
And really Johann. Please stop with the "I'm going to take my ball and go home!" ultimatums. It's childish and it does a great job of ensuring that no one will take you seriously.
systemd timers and cronie and cron jobs are interchangeable components and submitted, which will address the short comings of this one ( since the work that I have put in this is based on these two components and their functionality to be used to complement each others shortcomings ), which components that ship cron job will be migrated to timer units as well as add any requirement FPC deems to be necessary, based on this should or what ever other wording that adhere to the illusion that timers and cron jobs are completely interchangeable and will require introduction of new systemd targets and bigger changes to the FPG guidelines to be implemented) as illogical they might be ( like continue to ship legacy sysv initscripts in a separated sub-package o_O ).
This rant is just completely false on pretty much every point, but I realize at this point that having a rational discussion with you is becoming difficult. You have made it clear that you have no interest whatsoever in participating meaningfully in a community. You are not operating in good faith and you are very rapidly burning through any remaining goodwill that your contributions have earned you.
Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that but Stephen I see this has come to this and maybe you want to by me a beer for your amusement here as well or hold a bucket full of paper while bullying me that work so well for Josh at flock.
Jaroslav just formally announce the feature retraction and have another individual submit another proposal, I have already taken care of any other work that might be required of you as the feature wrangler.
Formerly closing this ticket once and for all so I wont take up of FESCo's any more valuable time.
Replying to [comment:49 johannbg]:
hold a bucket full of paper while bullying me that work so well for Josh at flock.
Me? If so, I don't remember holding buckets full of paper or bullying anyone. If I said something that was taken otherwise, my apologies. I'm rather confused though.
Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that
Yes, and the thing that is truly baffling is that we have ''agreed'' with you on this. The only point that is slightly sticking is your insistence that nothing can get done unless we change the wording to say that "People ''must not'' do this thing that no one would bother to do unless they had a really good reason anyway". There's nothing stopping you whatsoever from making the changes that do need to happen. For that matter, there's nothing stopping you from at least getting started on this and working out the remaining nitpick on the way.
The only one that is hindering this effort, Johann, is you. We are trying to work with you. We are probably trying harder than we ought to, because you are as I said not operating in good faith. What "good faith" means is that you acknowledge that all parties in the discussion are trying to come up with a solution that works for everyone.
You are not doing this. You are demanding that yours is the only opinion that matters and are disregarding other input. Beyond that, you are attempting to bully FESCo into doing what you say by asserting that you won't help unless you get your way. When that didn't work, you are attempting to bully us into not finding someone else to do the work that wouldn't be adding so much meaningless drama into the proceedings.
In short, Johann, you need to recognize that you are responsible for this situation and have done nothing at all to improve it.
but Stephen I see this has come to this and maybe you want to by me a beer for your amusement here as well or hold a bucket full of paper while bullying me that work so well for Josh at flock.
There's probably a language barrier problem here, but I'm not sure what you're saying. No one bullied you at Flock, and I have no idea what amusement I would get from buying you a beer.
I've tried very hard over the last year to work with you. I understand some of your motivations and some of the hardships you have faced that have put you into your current frame of mind. I respect that and I've attempted to color my interactions with you with that in mind. However, you have not done me the same courtesy, and for that I reiterate my assertion that you are not behaving in good faith.
Replying to [comment:50 jwboyer]:
Replying to [comment:49 johannbg]: hold a bucket full of paper while bullying me that work so well for Josh at flock. Me? If so, I don't remember holding buckets full of paper or bullying anyone. If I said something that was taken otherwise, my apologies. I'm rather confused though.
You were responsible for handing out the beer ticket's at the main flock party evening, an ticket made of paper and you kept in a bucket while sitting on a chair beside the entry door.
Care to explain to the audience how you responded when I asked you for those tickets when you knew full well I went straight to the back room to smoke when I walked in besides you?
Replying to [comment:52 johannbg]:
Replying to [comment:50 jwboyer]: Replying to [comment:49 johannbg]: hold a bucket full of paper while bullying me that work so well for Josh at flock. Me? If so, I don't remember holding buckets full of paper or bullying anyone. If I said something that was taken otherwise, my apologies. I'm rather confused though. You were responsible for handing out the beer ticket's at the main flock party evening, an ticket made of paper and you kept in a bucket while sitting on a chair beside the entry door.
Ah, yes. I was making sure people were both of age for the drink tickets and that they were with our group.
That was 9 months ago. There were a lot of people and I have no idea. If I said something it was probably done in jest. You're more than welcome to share if you'd like. Again, if you took offense, it wasn't intended and my apologies.
Replying to [comment:51 sgallagh]:
Replying to [comment:49 johannbg]: Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that Yes, and the thing that is truly baffling is that we have ''agreed'' with you on this. The only point that is slightly sticking is your insistence that nothing can get done unless we change the wording to say that "People ''must not'' do this thing that no one would bother to do unless they had a really good reason anyway". There's nothing stopping you whatsoever from making the changes that do need to happen. For that matter, there's nothing stopping you from at least getting started on this and working out the remaining nitpick on the way.
Hmm interesting why are you under the assumption I have not already started on this when in fact I did so at devconf 2013. when I left the guys and girls in the downstairs in the famous bowling ally the last evening to start working on this, Feel free to ask Harald, Kay, Lennart, Christop Wickert, Alexandria and any others that where down there if you have a hard time believing that. I almost skipped lunch with Jiri the day after to continue to work on this because I knew how little free time I have available to work on stuff like this ( why do you think specifically mentioned 80 hours work required to work on this? ) but he convinced me to step up from the computer to have lunch with him.
Feel free to ask him too.
It cannot work as is being proposed as the compromise that's what I have been trying to point out. repeatably which it he language barrier I guess we might be hitting I'm not explaining that point well enough for you ( fesco ) to understand and to implement that requires introduction of new targets, larger guidelines changes and so on and so fourth.
The startup and enable of timer unit is bound to the corresponding startup of the service it accommodates so when you for example start mailmain you will start mailmans time units previously known as it's "cron job" you stop mailman you stop the timer units opposed to the cron job which administrators repeatedly forgot to turn off when they stopped/disabled the mailman's initscript , now for a component that falls under "should" like for example moodles and component that does not ship an unit file or unmigrated legacy sysv initscript cron script, to which component are you going to bind it's startup? httpd,lighttp, nginx? obviously you cannot bind it to all so what alternative solution do you suggest?
Long story put short to solve that single integration issue for those "should" components and without going into specifically why you will have to solve this in attempt to not lengthening this further then it already has, this way but you will need to introduce hourly,weekly,monthy,yearly targets and once you have done that you have to migrate every cron job to timer units so you dont double the workload on maintainers having to maintain ( depending what FPC decided but they seem to be aiming for what I'm using in this example ) for example two sub packages, one that contained the timer unit and another one that contained the cron job, and the administrators ( as well as the maintainer or triager if dealing with bug ) having to figure out which solution is running and debug it.
The above is just one integration issue with "should"
You are not doing this. You are demanding that yours is the only opinion that matters and are disregarding other input.
Simply for the reason it does not make sense what is proposed or I have yet to see and understand the logic in solving it so, which does not result in alternative implementation and added workload for others and the community in whole.
Beyond that, you are attempting to bully FESCo into doing what you say by asserting that you won't help unless you get your way.
I'm investing 80 hours of my life into this work, to scratch an it's that I have, which I have to do on my free time and last time I checked my life is entirely under control to do what ever I please with, so if an proposal that I have been working on for the last year and I have submitted for acceptance suddenly gains an requirement for FPC, an requirement that I thought was not necessary based, and I choose to withdraw my contribution to due to that and me doing so results in me being bullying FESCo. that's quite the logic behind that.
When that didn't work, you are attempting to bully us into not finding someone else to do the work that wouldn't be adding so much meaningless drama into the proceedings.
The proper feature procedure is to officially withdraw proposal of feature submitter that no longer are working on their features which opens up the possibility for others willing to similar work. submitting their feature proposal and assign that to themselves in the process.
No I'm not I was plan on doing this entirely without the involvement of FPC what so ever since. My view of the purpose and usefulness of the fpc is or atleast should be known to everybody at this point + I was under the assumption the guidelines already covered this via it's install section, the rest is handled in the timer units themselves.
And you seem to be forgetting the fact that I'm not the one that asked for the involvement of FPC in the first place.
but Stephen I see this has come to this and maybe you want to by me a beer for your amusement here as well or hold a bucket full of paper while bullying me that work so well for Josh at flock. There's probably a language barrier problem here, but I'm not sure what you're saying. No one bullied you at Flock,
There's probably a language barrier problem here, but I'm not sure what you're saying. No one bullied you at Flock,
This is quite the response claiming that the victim was never subjected to the assault but duly noted how things operate within the project.
and I have no idea what amusement I would get from buying you a beer.
The same sarcastic amusement you gave me when I was planning to leave Fedora after what close to a decade of contribution and you single that entire contribution and what I sacrifices in the process making those contributions to a single beer offering on G+ at this years devconf or fosdem.
Regarding my "good faith" or lack there of, those are result of Red Hat's own employees doing. Bill can explain to you why he single me out specifically in F15 in relation to the sysv to systemd migration, the remarks he put on my bug reports and my alone when we where a team migrating the legacy sysv initscript to systemd service units an team that I dissolved due to that or when Toshio that filed a proven packaging request without as much as consulting me first in doing so then leaves me hanging to dry in that request without as much as an input if I can recall correctly which get's dismissed by fesco members due to conflict with Steve Dickinson the nfs maintainer, after I tried to migrate the nfs service in every possible way he liked, after I asked of there was another nfs maintainer I could deal with on the bug report and later on both fixed his own broken implementation after it being broken in Fedora for several months and he had a several weeks heads up notice he had to fix things from Kay due to how his units were implemented, heck even later after that I spent 5 hour cleaning the NFS spec file, fixes he dismissed and today I think the nfs is still broken in Fedora as well as RHEL 7.
My lack of good faith is through experiencing like the above which I see personally as frequent attempts to belittle my contribution to this project which I have been dedicated to and made sacrifices along the way more so you can image for close to a decade for no other reason but for others amusement.
Replying to [comment:53 jwboyer]:
Replying to [comment:52 johannbg]: Replying to [comment:50 jwboyer]: Replying to [comment:49 johannbg]: hold a bucket full of paper while bullying me that work so well for Josh at flock. Me? If so, I don't remember holding buckets full of paper or bullying anyone. If I said something that was taken otherwise, my apologies. I'm rather confused though. You were responsible for handing out the beer ticket's at the main flock party evening, an ticket made of paper and you kept in a bucket while sitting on a chair beside the entry door. Ah, yes. I was making sure people were both of age for the drink tickets and that they were with our group. Care to explain to the audience how you responded when I asked you for those tickets when you knew full well I went straight to the back room to smoke when I walked in besides you? That was 9 months ago. There were a lot of people and I have no idea. If I said something it was probably done in jest. You're more than welcome to share if you'd like. Again, if you took offense, it wasn't intended and my apologies.
Your response was very much intended and one that I will never forget it's not without a reason I can describe that moment so clearly. An action that earned you the nickname the "Bucket King" in the story of Flock since I never in my life have encounter an individual that has put himself on a high horse with me holding a bucket full of paper...
In anycase your behaviour is outside the scope of this ticket, people are busy attacking mine.
Replying to [comment:54 johannbg]:
This is probably a language barrier issue, but "bullied" and "assault" are very serious accusations. I can very clearly say I have never assaulted anyone, neither at flock nor anywhere else. Again, if I said something in what could only have been brief exchange that offended you, my apologies. However, there was no assault that occurred at all.
If you would like to continue to reference this, please just clearly state whatever you took offense to so it can be addressed plainly. I am honestly trying to give you the benefit of the doubt, but I do not take kindly to being accused of such serious things.
Replying to [comment:55 johannbg]:
Replying to [comment:53 jwboyer]: Replying to [comment:52 johannbg]: Replying to [comment:50 jwboyer]: Replying to [comment:49 johannbg]: hold a bucket full of paper while bullying me that work so well for Josh at flock. Me? If so, I don't remember holding buckets full of paper or bullying anyone. If I said something that was taken otherwise, my apologies. I'm rather confused though. You were responsible for handing out the beer ticket's at the main flock party evening, an ticket made of paper and you kept in a bucket while sitting on a chair beside the entry door. Ah, yes. I was making sure people were both of age for the drink tickets and that they were with our group. Care to explain to the audience how you responded when I asked you for those tickets when you knew full well I went straight to the back room to smoke when I walked in besides you? That was 9 months ago. There were a lot of people and I have no idea. If I said something it was probably done in jest. You're more than welcome to share if you'd like. Again, if you took offense, it wasn't intended and my apologies. Your response was very much intended and one that I will never forget it's not without a reason I can describe that moment so clearly.
Your response was very much intended and one that I will never forget it's not without a reason I can describe that moment so clearly.
Yet you haven't described it at all and I cannot remember anything of the sort.
An action that earned you the nickname the "Bucket King" in the story of Flock since I never in my life have encounter an individual that has put himself on a high horse with me holding a bucket full of paper...
I'm happy to be thought of as a fool. That doesn't bother me. What bothers me is being accused of something without being told what that something is.
I'm not attacking you. I'm trying to understand why you are offended and why you brought it up in the ticket. I'd like to resolve this in whatever way you see fit.
Replying to [comment:51 sgallagh]: Replying to [comment:49 johannbg]: Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that Yes, and the thing that is truly baffling is that we have ''agreed'' with you on this. The only point that is slightly sticking is your insistence that nothing can get done unless we change the wording to say that "People ''must not'' do this thing that no one would bother to do unless they had a really good reason anyway". There's nothing stopping you whatsoever from making the changes that do need to happen. For that matter, there's nothing stopping you from at least getting started on this and working out the remaining nitpick on the way. Hmm interesting why are you under the assumption I have not already started on this when in fact I did so at devconf 2013. when I left the guys and girls in the downstairs in the
Hmm interesting why are you under the assumption I have not already started on this when in fact I did so at devconf 2013. when I left the guys and girls in the downstairs in the
Because you have stated that you are just going to abandon the proposal. From where I'm sitting, that means "I'm not going to work on this". Whether you have already done some work on this is immaterial: you're planning to NOT work on this further, and that's what I was referring to.
famous bowling ally the last evening to start working on this, Feel free to ask Harald, Kay, Lennart, Christop Wickert, Alexandria and any others that where down there if you have a hard time believing that. I almost skipped lunch with Jiri the day after to continue to work on this because I knew how little free time I have available to work on stuff like this ( why do you think specifically mentioned 80 hours work required to work on this? ) but he convinced me to step up from the computer to have lunch with him.
I've never questioned your dedication, Johann. I've stated this repeatedly: I believe that you are attempting to make Fedora a better distribution. I know that you work hard on it.
The only one that is hindering this effort, Johann, is you. We are trying to work with you. We are probably trying harder than we ought to, because you are as I said not operating in good faith. What "good faith" means is that you acknowledge that all parties in the discussion are trying to come up with a solution that works for everyone. It cannot work as is being proposed as the compromise that's what I have been trying to point out. repeatably which it he language barrier I guess we might be hitting I'm not explaining that point well enough for you ( fesco ) to understand and to implement that requires introduction of new targets, larger guidelines changes and so on and so fourth.
If the problem is really that we're not understanding your point, then we need to work on communication. Resorting to "just do it my way or I quit!" doesn't help anyone.
If we think that the language barrier is really becoming the biggest problem, perhaps we could query the community for others that speak your native tongue and who might be able to act as an intermediary to help us get to the real meaning.
I do agree, it can be very difficult (for me, at least) to understand you at times. For what I hope might be constructive criticism: you don't seem to have a strong grasp of English punctuation, so it becomes difficult to parse what you are saying. The presence or absence of a comma, question mark or period can completely change the content of a sentence.
The classic example would be the difference between Let's eat, Grandma! (Asking your grandmother to join you at the dinner table) Let's eat Grandma! (Preparing your grandmother as the meal)
The lack of end-of-sentence punctuation is also difficult, as it can be unclear where one thought has ended and another has begun. (Notably, it can be difficult to tell when a particular noun is the actor in a new sentence or the target of a previous one).
Please accept these suggestions in the intent they are given, which is to improve communication, not to act as an attack.
This is an example of a sentence that can be difficult to read in English. In this particular case, I ''think'' I understand what you are saying, though you left out some context for those not familiar with moodles (I looked it up).
Let me attempt to summarize the problem: Timer units are bound to a service file. Timer units are automatically enabled when that service file starts and disabled when it stops. * Moodles is a web application that starts with a web-server. It is not bound to any one particular web server (and probably needs to be configured to enable it as well).
The question you ask is essentially "If you wanted to have it use timer units, you need to bind it to a service file. How do you do this if you don't know which web server it is using?"
If we assume for the moment that the conversion to a systemd timer unit is something we actually want for this package (it may not matter to the project at all), then perhaps the answer is as simple as dropping a new .service file for it into /etc/systemd/system that launches with whichever web-server you have chosen to use. Then the timer units could be bound to this supplementary service file.
This is just an off-the-cuff example, but maybe it's worth exploring?
I have a much harder time following this one, I think what you're saying is that allowing maintainers to migrate to systemd timer units means that they would have to maintain both cron and systemd units at the same time.
Sorry, I just really can't parse this well. I'm not sure why we couldn't just say "you may use one or the other, but must not use both, in your package". I suspect that this is the crux of the problem, but it's the part you seem to be having the most trouble explaining.
The above is just one integration issue with "should" You are not doing this. You are demanding that yours is the only opinion that matters and are disregarding other input. Simply for the reason it does not make sense what is proposed or I have yet to see and understand the logic in solving it so, which does not result in alternative implementation and added workload for others and the community in whole.
As I said above, I'm not ruling out that you are correct, but you haven't done a great job of explaining and justifying that position. I think we're all open to discussing it, but we need to come to the table with all of us understanding that we're on the same side. No one is trying to shoot you down.
Beyond that, you are attempting to bully FESCo into doing what you say by asserting that you won't help unless you get your way. I'm investing 80 hours of my life into this work, to scratch an it's that I have, which I have to do on my free time and last time I checked my life is entirely under control to do what ever I please with, so if an proposal that I have been working on for the last year and I have submitted for acceptance suddenly gains an requirement for FPC, an requirement that I thought was not necessary based, and I choose to withdraw my contribution to due to that and me doing so results in me being bullying FESCo. that's quite the logic behind that.
The "bullying" I mentioned was in your tone and the way that you continue to make ultimatums instead of reasoned arguments. Please try moderating your tone to sound less belligerent and more willing to explain yourself and people will listen.
When that didn't work, you are attempting to bully us into not finding someone else to do the work that wouldn't be adding so much meaningless drama into the proceedings. The proper feature procedure is to officially withdraw proposal of feature submitter that no longer are working on their features which opens up the possibility for others willing to similar work. submitting their feature proposal and assign that to themselves in the process.
I was looking at it more as a recognition that you have done good work and trying to build on it. It's really ''not'' intended as an attack on you, rather it's about not forcing someone to redo all the work you have already done, particularly when (to the best of our current knowledge) all the important bits are in place.
If we can reopen this conversation and bring it to a reasonable conclusion, I certainly have no problem whatsoever about you driving this to completion.
In short, Johann, you need to recognize that you are responsible for this situation and have done nothing at all to improve it. No I'm not I was plan on doing this entirely without the involvement of FPC what so ever since. My view of the purpose and usefulness of the fpc is or atleast should be known to everybody at this point + I was under the assumption the guidelines already covered this via it's install section, the rest is handled in the timer units themselves. And you seem to be forgetting the fact that I'm not the one that asked for the involvement of FPC in the first place.
I wasn't talking about the FPC here. I was talking about the stalemate and withdrawal of the feature. As noted above, I think this is first and foremost a communication problem.
but Stephen I see this has come to this and maybe you want to by me a beer for your amusement here as well or hold a bucket full of paper while bullying me that work so well for Josh at flock. There's probably a language barrier problem here, but I'm not sure what you're saying. No one bullied you at Flock, This is quite the response claiming that the victim was never subjected to the assault but duly noted how things operate within the project.
And now you are making claims of ''assault''? At what point did anyone lay a hand on you in anything other than a handshake?
If you felt that you were being abused, why did you not make that known at the time. If I had been witness or party to such treatment, I would have been ashamed. I do not believe that anyone in my sight treated you with anything but dignity.
and I have no idea what amusement I would get from buying you a beer. The same sarcastic amusement you gave me when I was planning to leave Fedora after what close to a decade of contribution and you single that entire contribution and what I sacrifices in the process making those contributions to a single beer offering on G+ at this years devconf or fosdem.
This is actually a very serious misconception. I did not make that conversation in sarcasm at all. I genuinely invited you to join me for a sit-down. When I asked you to let me buy you a beer, I was trying to extend an olive branch. I know how difficult it can be to express yourself over the Internet and I wanted a chance to talk to you directly.
I intended no sarcasm whatsoever there. I'm a little bit hurt that your assumption of me is to assume malice.
You're again drawing Red Hat with a very broad brush. I don't disagree that the situation you faced during the sysv->systemd migration was unpleasant (and I myself have thanked you repeatedly for sticking with that and seeing it through). Red Hat is a very large internal community as well, and we don't always see eye to eye. In fact, Red Hatters agreeing on a course of action has historically been the exception rather than the rule.
However, I don't really see how your interaction with a few specific individuals can color your impression of literally hundreds of others. There is no Red Hat corporate mandate that says "interfere with Johann!". All of us do our best in our own little areas of expertise to make Fedora and RHEL a better system. All of us have our own personalities, some more abrasive than others.
I don't think people belittle your contributions. I've asked around and people are genuinely happy with the work you do. What people ''do'' have a problem with is your communication. I maintain that some of this is a language barrier problem and that some of it is also the fact that the Internet is a terrible communication mechanism for carrying subtlety. The problem is that when communicating with others, you have a tendency to approach the situation with the expectation that everyone else involved is working against you. You (and everyone else in Fedora) needs to come to discussions with an understanding that the end goal is to make Fedora better.
Replying to [comment:58 sgallagh]:
Replying to [comment:54 johannbg]: Replying to [comment:51 sgallagh]: Replying to [comment:49 johannbg]: Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that Yes, and the thing that is truly baffling is that we have ''agreed'' with you on this. The only point that is slightly sticking is your insistence that nothing can get done unless we change the wording to say that "People ''must not'' do this thing that no one would bother to do unless they had a really good reason anyway". There's nothing stopping you whatsoever from making the changes that do need to happen. For that matter, there's nothing stopping you from at least getting started on this and working out the remaining nitpick on the way.
Replying to [comment:51 sgallagh]: Replying to [comment:49 johannbg]: Establishing a clear cut baseline when to use systemd timer units and when not to is preciecly what my proposal involved as well as any work related to that Yes, and the thing that is truly baffling is that we have ''agreed'' with you on this. The only point that is slightly sticking is your insistence that nothing can get done unless we change the wording to say that "People ''must not'' do this thing that no one would bother to do unless they had a really good reason anyway". There's nothing stopping you whatsoever from making the changes that do need to happen. For that matter, there's nothing stopping you from at least getting started on this and working out the remaining nitpick on the way.
That may seem so to you but from my view I will have to rethink,redo the timer migration integration with in mind that cron jobs that come with components that do not already depend on systemd will be migrated.
I have tried to convey an message that it requires different approach different implementation but I'm failing to do so.
If the problem is really that we're not understanding your point, then we need to work on communication. Resorting to "just do it my way or I quit!" doesn't help anyone. If we think that the language barrier is really becoming the biggest problem, perhaps we could query the community for others that speak your native tongue and who might be able to act as an intermediary to help us get to the real meaning.
To get the real meaning you need to understand the nature of the problem and I dont think there exist any icelander within the community that possesses the required knowledge to understand the nature of the problem and thus could convey it to you in a meaningful way.
Your not the first nor the last that points out that my English sucks.
It's not without reason I always had James Laska or Robert "Bob" Jensen and others from the community to proof read my work before publishing it be it on wiki or elsewhere.
The startup and enable of timer unit is bound to the corresponding startup of the service it accommodates so when you for example start mailmain you will start mailmans time units previously known as it's "cron job" you stop mailman you stop the timer units opposed to the cron job which administrators repeatedly forgot to turn off when they stopped/disabled the mailman's initscript , now for a component that falls under "should" like for example moodles and component that does not ship an unit file or unmigrated legacy sysv initscript cron script, to which component are you going to bind it's startup? httpd,lighttp, nginx? obviously you cannot bind it to all so what alternative solution do you suggest? This is an example of a sentence that can be difficult to read in English. In this particular case, I ''think'' I understand what you are saying, though you left out some context for those not familiar with moodles (I looked it up). Let me attempt to summarize the problem: Timer units are bound to a service file. Timer units are automatically enabled when that service file starts and disabled when it stops. * Moodles is a web application that starts with a web-server. It is not bound to any one particular web server (and probably needs to be configured to enable it as well). The question you ask is essentially "If you wanted to have it use timer units, you need to bind it to a service file. How do you do this if you don't know which web server it is using?" If we assume for the moment that the conversion to a systemd timer unit is something we actually want for this package (it may not matter to the project at all), then perhaps the answer is as simple as dropping a new .service file for it into /etc/systemd/system that launches with whichever web-server you have chosen to use. Then the timer units could be bound to this supplementary service file. This is just an off-the-cuff example, but maybe it's worth exploring?
The sample I provided was just one in many problems allowing for components that do not already provide systemd service units so even if this one would be solve this way another one waits around the corner and basically when you have solve most if not all of them you will have provided the infrastructure for a complete cronie,cron job removal.
Once that is in place there is no justification of us keeping it in the distribution but people would not settle on that which leads to an result that compromise as in ships both components.
I have a much harder time following this one, I think what you're saying is that allowing maintainers to migrate to systemd timer units means that they would have to maintain both cron and systemd units at the same time. Sorry, I just really can't parse this well. I'm not sure why we couldn't just say "you may use one or the other, but must not use both, in your package". I suspect that this is the crux of the problem, but it's the part you seem to be having the most trouble explaining.
The problem I'm having most trouble explaining is that we should not migrate components outside what I have listed on the feature page and even not all of those that I have listed there.
And I have no problem finishing what I signed myself up for but unfortunately I'm not seeing the reasoning in allowing component outside my defined scope to be migrated.
As much as I'm having hard time explaining why that should not be done you are having a hard time explaining why that should be done, or why that should be done without migrating everything.
In short, Johann, you need to recognize that you are responsible for this situation and have done nothing at all to improve it. No I'm not I was plan on doing this entirely without the involvement of FPC what so ever since. My view of the purpose and usefulness of the fpc is or atleast should be known to everybody at this point + I was under the assumption the guidelines already covered this via it's install section, the rest is handled in the timer units themselves. And you seem to be forgetting the fact that I'm not the one that asked for the involvement of FPC in the first place. I wasn't talking about the FPC here. I was talking about the stalemate and withdrawal of the feature. As noted above, I think this is first and foremost a communication problem.
Yes it's me having hard time explaining why I see things as a problems or in human interaction in general which boils to a different thought process I have then most people.
In pathetic attempt on explaining how that thought process is, when people in general for example look at a table, they look at the shape and texture of it I however look at how it's constructed.
People in general read books about love stories and what not, the only books I read are technical manuals.
When you look at the FPC you see... what I see is an inefficient means in the community to maintain a life document.
So to put it extremely simple I view everything as a puzzle to be solved which in turns leads to me trying to fix problems when they dont fit the puzzle or have a tendency to be "out of order" or "heading in the wrong direction".
Which makes me exceptionally good at spotting problems and fixing them if I posses the skill set required to do so but at the expense of me not winning any popularity contest or beauty patents while doing so.
Think psychological assault not psychical or sexual.
I'm perfectly capable of defending myself physically if it ever came down to that or die trying.
I'm a big man with a small heart which is my kryptonite.
I chose simply to walk away and never to attend flock again it's best that way. I wont bother anyone doing that.
You're again drawing Red Hat with a very broad brush. I don't disagree that the situation you faced during the sysv->systemd migration was unpleasant (and I myself have thanked you repeatedly for sticking with that and seeing it through).
It's far from being done yet from my point of view there are around 1000+ hours left to complete it.
Red Hat is a very large internal community as well, and we don't always see eye to eye. In fact, Red Hatters agreeing on a course of action has historically been the exception rather than the rule.
Which in the sense is a problem as in difference in perception what Fedora which in turns results in conflicts.
My lack of good faith is through experiencing like the above which I see personally as frequent attempts to belittle my contribution to this project which I have been dedicated to and made sacrifices along the way more so you can image for close to a decade for no other reason but for others amusement. I don't think people belittle your contributions. I've asked around and people are genuinely happy with the work you do. What people ''do'' have a problem with is your communication. I maintain that some of this is a language barrier problem and that some of it is also the fact that the Internet is a terrible communication mechanism for carrying subtlety. The problem is that when communicating with others, you have a tendency to approach the situation with the expectation that everyone else involved is working against you.
I don't think people belittle your contributions. I've asked around and people are genuinely happy with the work you do. What people ''do'' have a problem with is your communication. I maintain that some of this is a language barrier problem and that some of it is also the fact that the Internet is a terrible communication mechanism for carrying subtlety. The problem is that when communicating with others, you have a tendency to approach the situation with the expectation that everyone else involved is working against you.
Yup I suck at communication I think we can all agree on that point including myself.
Replying to [comment:59 johannbg]:
Replying to [comment:58 sgallagh]: If the problem is really that we're not understanding your point, then we need to work on communication. Resorting to "just do it my way or I quit!" doesn't help anyone. If we think that the language barrier is really becoming the biggest problem, perhaps we could query the community for others that speak your native tongue and who might be able to act as an intermediary to help us get to the real meaning. To get the real meaning you need to understand the nature of the problem and I dont think there exist any icelander within the community that possesses the required knowledge to understand the nature of the problem and thus could convey it to you in a meaningful way.
Ok, so maybe the best thing we can do here is arrange a phone call, Google Hangout or some other high-bandwidth communication and try to walk through the explanation in real time. Communication by email, in tickets or even on IRC is slow and prone to misunderstandings. Would you be willing to have a [series of?] discussions with me to explain the technology and the pitfalls you see of allowing other changes?
What I think I'm gathering from this thread is that the reason for blocking other changes is entirely because you feel that we need to hash out appropriate rules and guidelines for people to follow, or else we will end up with a wide variety of approaches that do more harm than good. If that's correct, then perhaps the answer becomes: "Packages that are not already consuming timer units MUST NOT be migrated until new guidelines are written." This is a very different (and more limited) statement.
Or possibly that the rules to accommodate other packages than those listed would change the way you need to proceed on the aforementioned packages (and possibly in difficult-to-predict ways). If ''this'' is the case, there's a strong argument for a blanket "No packages outside this list may convert within the Fedora 21 timeframe". If this is what you've been trying to say all along, I could certainly agree here.
The thing I still don't understand (but am willing to learn) is why you feel that the Change proposal cannot continue without the MUST NOT phrasing. I agree with you that we want the end result to be in the best possible state, but I also tend to agree with Matthew that, until we give people guidance on what ''to'' do, people are probably just going to continue working the way they have up until now. I suppose if it's the latter case above, then the stronger wording may very well be appropriate and necessary.
In any case, if you are still willing to discuss this, offer a time over the next few days that you will be free, and you and I (and any other FESCo members that would like to participate) can arrange a conference call or hangout. Is that reasonable?
Replying to [comment:60 sgallagh]:
Replying to [comment:59 johannbg]: Replying to [comment:58 sgallagh]: If the problem is really that we're not understanding your point, then we need to work on communication. Resorting to "just do it my way or I quit!" doesn't help anyone. If we think that the language barrier is really becoming the biggest problem, perhaps we could query the community for others that speak your native tongue and who might be able to act as an intermediary to help us get to the real meaning. To get the real meaning you need to understand the nature of the problem and I dont think there exist any icelander within the community that possesses the required knowledge to understand the nature of the problem and thus could convey it to you in a meaningful way. What I think I'm gathering from this thread is that the reason for blocking other changes is entirely because you feel that we need to hash out appropriate rules and guidelines for people to follow, or else we will end up with a wide variety of approaches that do more harm than good. If that's correct, then perhaps the answer becomes: "Packages that are not already consuming timer units MUST NOT be migrated until new guidelines are written." This is a very different (and more limited) statement.
Yes and No as in yes I feel that we need to hash out appropriate rules and guidelines for people to follow, or else we will end up with a wide variety of approaches that do more harm than good but no that is not what is blocking this change.
Yes as well as beyond the 21 timeframe no package shipping cron job will be allowed to be migrated to systemd timer units unless he already contains a systemd service unit to bind the systemd timer unit to.
Allowing for the alternative requires different integration of systemd timer in the distribution as well as an alternative feature proposal that outlines that integration.
The thing I still don't understand (but am willing to learn) is why you feel that the Change proposal cannot continue without the MUST NOT phrasing.
See above.
Now what I need to understand from you is why you are insisting allow component that does not contain systemd service units but does contain an cron job, to allowed that cron job to be migrate to systemd timer units, what benefits you see from allowing that?
Also I'm not foreseeing systemd timer neither obsoleting nor replacing cronie and cron jobs entirely in foreseeable future. I'm perfectly aware we could do that via hacks and administrative discomfort but I dont see the benefits of doing so can you explain to me the pros you think systemd timers has over cronie and cron jobs since that might help me understand what you are hoping to gain from allowing that and enlighten me in the process?
Login to comment on this ticket.