= phenomenon = Just before freeze was commited change, which might broke few apps [1]. According to responses [2] on fedora-devel it might or might not broke or change behaviour unexpectedly.
[1] http://lists.fedoraproject.org/pipermail/scm-commits/2012-October/889150.html [2] http://lists.fedoraproject.org/pipermail/devel/2012-October/173016.html
= background analysis = The commit should go into rawhide with warning on fedora-devel. Nothing like that happened.
= implementation recommendation = Please, revert this commit and leave it only in rawhide. It's too late in development cycle for commits like this.
Reverting this gives us almost nothing. Any change to hostname, locale from the desktop will create the new files, which effectively disable the old files. The same happens when anaconda runs.
As you can see, the above mentioned change triggers only in the case the new files do not exist, which only happens if no recent anaconda never ran before on the installed system, and the user never used any of the desktop tools. Reverting this will effectively not make any real difference.
We should focus on fixing the remaining issues, if there are ones, and not try to pretend all would work with the status quo. These files are almost entirely dead to the system, they are not read if the new files exist, they are just confusing text without much effect; hence we better remove it when we detect a clear state of a transition from old to new.
Sure, there are things missing and to fix, like always, but reverting does not bring us any closer to where we need to be. Now, I would think, that removing the "does the new file exist" check and do all that unconditionally would even be the better move than reverting, sticking the head in the sand, and hope all will work.
Replying to [comment:1 kay]:
First, from the ''user'' point of view:
Reverting this gives us almost nothing. Any change to hostname, locale from the desktop will create the new files, which effectively disable the old files.
http://lists.fedoraproject.org/pipermail/devel/2012-October/173045.html suggests the existing files take precedence. So what's actually happening?
In any case, moving data from documented files without any user notification, not even a release note, is really bad form.
As detailed below, moving the information breaks other applications; without any reason to think otherwise, "the desktop tools" that move the information are therefore buggy / badly integrated with the rest of the distribution and should have been fixed to integrate better in the first place, instead of now using them as an argument that the rest needs to adapt.
The same happens when anaconda runs. As you can see, the above mentioned change triggers only in the case the new files do not exist, which only happens if no recent anaconda never ran before on the installed system, and the user never used any of the desktop tools. Reverting this will effectively not make any real difference.
The same happens when anaconda runs.
And from the ''developer'' point of view:
Sure, there are things missing and to fix, like always,
"There are things missing, like always" is not the quality standard I want to see from a core system component. How can I rely on a base like that?
We do have other software that use the existing files and not the new ones. system-config-language is a very obvious case.
but reverting does not bring us any closer to where we need to be.
(I can't see any great "need" here, but that's a side issue.) Wherever you want to go, breaking things without any notification to affected developers, and on the day of a freeze, which makes it ''close to impossible'' for the affected developers to catch up even if they noticed, is just not a way the 1279 Fedora packagers can collaborate on this distribution.
Moving the files should be a full feature, with the associated notification, documentation and testing requirements.
Don't get me wrong, I don't disagree much here, at least not with the theory behind it.
But most of the issues are already in F16+F17 and this change does not make it worse. We need to fix stuff for good. Believe me, we will not fix anything by reverting this change, it is just not the problem. It would be just ignoring the reality, not help with anything we need to do.
People just pointed out the, if you look at it from outside, obvious inconsistency with the duplicated files, which are not even read anymore, so we just went ahead and fully converted the old one to the new ones, if there is a clear detectable state.
We have delayed this problem for too long, and the above mentioned commit does not make it worse, it's just a very tiny piece in the puzzle. So, yeah, stuff is sub-optimal an inconsistent for a full year now, we just did not realize it. It goes back as far as F16, and that's where we probably missed the feature to do that, if we did.
Reverting this change will not help with anything. We need to find out what to do instead, and not pretend all was working before that change, it wasn't at all. So let's come up with a plan please, and leave the politics, rules, and formalities behind, it's too late we already missed that opportunity looong ago, and applying them now is just theater and pretty useless for users and developers.
In short: tell me to revert it, I'll just do it right away to stop this game here, but you have absolutely nothing accomplished by that, besides wasted our time; the system will carry out at least the same inconsistency as it had before.
I've put together a brief email highlighting those changes to the test list [1] asking testers to be on the lookout for any bugs that come out of this.
I'm going to see if I cant find the time to wikify all this stuff.
Although this is just a small portion of what got introduced with 194 it is something that needs to be in the release notes.
1.http://lists.fedoraproject.org/pipermail/test/2012-October/111230.html
Peter Travis just offered to clean up my English and put what I wrote there in the release notes...
I agree with Marcela, this step should be pushed to rawhide. Doing such a change just a few hours before freeze should be avoided, as it's just unnecessary. That's what rawhide is for. Also, at first glance, this change seems to be done without a real reason (I hope, I'm wrong). Doing such a step without a public notice on fedora development list is just unfriendly.
Having it documented "somewhere" makes it even ubuntu style ("The user/upstream is free to pick relevant pieces of information from launchpad"). I expect Fedora to be different from that.
As I mentioned before Peter offered to add this to the release notes as he did this weekend which should arguably take out any lack of documentation out of the discussion before final .
http://git.fedorahosted.org/cgit/docs/release-notes.git/commit/?id=1d58107d11b00d9feca651548ea1339112bd7306
There are still concerns about stability of Fedora. We have so many rules on updates into Fedora, that no-one understand them, but when bigger change before freeze arise everyone is happy about that.
As I stated in a thread I'm not sure how much damage will be done, but we shouldn't ack such changes in the last minute. It's unfair to other people who fill their feature pages and warn others about possible breakage.
Replying to [comment:2 mitr]:
Replying to [comment:1 kay]: First, from the ''user'' point of view: Reverting this gives us almost nothing. Any change to hostname, locale from the desktop will create the new files, which effectively disable the old files. http://lists.fedoraproject.org/pipermail/devel/2012-October/173045.html suggests the existing files take precedence. So what's actually happening?
FWIW, http://cgit.freedesktop.org/systemd/systemd/commit/?id=cae356ad49b505a5172d4dbb830d7ec8f32a9953 ; this happens shortly after systemd-195, i.e. is not yet in F18.
Before that, it seems that the systemd files do take precedence over the local ones.
Replying to [comment:3 kay]:
Don't get me wrong, I don't disagree much here, at least not with the theory behind it. But most of the issues are already in F16+F17 and this change does not make it worse. We need to fix stuff for good.
But most of the issues are already in F16+F17 and this change does not make it worse. We need to fix stuff for good.
Moving from one inconsistent state to a different inconsistent state is '''not free'''.
Believe me, we will not fix anything by reverting this change, it is just not the problem.
Oh, but we will fix something. (It's a mess in any case.)
So the decision is between breaking tools on upgrade to F18, and consistency of behavior in F18. Or we could extend this to revert both systemd and anaconda, and keep the F<=17 behavior for all F18 cases.
As much as I hate to say it, I prefer consistency of behavior in F18, and not invalidating anaconda testing, i.e. keeping F18 as it is. (Thanks to Johann and Peter to taking care of the release note.)
And the reason I hate to say it:
So let's come up with a plan please, and leave the politics, rules, and formalities behind, it's too late we already missed that opportunity looong ago,
The "politics, rules and formalities" are how the 1200 developers coordinate. Ignoring them rewards the uncooperative behavior.
I have filed https://bugzilla.redhat.com/show_bug.cgi?id=871119 for system-config-language; please do at least a little work to support the "politics, rules and formalities", and find and file bugs against any other affected component.
(The decision of what to do in F18 remains up to FESCo on the next meeting; considering that nobody is proposing to block it forever, and supporting the systemd files would be an improvement even on older releases, AFAICS the bugs can be filed now.)
obvious other candidates to check are the KDE and GNOME control center applets, which can do stuff to clocks, language and keyboard settings. we have system-config-date and system-config-keyboard that are Fedora specific. I believe system-config-date is already being worked on and there is an update for testing at present. I'm not sure if Xfce has applets for configuring any of this, but it may.
Replying to [comment:11 adamwill]:
At least GNOME uses systemd's timedated mechanism anyway, so will do the right thing anyway. Not sure about KDE.
At today's FESCo meeting we agreed to:
AGREED: Kay should make sure all the packages affected to use the new config files.
Kay, can you please make sure all affected packages are fixed up asap? Thanks.
I would leave it open until we will some analysis (and patches). I guess voices on fedora-devel are saying we should control changes more thoroughly.
Kay, we are waiting for your reply. I do not have any idea how to find out, which packages might be broken by your change. But you was working on the change, so you have probably more information about the area. I'd like to see list of packages, which are using old config files and fixes for them.
No activity in last two weeks. Revert it or find out if Kay is responsive maintainer?
In the FESCo meeting on 2012-10-31 the availability of a machine with an exploded Fedora source tree was mentioned. Kay and I tried to get information on how to access it. mjg59 told us it's ihatethathostname.lab.bos.redhat.com. He said he'd found out who can grant us access to it. I understand he's been busy, so we haven't received this information yet. If anyone else knows, please tell us.
Kay or Michael, drop me an email and I'll get this sorted. Sorry for the delay.
Defer for now and see if mjg59 can get them access to the info they seek (+8,-0)
Packages scanned, sources reviewed, individual bugs filed, tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=881785
Many of these are done, but there's more that aren't.
I think the remaning ones can be post release updates.
Adding meeting here to discuss in meeting and see if there's anything we want to try and get in before release.
The only one we are concerned with is firstboot.
If it turns out firstboot is always using en_US.UTF8 instead of the users install language, we will fix that one and get it added as a blocker. Other packages can fix this now in rawhide or as a post release update.
firstboot was fixed with https://bugzilla.redhat.com/show_bug.cgi?id=892097. Closing this out per 2013-01-09 FESCo meeting.
Login to comment on this ticket.