Nirik wanted me to resubmit the proposal all thou I'm not so sure why it's not like we are backing out of this now...
Basically just continuing migration process where we left off in F16.
The main hurdle still remains the same as in maintainers not packaging unit et all or early enough forcing others to step in and do it for them.
If it was not for abadger1999 and spot's packing the units we would be even further behind then we already are and it's probably best of someone is going to package this for the maintainer he does so as the unit's are submitted as opposed to do it all just before beta or some other decided deadline.
Having set of goals before a certain milestone as sgallagh proposed last release cycle work well atleast for me since I could focus on converting the legacy sysv initscript to meet that goal and anything else I converted at that time was a bonus.
It would be good if FPC could make it mandatory that new packages being introduced into the distribution contain native systemd units as opposed to legacy sys init scripts as in some policy saying that the newly introduced component would fail the review process if he did not.
Given some members of the fpc attitude against systemd and people submitting unit files you might find yourself in the shoe of having to override them in that regard.
I still think it's unreasonable goal to meet migrating them all during this release cycles as I did last time given the current rate of adoption but hey kudos to us if we manage to do that.
Note I was thinking about creating a new tracker bug for F17 and I should mention that the unit files I will be submitting will be reflecting the current state of systemd in rawhide which means they will not be backwards compatible to F15 afaik.
Can you create a f17 feature page? should be pretty easy to just copy the f16 one and adjust scope for the ones that were not done in f16.
I think a new tracker might be useful.
Feel free to take to FPC your ideas there.
Replying to [comment:1 kevin]:
Already had updated and moved the feature page back to the wrangle queue.
Ok will create a new one
We got ca 330 packages left to convert and if they failed to realize that allowing packages into the distribution containing the legacy sysv init script was and still is just adding additional load to those of us converting and package the stuff then so be it what are couple of packages more <sigh>...
I think the main issue here is to find the fastest way to roll the package out of koji with the unit files basically they kinda need to be package and shipped as they get submitted granted there exist proven packagers willing to do the necessary work.
Personally I think it's a bit excessive if all that work falls again more or less into the hands of one man to do somewhere around beta.
Maintainer can always update their packages later during the development cycle should they need any kind of fixing.
Oh yeah and it also would be good if fesco could ask maintainers if they are going to orphan their packages to do it now and perhaps again around alpha so we dont have convert something that's is scheduled or winds up to be dropped from the distribution.
FESCo decision:
Warn on fedora-devel that FESCo might decide to block the packages that violate this packaging guideline before Alpha. Defer the decision on the blocking to next meeting.
t8m will write warning email, sgalagh will start the discussion about blocking policy.
Tracker - bug 713562
Rough list of remaining packages to be converted from sysv to systemd systemd-f17.txt
Replying to [comment:5 johannbg]:
Uhum that's the old one this is the new Tracker 751869 teaches me being half in lord of the rings and half working...
Thanks for your work and info here. I don't think there's much for us to do at this time, other than urge maintainers to get to work. ;)
Hum not following so no need to write and submit unit file(s) and at the same time for proven packager(s) to package and ship them?
No, please do.
This ticket can be closed in favor of the feature ticket (IMHO). It's up to fesco to approve that one and help out the feature as much as they can.
Is there any other action from fesco here?
Replying to [comment:9 kevin]:
No, please do. This ticket can be closed in favor of the feature ticket (IMHO). It's up to fesco to approve that one and help out the feature as much as they can. Is there any other action from fesco here?
Not really other than perhaps grant explicit permission for proven packager(s) to step in and do the necessary work as in to package and ship submitted unit files and announce that they do have that authority to do that on the devel list.
Given that fesco does not have a "hit squat" on their payroll that atleast would make way for any proven packager willing to step up and do the necessary work without having to worry about maintainers getting on his/their back due to the current ownership model we have in place.
Worst case scenario would be for the proven packager to step aside ( but still provided spec file patch? ) should the maintainer actually respond and or the maintainer himself could fix things that need fixing via update but at the same time he would benefit from the work the proven packager had already done.
With the above what's slowing down the migration process is taken out of the equation and the speed of the migration process put entirely in the hands of the community as in the more that participate in migrating and packaging systemd units the faster it will be done.
I think that is as best as it can get scenario to help the migration process without having an assigned hit squat to do the packaging atleast this is the only thing I can currently come up with adding the process.
s/adding/aiding
Login to comment on this ticket.