Ticket #963 (closed task: fixed)

Opened 18 months ago

Last modified 16 months ago

change of names of configuration files

Reported by: mmaslano Owned by:
Priority: major Keywords: meeting
Cc: kay, michich Blocked By:
Blocking:

Description

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.

Change History

comment:1 follow-up: ↓ 2 Changed 18 months ago by kay

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.

comment:2 in reply to: ↑ 1 ; follow-ups: ↓ 9 ↓ 10 Changed 18 months ago by mitr

Replying to 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.

  • On upgrades, anaconda doesn't run in the traditional sense any more.
  • These kinds of data are typically set during installation and never modified by a GUI. I'd expect any use of "the desktop tools" to be rarer than using any configuration management system to manage the old file, which is broken by the change.

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.

comment:3 Changed 18 months ago by 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. 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.

comment:4 Changed 18 months ago by johannbg

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

comment:5 Changed 18 months ago by johannbg

Peter Travis just offered to clean up my English and put what I wrote there in the release notes...

comment:6 Changed 18 months ago by mrunge

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.

comment:7 Changed 18 months ago by johannbg

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

comment:8 Changed 18 months ago by mmaslano

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.

comment:9 in reply to: ↑ 2 Changed 18 months ago by mitr

Replying to mitr:

Replying to 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.

comment:10 in reply to: ↑ 2 Changed 18 months ago by mitr

Replying to 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.

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.)

  • F<=17: Anaconda creates /etc/sysconfig/i18n; tools using /etc/sysconfig/i18n work unless and until tools using /etc/locale.conf are used; tools using /etc/locale.conf work.
  • F18, new install: Anaconda creates both; tools using /etc/sysconfig/i18n don't work, tools using /etc/locale.conf work.
  • F18 before change, update: old files exist; tools using /etc/sysconfig/i18n work unless and until tools using /etc/locale.conf are used; tools using /etc/locale.conf work.
  • F18 after change, update: old files exist and are migrated; tools using /etc/sysconfig/i18n don't work; tools using /etc/locale.conf work.

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.)

comment:11 follow-up: ↓ 12 Changed 18 months ago by adamwill

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.

comment:12 in reply to: ↑ 11 Changed 18 months ago by lennart

Replying to adamwill:

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.

At least GNOME uses systemd's timedated mechanism anyway, so will do the right thing anyway. Not sure about KDE.

comment:13 Changed 18 months ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

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.

comment:14 Changed 18 months ago by mmaslano

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Keywords meeting removed

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.

comment:15 Changed 18 months ago by mmaslano

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.

comment:16 Changed 18 months ago by mmaslano

  • Keywords meeting added

No activity in last two weeks. Revert it or find out if Kay is responsive maintainer?

comment:17 Changed 18 months ago by michich

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.

comment:18 Changed 18 months ago by michich

  • Cc michich added

comment:19 Changed 18 months ago by mjg59

Kay or Michael, drop me an email and I'll get this sorted. Sorry for the delay.

comment:20 Changed 18 months ago by mmaslano

  • Keywords meeting removed

Defer for now and see if mjg59 can get them access to the info they seek (+8,-0)

comment:21 Changed 17 months ago by kay

Packages scanned, sources reviewed, individual bugs filed, tracker bug is here:

https://bugzilla.redhat.com/show_bug.cgi?id=881785

comment:22 Changed 16 months ago by kevin

  • Keywords meeting added

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.

comment:23 Changed 16 months ago by kevin

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.

comment:24 Changed 16 months ago by jwboyer

  • Status changed from reopened to closed
  • Resolution set to fixed

firstboot was fixed with https://bugzilla.redhat.com/show_bug.cgi?id=892097. Closing this out per 2013-01-09 FESCo meeting.

Note: See TracTickets for help on using tickets.