===================================
#fedora-meeting: FESCO (2012-10-31)
===================================
Meeting started by nirik at 17:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-10-31/fesco.2012-10-...
.
Meeting summary
---------------
* init process (nirik, 17:00:01)
* #932 F18 Features - progress at Feature Freeze (nirik, 17:02:28)
* LINK:
https://fedorahosted.org/fesco/ticket/932 (nirik, 17:02:28)
* LINK:
http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset?h=f18
(nirik, 17:06:18)
* #960 F18 schedule + the holidays (nirik, 17:24:48)
* LINK:
https://fedorahosted.org/fesco/ticket/960 (nirik, 17:24:49)
* AGREED: if we slip on Thursday, pull 1 week from schedule after beta
release but before final freeze (nirik, 17:39:10)
* #961 Clarification request- Is Java (including the JVM) exempt from
Multilib (nirik, 17:39:44)
* LINK:
https://fedorahosted.org/fesco/ticket/961 (nirik, 17:39:44)
* LINK:
https://fedoraproject.org/wiki/Category:FESCo_policy (nirik,
17:44:03)
* AGREED: proposal is accepted (nirik, 17:44:50)
* #963 change of names of configuration files (nirik, 17:45:00)
* LINK:
https://fedorahosted.org/fesco/ticket/963 (nirik, 17:45:00)
* AGREED: Kay should make sure all the packages affected to use the
new config files. (nirik, 17:59:58)
* Daylight savings time change (nirik, 18:00:26)
* AGREED: Move ahead to 18UTC starting next week. Those people who's
lunch are affected update the wiki. ;) (nirik, 18:05:06)
* Chair next week (nirik, 18:05:12)
* ACTION: t8m to chair next weeks meeting (nirik, 18:05:45)
* Open Floor (nirik, 18:05:50)
Meeting ended at 18:15:39 UTC.
Action Items
------------
* t8m to chair next weeks meeting
Action Items, by person
-----------------------
* t8m
* t8m to chair next weeks meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (129)
* jreznik (50)
* mjg59 (48)
* mitr (34)
* notting (25)
* mmaslano (20)
* t8m (14)
* jwb (11)
* limburgher (10)
* pjones (9)
* zodbot (8)
* Viking-Ice (5)
* gholms (4)
* adamw (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`:
http://wiki.debian.org/MeetBot===================================
#fedora-meeting: FESCO (2012-10-31)
===================================
Meeting started by nirik at 17:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-10-31/fesco.2012-10-...
.
Meeting summary
---------------
* init process (nirik, 17:00:01)
* #932 F18 Features - progress at Feature Freeze (nirik, 17:02:28)
* LINK:
https://fedorahosted.org/fesco/ticket/932 (nirik, 17:02:28)
* LINK:
http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset?h=f18
(nirik, 17:06:18)
* #960 F18 schedule + the holidays (nirik, 17:24:48)
* LINK:
https://fedorahosted.org/fesco/ticket/960 (nirik, 17:24:49)
* AGREED: if we slip on Thursday, pull 1 week from schedule after beta
release but before final freeze (nirik, 17:39:10)
* #961 Clarification request- Is Java (including the JVM) exempt from
Multilib (nirik, 17:39:44)
* LINK:
https://fedorahosted.org/fesco/ticket/961 (nirik, 17:39:44)
* LINK:
https://fedoraproject.org/wiki/Category:FESCo_policy (nirik,
17:44:03)
* AGREED: proposal is accepted (nirik, 17:44:50)
* #963 change of names of configuration files (nirik, 17:45:00)
* LINK:
https://fedorahosted.org/fesco/ticket/963 (nirik, 17:45:00)
* AGREED: Kay should make sure all the packages affected to use the
new config files. (nirik, 17:59:58)
* Daylight savings time change (nirik, 18:00:26)
* AGREED: Move ahead to 18UTC starting next week. Those people who's
lunch are affected update the wiki. ;) (nirik, 18:05:06)
* Chair next week (nirik, 18:05:12)
* ACTION: t8m to chair next weeks meeting (nirik, 18:05:45)
* Open Floor (nirik, 18:05:50)
Meeting ended at 18:15:39 UTC.
Action Items
------------
* t8m to chair next weeks meeting
Action Items, by person
-----------------------
* t8m
* t8m to chair next weeks meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (129)
* jreznik (50)
* mjg59 (48)
* mitr (34)
* notting (25)
* mmaslano (20)
* t8m (14)
* jwb (11)
* limburgher (10)
* pjones (9)
* zodbot (8)
* Viking-Ice (5)
* gholms (4)
* adamw (2)
--
17:00:01 <nirik> #startmeeting FESCO (2012-10-31)
17:00:01 <zodbot> Meeting started Wed Oct 31 17:00:01 2012 UTC. The chair is nirik.
Information about MeetBot at
http://wiki.debian.org/MeetBot.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:01 <nirik> #meetingname fesco
17:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:00:01 <nirik> #topic init process
17:00:01 <zodbot> The meeting name has been set to 'fesco'
17:00:01 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting
pjones t8m
17:00:07 * limburgher here
17:00:07 <jwb> i am present
17:00:16 <notting> i am here as well
17:00:20 <mmaslano> hi
17:00:32 <nirik> thats 5, so we have quorum. ;)
17:01:01 <nirik> pjones / mjg59 / t8m / mitr ?
17:01:06 <t8m> hi
17:02:23 <nirik> ok, lets go ahead and get started.
17:02:28 <nirik> #topic #932 F18 Features - progress at Feature Freeze
17:02:28 <nirik> .fesco 932
17:02:28 <nirik>
https://fedorahosted.org/fesco/ticket/932
17:02:30 <zodbot> nirik: #932 (F18 Features - progress at Features 100% Complete
deadline (was: Feature Freeze)) – FESCo -
https://fedorahosted.org/fesco/ticket/932
17:02:35 <mitr> Hello all
17:02:36 <mjg59> Hi
17:02:43 <nirik> jreznik had an update this morning on the ticket.
17:03:05 * jreznik is ready here
17:03:28 <jreznik> the power features and owncloud postponed to f19
17:03:40 <nirik> +1 on that.
17:03:58 <notting> what exactly is missing in the rngd one?
17:04:15 <jreznik> notting: how to switch it default-on
17:04:25 <jreznik> last time I was talking with jeff
17:05:09 <jreznik> cite: "Just looking for a pointer to the proper systemd
switch to make it default-on..."
17:05:35 <notting> that's the preset file
17:05:39 <nirik> that would be a bug against systemd to change it's default on
preset?
17:05:48 * pjones is here.
17:05:53 <pjones> sorry, bit late.
17:05:58 <jreznik> hmm, indeed, it's a preset thing
17:06:18 <nirik>
http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset?h=f18
17:06:26 <jreznik> ok, I can point him to presets
17:06:48 <mmaslano> we should probably improve our guidelines if it's not
obvious
17:08:29 <nirik> ok, so any objections to the power features and owncloud going to
f19? any others we should punt to f19 now?
17:08:37 <jwb> no
17:08:41 <jreznik> nirik: I already did it
17:08:50 <nirik> jreznik: great
17:08:57 <jreznik> for power and owncloud
17:09:24 <jreznik> no reply for openshift origin about the current status, so
I'm +1 moving to F19
17:09:40 <jreznik> rngd should be still doable and simple one... so not sure
17:09:41 <jwb> yeah, agreed. i don't think the ruby thing is going to get
cleared up in time
17:10:00 <nirik> yeah, I think I saw in the cloud meeting that they were now going
to target f19
17:10:11 <jreznik> ok
17:10:28 <nirik> "<tdawson> We're going to shoot for Fedora 19 as a
feature."
17:10:45 <mmaslano> ok
17:11:37 <nirik> Usermode Migration ?
17:12:05 <t8m> this is definitely not finished yet
17:12:09 <jreznik> nirik: as notting said, it's more continuous effort, same as
sysvtosystemd
17:12:18 <t8m> and won't be in F18
17:12:50 <jreznik> so the question is how to deal with these long term features,
reapprove for every release?
17:13:18 <nirik> jreznik: they should change the feature to match whats done NOW and
put it to 100% and then redo a feature next release with what they are going to do
then'
17:13:26 <limburgher> I think that's a discussion for the feature process
improvement conversation.
17:14:04 <notting> nirik: in the usermode migration case, then, it's just
move-to-f19
17:14:10 <jreznik> notting: ok
17:14:24 <notting> the infrastructure work there, but if the feature is
'migration', basically nothing has been migrated
17:15:05 <nirik> right, fine with me.
17:16:00 <nirik> new installer ui is at 80%?
17:16:18 <mitr> jreznik: Long-term I think we do need to develop a process for
"everyone fix your own packages NOW or else" - but that's a completely
separate discussion
17:16:20 <jreznik> nirik: for sysvsystemd I ask Viking-Ice to do it, we were arguing
how to solve it :)
17:17:07 <jreznik> nirik: new installer ui - we should be tracking it and it's
definitely not 100% now and it would be foolish to ask anaconda to say it's 100% done
17:17:18 <nirik> it isn't ?
17:17:35 <nirik> what parts of functionality are not yet written and testable?
17:18:03 <mitr> Iignoring code quality, do we have 100% of expected (by whom?)
features, or do we need to release-note dropped functionality?
17:18:05 <jreznik> nirik: if we consider fedup for example as part of rewrite? to
have feature parity?
17:18:27 <nirik> "At the Beta Change Deadline new features must be code
complete meaning that all the code required to enable to the new feature is
finished."
17:19:25 <mmaslano> ok, that might be a problem
17:19:29 <jreznik> nirik: and we are tracking it in
https://fedorahosted.org/fesco/ticket/946 aren't we? as it's a different feature
to the rest...
17:19:53 <nirik> sure, I just don't think 80% is accurate... but nevermind
that.
17:19:53 <nirik> Anything else on this ticket?
17:20:00 <nirik> shall we close it now?
17:20:21 <jreznik> nirik: ok, I'll work with anaconda on updates
17:20:40 <jreznik> pjones: what about secure boot one?
17:20:46 <mjg59> It's code complete
17:20:59 <pjones> right now we're waiting on lawyers, with whom we've just
had a phone call that was fairly promising
17:21:03 <mjg59> The final signing hasn't been done because we're still
blocked on legal agreement
17:21:08 <mjg59> But this week really this time
17:21:23 <pjones> we need to do a couple of builds of the three packages in question
and then get one signed (which will actually wind up being a 4th package)
17:21:39 * nirik doesn't see any other sub 100% ones to deal with off hand.
17:22:48 <Viking-Ice> nirik we just keep doing the same with sysvtosystemd feature
as we did previously release cycle
17:22:55 * nirik listens to the crickets
17:23:02 <jreznik> pjones: well as it's code complete, it could be probably set
to 100%
17:23:14 <nirik> Viking-Ice: right. update to whats done now, repurpose for f19 to
do more.
17:23:27 <pjones> jreznik: if you want to change the wiki that's fine.
17:23:33 <Viking-Ice> nirik, it's not unlikely that there will be new feature
process in f19 ( or at least I hope so )
17:23:45 <nirik> Viking-Ice: I think we all do. ;)
17:23:56 <nirik> (hope it's changed that is)
17:24:06 <limburgher> indeed
17:24:10 <nirik> anyhow, if no objections, close this ticket and move on to next...
17:24:12 <pjones> jreznik: *I'm* not going to change the wiki until it actually
works.
17:24:19 <pjones> But it's a wiki.
17:24:36 <jreznik> pjones: fair enough
17:24:48 <nirik> #topic #960 F18 schedule + the holidays
17:24:48 <nirik> .fesco 960
17:24:49 <nirik>
https://fedorahosted.org/fesco/ticket/960
17:24:51 <zodbot> nirik: #960 (F18 schedule + the holidays) – FESCo -
https://fedorahosted.org/fesco/ticket/960
17:25:09 <nirik> so, not sure what we want to do here. It seems likely we will slip
at least another week.
17:25:22 <mmaslano> jreznik: 23th of December?
17:25:23 <limburgher> It does.
17:25:25 <mmaslano> or in January?
17:25:26 * nirik finds it hard to discuss abstracts until we know more .
17:25:33 <nirik> no
17:25:48 <nirik> current release is scheduled for 2012-12-11
17:25:59 <nirik> if we slip a week (as seems likely) it will be 2012-12-18
17:26:15 <jreznik> for now, it's still ok but we're going to slip probably
one more week... that's 18
17:26:21 <nirik> right.
17:26:35 <jreznik> so would be great to have at least one spare week to cut off from
current schedule
17:26:56 <jreznik> and yeah, latest date this year could be 23, dgilmore seems to be
ok with that
17:27:02 <nirik> jreznik: where do you propose cutting it?
17:27:34 <t8m> I'd rather like to see a nice Fedora 18 release some time in 2013
than buggy and ugly Fedora 18 release in 2012.
17:27:41 <nirik> one of the weeks after beta release but before final freeze?
17:27:48 <jreznik> nirik: yep
17:27:55 <notting> so, we essentially have 2 'weeks' of wiggle room in the
current process, one of which we're likely to take RSN
17:28:01 <nirik> t8m: agreed. I don't think anyone is proposing changing release
critera tho
17:28:32 <mitr> t8m: right, but a part of the release process is indepenent on
results quality. We can have a golden image and continue work on improving the website in
the week it takes to mirror and prepare the GA.
17:29:02 <mitr> So _if_ the critical path on the schedule was websites or something
else not related to anaconda, there might be a wiggle room.
17:29:27 <mitr> Right now that's seems purely theoretical though.
17:29:31 <jreznik> mitr: yep
17:29:42 <jreznik> I'd like to ask teams on readiness meeting
17:29:55 <nirik> well, I don't think we can reduce mirroring time any... but
thats not super long already.
17:30:09 <jreznik> dgilmore, docs team, commonbug people are ok right now with it
17:30:26 <jreznik> nirik: we need three days
17:30:31 <nirik> I'd be ok with pulling a week out of the time between beta
release and before final freeze. Other than that, I don't see much place for getting
back a week
17:30:52 <jreznik> nirik: in case we slip now (and probably we will)
17:31:03 <nirik> jreznik: we currently have 4-5... stage content on friday, release
on tuesday.
17:31:08 <mitr> (s/results/released ISO/ above, the other teams do produce results
and I didn't want to imply otherwise)
17:31:15 <nirik> if that time is reduced, we will have fewer mirrors ready
17:31:46 <jreznik> nirik: that's what dennis told me, it should be enough...
17:31:59 <jreznik> as a real minimum
17:32:20 <nirik> ok. ;(
17:32:32 * nirik isn't happy with 3 days particularly, but we could try and make it
work.
17:32:33 <mitr> FWIW aiming at the 23rd sounds like a challenge in any case -
I'd expect quite a few people, at least in Europe, to take the whole week starting
with 22nd off.
17:33:12 <nirik> anyhow, we can: a) do nothing and revisit this next week, b) pull 1
week from the schedule now between beta/final freeze c) something else?
17:33:14 <jreznik> mitr: I know, I wanted to do so too... but it really depends on
what problem we will hit
17:33:35 <notting> mitr: right, but at t-1 day, the number of people needed is much
smaller
17:33:53 <jreznik> nirik: let's do a) and revisit if we slip... and I'll ask
on Thursday readiness meeting if this will work for the rest of folks
17:34:03 * nirik is fine with that.
17:34:19 <jreznik> notting: indeed, it depends on what issue we will hit...
17:35:01 <jreznik> nirik: on the other hand it will look silly to move schedule back
if we slip, so b) could be a good idea too
17:35:23 <nirik> jreznik: well, ideally we do that if we slip a week (which seems
pretty likely)
17:35:28 <jreznik> what about - if we slip on Thursday, pull 1 week from schedule/
17:35:34 <nirik> right.
17:35:55 <jreznik> and no objections are raised on readiness meeting
17:36:02 <t8m> +1
17:36:05 <jreznik> (follows go/no-go)
17:36:57 <jreznik> anyone else? I see nirik ok with it, t8m...
17:37:04 <limburgher> +1
17:37:05 * nirik is +1 as well, it means less non freeze time for developers, but I think
at this point we all just want to get f18 out.
17:37:23 <limburgher> nirik: out, and as high-quality as humanly possible.
17:37:25 <notting> ok, +1
17:37:31 <mmaslano> +1
17:37:51 <nirik> so, that would mean, slip a week, but keep all milestones after
beta release the same right?
17:38:00 <mjg59> +1
17:38:03 <jwb> +1
17:38:04 <jreznik> nirik: yep
17:39:09 <jreznik> Final Change Deadline would be still Mon 2012-11-26
17:39:10 <nirik> #agreed if we slip on Thursday, pull 1 week from schedule after
beta release but before final freeze
17:39:22 <nirik> ok, anything else on this?
17:39:44 <nirik> #topic #961 Clarification request- Is Java (including the JVM)
exempt from Multilib
17:39:44 <nirik> .fesco 961
17:39:44 <nirik>
https://fedorahosted.org/fesco/ticket/961
17:39:46 <zodbot> nirik: #961 (Clarification request- Is Java (including the JVM)
exempt from Multilib) – FESCo -
https://fedorahosted.org/fesco/ticket/961
17:40:27 * limburgher steps away briefly
17:40:27 <mjg59> Are there any cases where this actually matters?
17:40:32 <mjg59> I don't know java well enough
17:40:33 <nirik> so, drop 32bit support? ;) sorry
17:41:01 <notting> mjg59: someone manually installing a 32-bit browser and wanting
java plugin support, i suppose
17:41:04 <nirik> So, it seems that this is already the case, and they just want us
to note it officially...
17:41:10 <mjg59> notting: Ok
17:41:11 <mitr> mjg59: Yes, java applications can, and fairly frequently do, include
native extensions. I.e. supporting 32-bit-only Java apps.
17:41:14 <nirik> and fixing it would be 'difficult'
17:41:20 <notting> but yes, this is the de-facto policy
17:41:22 <mjg59> Oh, great
17:41:36 <mjg59> I'm glad "Write once, run anywhere" was such a
success
17:42:05 <mjg59> So sure, unless we have a good plan for changing practice policies
should represent practice
17:42:05 <mitr> mjg59: The Java standard library just doesn't have enough
interfaces to the underlying OS, so...
17:42:06 <nirik> on the one hand, I feel for them... on the other hand, how come
they get to ignore the horror of multilib and others don't. ;)
17:42:16 <notting> mitr: i may be misremembering, but where i usually hit those is
web apps that see 'linux' in browser string, and just hand you 32-bit x86 linux
jni libraries on the assumption that all linux is 32-bit x86?
17:42:19 <mjg59> I'm +1
17:42:20 <mitr> Based on
https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#No...
, the only solution would basically to turn all .noarch into arch rpms
17:42:23 * jwb steps away for a few min
17:42:50 <mitr> notting: I really don't know much.
17:42:59 <notting> but in any case, i'm +1 to this
17:43:04 <mitr> Just based on the link above, +1
17:43:06 * nirik is a reluctant +1, not sure where to document really tho.
17:43:39 <mitr> We (FESCo) really need a page that logs decisions...
17:43:47 <mmaslano> +1 java sig knows better than we do
17:43:47 <t8m> +1 as that's unfortunately the only thing that could be done just
now
17:44:00 <mitr> but this could simply got into the Java part of the packaging
guidelines I think.
17:44:03 <nirik>
https://fedoraproject.org/wiki/Category:FESCo_policy
17:44:07 <nirik> but yeah
17:44:37 <nirik> ok, thats enough to pass.
17:44:50 <nirik> #agreed proposal is accepted
17:45:00 <nirik> #topic #963 change of names of configuration files
17:45:00 <nirik> .fesco 963
17:45:00 <nirik>
https://fedorahosted.org/fesco/ticket/963
17:45:01 <zodbot> nirik: #963 (change of names of configuration files) – FESCo -
https://fedorahosted.org/fesco/ticket/963
17:45:36 <nirik> so, what do we want to do here.
17:45:41 * nirik thinks what a mess.
17:46:08 <mjg59> It's not like it's hard to check the tree for every package
that references these files
17:46:32 <mitr> mjg59: Right, but someone has to do it.
17:46:35 <mmaslano> in mailing thread were mentioned some problems
17:46:45 <mjg59> Right. But that could have been done in the time that thread took.
17:47:00 <mitr> mmaslano: that particular mail referenced prefdm which is removed in
f18
17:47:06 * t8m thinks that people who introduce such changes should do that work.
17:47:11 <mjg59> #proposal Tell Kay to check an exploded tree and just fix
everything
17:47:28 * nirik agrees with t8m
17:47:30 <mitr> +1
17:47:44 <t8m> +1
17:47:45 <mmaslano> +1 to mjg proposal
17:48:10 <nirik> sure, +1 although a full exploded tree is going to be a pile of
stuff.
17:48:20 <mjg59> nirik: We've got one internally he can get access to, I think
17:48:26 <mjg59> I'll find out how up to date it is
17:48:28 <nirik> oh? cool.
17:48:33 <notting> and it's always possible to make one, given bandwidth and
time
17:48:47 * nirik nods.
17:49:05 <nirik> thats +4?
17:49:22 <mitr> notting: ... or closely collocated shell machines, which I think
exist
17:49:36 <notting> i'm not up on the devel@ list thread ... this is definitely a
problem. i'd be ok with just going through and fixing everything. I believe that even
once we do so, manual modification of the old files should still work, if the admin has
scripts that do that
17:49:58 <mitr> notting: Once the new files exist, systemd ignores the old ones
AFAICS
17:50:19 <notting> mitr: the last time i looked at the code, the old files were read
in preference to the new ones on startup
17:50:37 <notting> with the exception of /etc/hostname
17:50:56 <jwb> +1
17:51:10 <mitr> notting: I may have misread the code. I did ask in the ticket and
got no response...
17:52:10 <nirik> proposal: Kay (or other provenpackager(s)) should go and fix all
the config files to use the new files
17:52:13 <notting> so i'm +1 to Fixing Things
17:52:17 <nirik> is that what we are agreeing to?
17:52:30 <mjg59> nirik: Well I was explicitly saying that Kay should take the lead
17:52:37 <nirik> ok.
17:52:55 <nirik> but new files is what we want to fix everything to right? to be
consistent?
17:53:00 <mmaslano> nirik: provenpackers tent to do nothing
17:53:02 <mmaslano> tend
17:53:28 <nirik> we can't force them to, but if someone stepped up and said they
would do it, wouldn't that be ok?
17:53:41 <mmaslano> yeah, but how many times it happened?
17:53:43 <mitr> notting: in
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/locale-setup.c?...,
parse_env_file returns >0 if the file contains something; locale.conf goes first, and
that causes the other files to be ignored.
17:54:06 <mitr> mmaslano: We are not proposing a general "everyone go fix
it" mandate, but asking a specific person to do it.
17:54:18 <nirik> proposal: Kay should go and fix all the packages affected to use
the new config files.
17:54:22 <nirik> ^ is that better?
17:54:24 <Viking-Ice> just pointing out that deleting the old file ( once migrated )
is the right thing to do to avoid confusion among users and quickly identify problems (
from my pov )
17:54:34 <mitr> nirik: Isn't that exactly what mjg59 proposed above?
17:54:35 <mjg59> nirik: Kay should cause all the affected packages to use the new
config files
17:54:46 <mjg59> I don't care whether he does it himself
17:54:48 <nirik> mitr: I am trying to make it clear for the agreed and ticket.
17:54:54 <mjg59> As long as he makes sure it's done
17:54:54 <nirik> "fix it" is not clear
17:55:16 <mitr> nirik: oh, right
17:55:20 <mjg59> well I don't think we're talking about neutering
17:55:22 <notting> mitr: aha, didn't see how parse_env_file handled return
codes
17:55:22 <jreznik> is this for f18 - as fix things at least for beta would not
work... freeze...
17:55:36 <nirik> "fix it" could also mean back out the change and make
everything use the old files.
17:55:46 <mjg59> One way or the other
17:55:49 <mjg59> I suspect I know his preference
17:55:55 <nirik> right.
17:56:31 <nirik> jreznik: these changes can be fixed in updates no? or does anaconda
need further changes for this?
17:56:54 <notting> jreznik: the problem is 1) we have this file confusion since f-16
2) with anaconda currently writing both files, it's currently *worse* (AIUI), so we
should do Something to make things consistent. at least, as i understand it
17:57:07 <gholms> mjg59: Does that involve actually doing the work, or is simply
filing bugs against affected packages sufficient?
17:57:12 <jreznik> nirik: and if we hit some bad breakage - there's beta blocker
process
17:57:15 <mjg59> gholms: Make it happen
17:57:46 <gholms> mjg59: One interpretation of that is "I can file bugs and
walk away." Hence my question.
17:57:54 <mjg59> That's not an interpretation, no
17:58:00 <gholms> Alrighty then.
17:58:03 <mmaslano> so, Kay should go through all packages using those old
configuration files and fix them. Right?
17:58:07 <mjg59> Right
17:58:18 <nirik> proposal: Kay should make sure all the packages affected to use
the new config files.
17:58:26 <mjg59> I can't imagine it taking more than an order of magnitude
longer than this conversation has
17:58:30 <mjg59> +1
17:58:35 <mitr> mmaslano: and/or talk to the package owner and ensure that the owner
does it
17:58:37 <mitr> +1
17:58:50 <nirik> sure, +1. lets get this done and over with.
17:59:02 <t8m> +1
17:59:20 <jwb> +1 (again)
17:59:25 <mmaslano> +1
17:59:49 <notting> +1. also need relnotes, but it looks like someone took care of
that?
17:59:58 <nirik> #agreed Kay should make sure all the packages affected to use the
new config files.
18:00:20 <nirik> notting: seems so.
18:00:24 <nirik> ok, moving on...
18:00:26 <nirik> #topic Daylight savings time change
18:00:33 <nirik> DST changes in the us this upcoming weekend.
18:00:39 <nirik> are we sticking to same UTC time?
18:00:44 <notting> proposal: get UN to make EU and US coordinate DST schedules.
18:00:49 <nirik> ha
18:01:00 <gholms> Heh
18:01:06 <t8m> notting, +1 are you taking action item to do that ? :D
18:01:18 <mjg59> EU already changed
18:01:20 <jwb> that would mean noon eastern time?
18:01:28 <nirik> anyhow, I always forget... shall we just stick to UTC and ignore
timezone stupidity
18:01:31 <mjg59> Let's move back an hour so it's just the same as it was
before
18:01:44 <mjg59> Then this week is the only bizarro week
18:01:51 <pjones> EU already changed. If we were going to change it for the gap
week, we should have done that /this/ week.
18:01:54 <t8m> mjg59, I suppose you mean forward an hour?
18:02:00 <mjg59> t8m: Yeah
18:02:06 <mjg59> Fucking timezones, how do they work
18:02:06 <t8m> +1 then
18:02:14 <mmaslano> I would be fine with meeting at six, but it might be problem for
you ;-)
18:02:25 <mjg59> Keeping the same UTC time means I miss lunch
18:02:28 <mjg59> And then I'll be cranky
18:02:30 * pjones +1 to moving it with the DST change.
18:02:40 * mitr doesn't care about moving at all
18:02:52 <mitr> Can I abstain in a way that removes me from the quorum?
18:02:53 <nirik> I only care in that we need to then change all the wiki pages, etc.
;)
18:02:57 * notting says... pick something.
18:03:25 <nirik> proposal: Move ahead to 18UTC starting next week. Those people
who's lunch are affected update the wiki. ;)
18:03:33 <mitr> :)
18:03:53 <notting> nirik: +1 to having something written down
18:04:14 <mmaslano> +1
18:04:26 * nirik is +1 for his own proposal of course.
18:04:35 * limburgher back. FInally.
18:04:41 <mjg59> +1
18:04:43 <limburgher> Ugh.
18:04:45 <t8m> +1
18:04:54 <limburgher> +1
18:05:06 <nirik> #agreed Move ahead to 18UTC starting next week. Those people
who's lunch are affected update the wiki. ;)
18:05:12 <nirik> #topic Chair next week
18:05:16 <nirik> who wants it?
18:05:28 <t8m> I can do it
18:05:37 <nirik> thanks.
18:05:45 <nirik> #action t8m to chair next weeks meeting
18:05:50 <nirik> #topic Open Floor
18:05:58 <nirik> anyone have anything for open floor?
18:06:00 <mjg59> Did we skip the LVM one on the basis of the votes in the ticket?
18:06:29 <nirik> mjg59: yes, it passed in ticket to revert back to lvm by default.
18:06:30 <mmaslano> well it had +5 votes
18:06:35 <mjg59> Sure
18:06:41 <mmaslano> I wonder if anaconda people read the ticket
18:06:45 <nirik> which we should make sure and communicate to anaconda folks
18:07:08 <notting> pjones is *a* anaconda/anaconda-related person, and is on fesco.
so....
18:07:15 <mjg59> I'm not entirely happy with this being done without actual
discussion of the impact of LVM on our users
18:07:15 <notting> but yes, explicit communication better than implicit
18:07:27 <mjg59> But the same probably applies to the original change
18:07:27 <jreznik> it's more question - do fesco wants it in beta even we would
not slip this Thursday? as it would lead to the slip again
18:07:55 <jreznik> mjg59: yep, the original was not discussed at all too...
18:08:13 <mjg59> So we should plausibly aim to have an actual discussion about that
for f19
18:08:20 <nirik> mjg59: I agree.
18:08:30 <nirik> also with btrfs in the mix to see if thats finally ready or not
18:08:39 <mjg59> There is some promising LVM-based work coming, and it'd be good
to know how that can be integrated
18:08:44 <jwb> nobody will be making btrfs the default without discussion.
18:08:52 * nirik nods.
18:09:16 <nirik> also, it's worth noting that all of this is 'defaults',
you can choose something else if you really love it better.
18:09:19 <mitr> mjg59: I haven't seen any noted impact (one suggestion of
performace problems), beyond problems with rescuing the system but the anaconda boot.iso
"should" usually take care of it.
18:09:32 <mjg59> mitr: Interoperability is the main one
18:09:35 <mitr> jreznik: Is a slip caused entirely by LVM a real threat?
18:09:43 <nirik> mitr: I doubt it
18:09:50 <mitr> In any case, I'm strongly against changing the default after
beta
18:09:54 <mjg59> adamw: Some LVM-by-default testing had been done, right?
18:10:03 <nirik> mjg59: yes.
18:10:11 <mjg59> adamw: Would you feel comfortable with it being changed pre-beta?
18:10:50 <nirik> mjg59: see comments on ticket.
18:10:57 <jreznik> mitr: as we do not have RC and it's Wed today...
18:10:59 <jreznik> no
18:10:59 <adamw> mjg59: huh? oh. we've actually already moved on the basis that
fesco had voted to make the change for beta.
18:11:24 <adamw> i marked the bug as acceptednth and anaconda team is pulling the
fix into 18.22.
18:11:26 <Viking-Ice> I would very much like for fesco to considered giving us in QA
2 whole development cycle to test btrfs before making it the default so we could work in
advantage and try to have the transition as smooth as possible as in do target testing
documentation writing what not in F19 and make the switch in F20
18:11:54 <mjg59> adamw: Ok
18:12:12 <nirik> Viking-Ice: sure, as far as I know no one has yet formally asked
for btrfs by default... but that would be a good thing to talk about them with for sure.
18:12:13 <mjg59> adamw: Well that certainly answers my question :)
18:12:15 <jwb> Viking-Ice, make a note of that on the feature when it's filed.
or open a ticket. different meeting at the very least
18:12:31 <nirik> ok, any more open floor stuff?
18:12:59 <Viking-Ice> jwb thought this was open floor time?
18:13:22 <mitr> Viking-Ice: The Fedora space has been _very_ quiet about btrfs
status for some time...which makes things difficult to judge - in itself a reason to be in
favor to your request.
18:13:31 <jwb> Viking-Ice, sure. we've noted what you requested and i just
suggested how you can accomplish that. i don't think "open floor" means
"discuss things taht aren't even proposed"
18:13:52 * mmaslano needs to go home. Bye
18:14:17 * nirik has been leary of btrfs since his last dataloss incident... but that was
a year or more ago, so hopefully things are better now.
18:14:52 <nirik> ok, if nothing else, will close out in a minute...
18:15:37 <nirik> ok, thanks for coming everyone!
18:15:39 <nirik> #endmeeting