=================================== #fedora-meeting: FESCO (2010-09-14) =================================== Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-09-14/fesco.2010-09-14-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:01) * pjones and ajax are traveling today, will not be able to attend. (nirik, 19:30:30) * Updates policy status (nirik, 19:33:02) * LINK: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft (nirik, 19:34:12) * ACTION: nirik (and anyone else who wishes) to work on the updates policy wiki page for next week. (nirik, 20:02:44) * ACTION: SMParrish to work on metrics (nirik, 20:02:53) * ACTION: SMParrish and mjg59 to work on ideas for kde updates in stable releases. (nirik, 20:04:09) * http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:05:55) * http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik, 20:10:07) * #461 F14 blessing for systemd (nirik, 20:12:29) * LINK: http://fedoraproject.org/wiki/QA:Testcase_initialization_basic and http://fedoraproject.org/wiki/QA:Testcase_initialization_tools (nirik, 20:38:06) * ACTION: : will defer systemd to f15 release to give more time to fix small issues and docs and general polish. (nirik, 21:12:43) * ACTION: notting will look at what's required to flip the default in f14 (notting, 21:13:44) * #464 - Fix nss update issues (nirik, 21:15:31) * Open Floor (nirik, 21:32:28) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=488968 (nirik, 21:33:57) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2387 (nirik, 21:34:06) Meeting ended at 21:38:58 UTC. Action Items ------------ * nirik (and anyone else who wishes) to work on the updates policy wiki page for next week. * SMParrish to work on metrics * SMParrish and mjg59 to work on ideas for kde updates in stable releases. * : will defer systemd to f15 release to give more time to fix small issues and docs and general polish. * notting will look at what's required to flip the default in f14 Action Items, by person ----------------------- * mjg59 * SMParrish and mjg59 to work on ideas for kde updates in stable releases. * nirik * nirik (and anyone else who wishes) to work on the updates policy wiki page for next week. * notting * notting will look at what's required to flip the default in f14 * SMParrish * SMParrish to work on metrics * SMParrish and mjg59 to work on ideas for kde updates in stable releases. * **UNASSIGNED** * : will defer systemd to f15 release to give more time to fix small issues and docs and general polish. People Present (lines said) --------------------------- * nirik (177) * notting (61) * mjg59 (61) * mclasen (46) * SMParrish (17) * emaldona_mtv (15) * jsmith (14) * drago01 (13) * gholms (12) * zodbot (11) * fenris02 (7) * poelcat (5) * lmacken (4) * adamw (2) * jankratochvil (2) * mclasen_afk (1) * pjones (0) * ajax (0) * kylem (0) * cwickert (0) -- 19:30:01 <nirik> #startmeeting FESCO (2010-09-14) 19:30:01 <zodbot> Meeting started Tue Sep 14 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 <nirik> #meetingname fesco 19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 <nirik> #topic init process 19:30:01 <zodbot> The meeting name has been set to 'fesco' 19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:30 <nirik> #info pjones and ajax are traveling today, will not be able to attend. 19:30:55 * mclasen present 19:31:02 <notting> pjones also said he'd be out next week too 19:31:04 * notting is here 19:31:05 * SMParrish here 19:31:08 * nirik nods. yep. 19:31:36 <mjg59> Here 19:31:51 <nirik> cool. I think thats enough of us to get started... 19:32:18 <nirik> We have 3 updates related tickets. Should we just do them in one "Updates policy status" section? ;) 19:32:38 <mjg59> Seems reasonable 19:33:02 <nirik> #topic Updates policy status 19:33:11 <nirik> .fesco 351 19:33:12 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:33:16 <nirik> .fesco 382 19:33:17 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:33:22 <nirik> .fesco 454 19:33:23 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454 19:33:36 <nirik> so, on the first one we are just waiting for autoqa. 19:33:54 <nirik> on the second one, I whipped up a wiki page for docs the other day: 19:34:12 <nirik> https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft 19:34:37 <nirik> this is based on Ajax and notting's work for the stable updates part + rawhide and branched from the pre-release updates policy ticket. 19:35:04 <nirik> It needs more work I think... but I wanted to get it down and see if the idea seems like a good one. 19:35:16 <nirik> ie, a single page that lists the updates policy for each of the various branches we have. 19:35:33 <nirik> thoughts? 19:35:38 <notting> shiny. (also, tl;dr yet) 19:35:50 <mclasen> nirik: nice start 19:36:15 <nirik> yeah, length could be a issue... unless we index it well perhaps. 19:36:21 <mclasen> nirik: maybe it should be 'Beta to Pre-release 19:36:31 <mclasen> otherwise the two sections appear to overlap 19:36:44 <mclasen> or is that intended ? 19:36:51 <nirik> mclasen: good point. No, that seems a mistake 19:37:15 <nirik> perhaps we could link to the schedule where needed. 19:37:20 <notting> nirik: also, non-critical path updates only have a defined time requirement IFF they don't get the proper amount of karma 19:37:25 <notting> they can go out sooner w/testing 19:37:29 <nirik> true. 19:37:46 * nirik may have munged things when squashing them all together on the page. 19:38:19 <nirik> I wanted also to have a sense of: 19:38:35 <nirik> rawhide: try not to break things, but major updates are fine, and updates often are just fine too. 19:38:52 <nirik> branched: trying to make a release here, please try and slow down, avoid major release, etc. 19:39:05 <nirik> stable: try and stay stable, no api/abi, major ui changes, etc. 19:40:43 <mclasen> nirik: for the rawhide section, 'feel free to push the latest release' should perhaps be relativized to say 'as long as you are confident that it will go stable in time for the next fedora release' ? 19:40:45 <nirik> I'd really like to finish something this term if we can. ;) Even if we have to do a special working session to get things polished. 19:40:52 * mclasen had that issue with gnome3 this cycle... 19:40:57 <nirik> mclasen: yeah, good one. yep. 19:41:14 <nirik> of course you can't always know. 19:41:43 <mclasen> no, best guess... 19:42:13 <nirik> There is always Epoch if needed. 19:43:53 <nirik> In other news I added some more things to https://fedoraproject.org/wiki/Updates_Lessons 19:44:14 <nirik> SMParrish: any news on metrics and/or kde sig kde update plan? 19:44:59 <mjg59> I didn't get to work on that this week 19:45:06 <mjg59> My fault 19:45:06 <nirik> ok 19:45:17 <SMParrish> nirik: Nothing yet. should get it together by next week 19:45:40 <nirik> ok. 19:46:02 <nirik> I can fold in comments from above to the doc (or you guys can). Work on it over the next week and if it looks good, vote on it? 19:46:12 <mclasen> sounds good 19:46:47 <nirik> should we put this in force if we don't have the rest of the vision addressed yet? 19:46:51 <nirik> or should it be all at once? 19:47:29 <notting> nirik: works for me 19:47:46 <SMParrish> seems like we have already been implementing bits as they are ready 19:47:56 <mclasen> nirik: I haven't talked to lmacken yet about getting different policys implemented in bodhi 19:48:13 <mclasen> I'll check with him sometime this week 19:48:16 <nirik> mclasen: yeah, the prerelease thing should not need to be done until next cycle, so that should be ok. 19:49:31 <nirik> do we want to talk about some of the other sections? Perhaps metrics? How and what metrics should we gather? 19:49:51 * nirik notes we are over 15min... didn't see my alarm. Do folks want to continue on this? or move on for now? 19:51:25 * nirik wonders if anyone is paying attention. 19:51:46 <mjg59> We should probably think about metrics 19:51:54 <mjg59> By "think" I mean "talk" 19:52:16 <nirik> Thats fine with me if we would like to spend a few minutes on that... 19:52:35 <mjg59> So, the first thing we probably need to count is the numer of updates we get per release 19:52:39 <nirik> the board vision has: "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements" 19:53:21 <mjg59> Measuring the quality is somewhat harder 19:53:49 <mjg59> The total amount of negative karma that hit packages that went to stable? 19:54:01 <mjg59> Can we still generate that for previous releases? 19:54:04 <nirik> we do have https://admin.fedoraproject.org/updates/metrics/?release=F14 19:54:45 <mclasen> bodhi does keep the number of updates already, no ? 19:54:49 <mclasen> a right 19:54:50 <nirik> we could probibly get lmacken to do some. I'd like to note tho that we should have regular reports or some way to get stats we want without having to ask for them... 19:54:50 <SMParrish> I guess quality could be measured somewhat by bugs filed 19:55:00 <mjg59> Yeah, these seem like the right figures 19:55:17 <drago01> SMParrish: not really 19:55:41 <mjg59> SMParrish: We'd need to identify whether the bug was filed against stable or updates-testing 19:56:59 <mclasen> we probably also want to keep a list of 'problematic' updates (like the stuff thats on the wiki page) 19:57:17 <nirik> so # of updates would be usefull (but we might already have that). Total amount of karma perhaps? (to see if more testing is happening) 19:57:25 <mjg59> Does abrt identify the source of a package? 19:57:34 <mjg59> ie, whether it was pulled from stable or updates-testing? 19:57:53 <nirik> SMParrish: you still willing to work on this? might be worth talking with lmacken about what stats we _could_ get from bodhi 19:57:57 <mjg59> It's not perfect, but it ought to be reasonably fair 19:58:22 * lmacken answered mjg59's question during last weeks meeting (total # of stable updates w/ negative karma) 19:58:59 <nirik> lmacken: sure, we just may want to have some way to see that on the fly or in a regular report... 19:59:02 <SMParrish> nirik: Yes I'll keep on it 19:59:16 <nirik> mjg59: I don't think abrt mentions repo... just package version. 19:59:47 <nirik> lmacken: you have posted some reports in the past to the list I seem to recall. Do you remember what all was in those? 20:00:05 <lmacken> nirik: yep, I added it to bodhi's metrics generator, and it will be exposed in the web interface at some point soon 20:01:07 <lmacken> nirik: yeah, http://lewk.org/blog/bodhi-stats-20100608 I've added a bunch more metrics to that since then. I'll be generating a new report with the new bodhi release that I'm trying to get out the door now 20:01:37 <nirik> lmacken: cool. 20:01:52 <nirik> would it be possible to list even older releases too? or those are no longer in the db? 20:01:53 <mjg59> nirik: Well, we could certainly cross-reference that to see how many bugs are filed on packages that never get into stable against ones that do 20:02:09 <lmacken> nirik: yeah, I have db snapshots of previous releases. 20:02:24 <nirik> mjg59: true. 20:02:44 <nirik> #action nirik (and anyone else who wishes) to work on the updates policy wiki page for next week. 20:02:53 <nirik> #action SMParrish to work on metrics 20:03:22 <nirik> mjg59 / SMParrish: you guys still ok to try and work on some plan for kde? 20:03:33 <mjg59> nirik: Well, to write up pros and cons, yeah 20:03:49 <nirik> ok. 20:03:54 <SMParrish> nirik: yes 20:04:09 <nirik> #action SMParrish and mjg59 to work on ideas for kde updates in stable releases. 20:04:18 <nirik> ok, anything else here? or shall we move on for now? 20:05:32 <mjg59> Nothing from me 20:05:48 <mclasen> move on 20:05:52 <nirik> ok, moving along then... 20:05:55 <nirik> #topic http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations 20:05:56 <nirik> .fesco 434 20:05:57 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434 20:05:58 <nirik> any news here? 20:06:28 <nirik> don't see any answers on the talk page. 20:06:36 <nirik> any feature owners for it present? 20:07:04 * nirik doesn't see any. 20:07:10 * mclasen had some discussion with dcbw about that feature 20:07:41 <mclasen> and he was planning to use dnsmasq, so there may be some need to synchronize between the feature owners and dcbw 20:07:57 <nirik> ok. So, ping again, defer to next week? 20:08:26 * mclasen opts for deferring 20:08:36 <mclasen> I may try to find the feature owners during the week 20:09:02 * nirik is fine with that. 20:09:43 <nirik> any objections? will move on if not. 20:10:07 <nirik> #topic http://fedoraproject.org/wiki/Features/GoldLinkerDefault 20:10:07 <nirik> .fesco 423 20:10:08 <zodbot> nirik: #423 (F15Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423 20:10:11 <nirik> any news on this one? 20:10:50 * mclasen hasn't heard anything 20:11:02 <nirik> yeah, so ping again I think and try again next week also. 20:11:03 <notting> nor have i 20:11:51 <nirik> ok, will move on if no objections... 20:12:29 <nirik> #topic #461 F14 blessing for systemd 20:12:34 <nirik> .fesco 461 20:12:35 <zodbot> nirik: #461 (F14 blessing for systemd) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/461 20:12:49 <nirik> This is kinda moot now I think, but I wanted to bring it up here for two things: 20:12:59 <nirik> a) any more feedback on this from fesco folks 20:13:22 <mclasen> we have had two or three systemd & initscripts updates in the meantime 20:13:25 <nirik> b) is there any way we could mark or otherwise setup things so trac tickets that need attention between meetings could be seen and acted on by fesco members? 20:13:34 <notting> well, i would like *actual* decisions, not just tacit lack of response 20:14:00 <mjg59> tbh, by the time I had a chance to look at it it seemed pretty clear which direction the discussion was going in 20:14:16 <mjg59> But I sould probably have explicitly indicated my support for that, so sorry about that 20:14:27 <nirik> I'm a bit worried about systemd, since it's such a big change to a core system, but I gave a +1 anyhow. I think the pros outweigh the cons, IMHO. 20:15:10 * notting is still pretty nervous about it. for example, that request to review the chapter? there's very little you can add there except 'it's all screwed up' no. 20:15:11 <nirik> so would any other fesco folks care to vote? 20:15:12 <notting> now. 20:15:34 <nirik> yeah. ;( 20:15:46 * mclasen hasn't kept up with the schedule too closely, how long do we have till beta closes for good ? 20:16:00 <notting> tomorrow 20:16:17 <mjg59> +1 20:16:19 <nirik> and the test composes have all been using systemd of course. 20:16:22 <notting> actually, that says 'today' 20:16:58 <notting> and there are still some pretty gaping holes in the plan 20:17:17 <mclasen> notting: I don't know that that chapter is in much worse shape that e.g. the networking section is wrt to network manager 20:17:29 <nirik> notting: are you advocating punting? or just expressing concerns? 20:18:39 <notting> mclasen: that chapter at least describes NM, albeit incompletely 20:19:45 <notting> nirik: i would feel more comfortable having more time to fix the stuff i know about 20:20:11 <mclasen> nottin: oh, you are right, there is more than I had seen 20:21:17 <nirik> is there anything more we could do to try and make it work out better for f14? 20:21:28 <nirik> I was thinking another test day after beta might be good. 20:22:03 <nirik> we could try and get someone to help re-do that chapter. 20:22:13 <notting> but there are many ways that it could be redone 20:22:15 <mclasen> nirik: that is a good idea (test day repeat) 20:22:28 <notting> we could point it at systemadm, which is an entirely different tool with a different usage set 20:22:29 * mclasen is writing down notes for the chapter currently 20:22:36 <notting> we could try and port some of the underlying s-c-services code to systemd 20:22:49 <notting> we could say 'well, you need to also look for these systemd services and do this other thing' 20:23:43 <nirik> I'll note that it doesn't currently have anything about upstart (/etc/init/ /etc/event.d/) in there. 20:23:52 * mclasen thinks that for f14, it will be enough to point out the things that don't work as they used to 20:24:04 <notting> nirik: there aren't system services in upstart. there are in systemd 20:24:16 <nirik> yeah... true. 20:24:28 <mclasen> e.g. s-c-services still works, doesn't it 20:24:30 <mclasen> ? 20:24:42 <notting> mclasen: not if you attempt to disable, say, NM or avahi 20:24:53 <mclasen> oh, hmm 20:25:10 <nirik> right... the 'special case' ones that have a unit file. 20:25:53 <notting> but, then again, s-c-services apparently complies regexes that it uses to parse chkconfig output 20:26:11 <mclasen> ugh 20:26:13 <nirik> I guess I would lean toward: all this stuff is the same, except these: where you will need systemadm 20:26:35 <notting> nirik: systemadm doesn't enable/disable services, though 20:27:06 <mclasen> does chkconfig not work for NM or avahi, either ? 20:27:50 <notting> mclasen: it will happily run and correctly enable/disable/etc the sysv service... which doesn't have any effect. 20:28:08 * gholms rings the 15 minute bell 20:28:23 * mclasen thought there was some plan to make chkconfig fall back to systemctl ? 20:28:35 <nirik> sorry, I mean systemctl I guess. 20:28:42 <nirik> +1 to continue for a few minutes... 20:28:55 <notting> mclasen: there is. but i haven't finished that yet. 20:29:22 <mclasen> would finishing that make s-c-services work again ? (considering the regexes...) 20:29:29 <notting> yes 20:30:23 <notting> (assuming it's feasible) 20:30:41 <nirik> so, votes to continue? 20:31:00 <mclasen> +1 20:32:13 <nirik> hopefully if chkconfig/s-c-services could be made to use systemctl we could leave that chapter mostly alone? 20:32:13 <SMParrish> +1 20:32:29 <mjg59> +1 20:32:53 <mclasen> if we don't get that, then we'll have to assemble a list of 'native systemd' services and explain how to use systemctl for them 20:32:59 <nirik> is there any plan for systemadm to handle enable/disable? 20:33:22 <notting> dunno. imo, systemadm needs some quality time with mizmo/mccann 20:33:39 <nirik> yeah. 20:33:45 <notting> but that's probably neither here nor there 20:33:47 <mclasen> not that it is any worse than s-c-services... 20:34:31 * notting disagrees, but that's OT 20:34:53 <notting> probably shouldn't have brought it up 20:35:07 <nirik> so, any other votes or opinions? anyone advocate we punt to f15 strongly? 20:36:12 <poelcat> what is the downside of waiting for Fedora 15 when this feature can be fully ready? 20:36:22 <mclasen> notting: actually, you are right about s-c-services 20:36:27 * nirik thought this would be a hot issue, but it's seeming to be full of apathy. 20:36:35 <mclasen> we don't have a clear definition of 'fully ready' 20:37:02 <poelcat> wouldn't that be a good place to start? :) 20:37:25 <nirik> poelcat: we would need to revert changes made for it. We would lose press and 'buzz' about it. It's unclear how much testing it would get in rawhide (or what kind). 20:37:58 <gholms> It would still get testing for the entirety of another release branching. 20:38:06 <nirik> http://fedoraproject.org/wiki/QA:Testcase_initialization_basic and http://fedoraproject.org/wiki/QA:Testcase_initialization_tools 20:38:28 <mjg59> poelcat: Because, realistically, the time for a go/no-go decision is not now 20:38:29 <SMParrish> nirik: but what about the bad press if it bombs at release 20:38:29 * mclasen predicts that the things that make us nervous now would still make us nervous, come f15 branching time 20:38:30 <jsmith> nirik: You'd know better than I would, but I'm not sure reverting those changes is a big deal. 20:38:38 <jsmith> mjg59: If not now, when? 20:38:50 <mjg59> Before we started composing test releases for the beta at the very latest 20:38:56 * jsmith isn't taking sides one way or the other -- he just wants a *strong* decision in one direction 20:38:56 <nirik> SMParrish: sure, thats something to avoid... 20:39:13 <jsmith> mjg59: We start on TCs on Thursday, if I remember the schedule correctly 20:39:29 <notting> mjg59: sure. that's why the ticket was filed 6 days ago 20:39:32 <nirik> jsmith: well, I know we made changes in livecd-tools, and there's possibly anaconda and docs changes, features/marketing/press changes. 20:39:41 <poelcat> mjg59: the test day was held before the TC so a decision could be made 20:39:52 * nirik would like to appologize for not having this at the last fesco meeting. 20:40:29 <notting> nirik: what changed in livecd-tools relative to this? 20:40:47 <nirik> I thought we made some change, but I could be mistaken. 20:40:48 * nirik looks. 20:41:08 <jsmith> mjg59: I think this is too important to just leave up to "decision by default" 20:41:23 <mjg59> I'm sorry, the ticket indicated that the test composes started on the 9th 20:41:25 <jsmith> mjg59: We either need to be confident that it's ready, or be willing to say "no" 20:42:08 <notting> mjg59: yeah, it was tight, but the idea was 'have test day', 'decide after getting test day results' 20:42:09 <nirik> notting: oh, my mistake, that was some changes in ks files. 20:42:12 <mjg59> Ok. We could certainly drop it now, at the risk of finding that something unexpected has started depending on its semantics. 20:42:25 <mjg59> And by "drop" I mean "push out" 20:42:28 <nirik> for firstboot I think. 20:42:30 <jsmith> Right... 20:42:41 <jsmith> So what's the bigger risk? 20:43:05 <drago01> try it out ... go back with a timemachine and tell us ;) 20:43:08 <mjg59> Well, the bigger risk is presumably keeping it, but that's true of every package update since we branched F14 20:43:29 <gholms> What's the point of a fallback if people are loathe to use it? 20:43:34 * nirik is still a weak +1. I am nervous about it, but I think it can be ready. I would definitely like to have lots of attention on it and try and get it as polished as possible... 20:43:35 <SMParrish> If on release day we cannot guarantee that F14 works out the box, then we need to push it to F15 20:43:48 <mjg59> gholms: Because it's not absolutely clear that the fallback is preferable 20:44:05 <gholms> s/loathe/loath/ 20:44:20 <mjg59> If it were obvious that systemd was causing signfiicant problems then I'd have no qualms about saying that we push it for F15 20:44:21 <SMParrish> I want it in F14 but not at the expense of 1000s of users without bootable and stable systems 20:44:21 <jsmith> SMParrish: We can't wait 'til release day to make that decision. The beta change freeze is *today* 20:44:54 <nirik> mjg59: me too. 20:45:13 <mjg59> SMParrish: Do we have any reason to believe that it's more likely to leave systems unbootable now than in 6 months? 20:45:25 <SMParrish> jsmith: right what I meant was if we cannot gurantee that based on the systemd of today we need to push it 20:45:27 <mjg59> SMParrish: If we're concerned about upgrades then pushing it out a release doesn't help much 20:45:47 <mjg59> SMParrish: We're not going to get a significantly increased quantity of testing on that basis 20:46:02 <notting> adamw: where did you post that big systemd checklist i had? (if anywhere) 20:46:20 <gholms> mjg59: The entirety of the F15 branching won't help flush out more bugs at all? 20:46:32 <nirik> notting: the second of these: http://fedoraproject.org/wiki/QA:Testcase_initialization_basic and http://fedoraproject.org/wiki/QA:Testcase_initialization_tools 20:46:47 <SMParrish> mjg59: but 6 more months of development and testing is a plus. Its nice to be first but no at the expense of our user base 20:46:54 <nirik> gholms: it may... although there will not be any new install testing. 20:47:02 <mjg59> SMParrish: Yes, but testing under what circumstances? 20:47:19 * nirik notes we are at another 15min now. Votes to continue again? 20:47:20 * gholms rings the 35 minute gong 20:47:31 <mjg59> This conversation is pointless without determining what our criteria are 20:47:39 <mjg59> "We don't know it's ready" isn't helpful. We'll never know that. 20:47:43 <mclasen> SMParrish: has there been any indication that our userbase will suffer ? IMO, there have not been many problems of that sort with systemd 20:47:58 <jsmith> I thought notting did a pretty good job of enumerating the criteria for init tools 20:47:59 <notting> mjg59: that was the point of me trying to define such criteria (see the linked pages) 20:48:11 <mjg59> notting: I agree, but I don't think that's what we seem to be talking aout 20:48:22 <notting> alas, there's no data on that other than some handwavy 'we pointed testday people at that told them to file bugs' 20:48:22 <mclasen> we had listed a number of 'blocker' bugs in the ticket. have all of them addressed yet ? 20:49:20 <notting> mclasen: there's still one where starting the network deadlocks until systemd's timeout kicks in 20:49:33 <SMParrish> mclasen: Not saying there are any issues, just looking at the what if and the blackeye Fedora will have if it does not work as described 20:50:01 <jsmith> The whole reason we rescheduled the systemd test day was to give more input on problems people might encounter 20:50:15 <jsmith> If you have suggestions for how we can improve that, please add them to the F14 retrospective page 20:50:17 <mclasen> SMParrish: 'what if' is not really helpful...we've had a test day to identify issues... 20:50:26 <mjg59> SMParrish: The main risk that I see is in some unexpected case where upgrades break. It's not clear that delaying a release results in a significant reduction of that possibility. 20:50:33 <drago01> smooge: by that logic we can never ship anything new 20:50:35 <drago01> err 20:50:40 <drago01> SMParrish: ^^ 20:50:51 <mjg59> The test day idenitified some issues and the majority of them have been fixed 20:51:33 <mjg59> From a technical perspective I'm fairly happy that the code works pretty much as it should do and that there's a high probability that any significant issues discovered will be fixed in a sufficiently timely manner 20:51:36 <notting> mjg59: my concern is less "OMG crash and burn" and more "argh warts warts everywhere" 20:51:54 * mclasen unfortunately has to leave this discussion now 20:52:04 * mclasen left his vote on the ticket, anyway 20:52:08 <adamw> notting: sorry, bit late, but mostly i turned them into the systemd test day test cases 20:52:09 <mjg59> notting: Yeah, understandable 20:52:23 <adamw> notting: otherwise i've just been referring to your post from the ml archives, i haven't re-posted it anywhere 20:52:51 <mjg59> But I think there's a risk that we end up holding systemd to a higher standard than we have any other piece of code 20:53:07 <mjg59> Which I'm not averse to, but if we do that we should be more consistent across the rest of the distribution 20:53:17 <notting> mjg59: it's init. it *should* be held to a higher standard than other things. 20:53:28 <mjg59> notting: I agree, but upstart was hardly without warts 20:53:39 <SMParrish> mjg59: but as an integral part of the core system it should be held to a higher standard 20:54:03 <mjg59> If I felt that the rest of the distribution were entirely without warts than I'd worry about that more 20:55:00 <nirik> if there's specific items people are looking at, I'd like to hear them... as I said, I think the pros outweigh the cons currently, but perhaps I am missing some data? 20:55:39 <mjg59> And, of course, there's the argument that shipping something that's good enough means that we'll get enough testing that by F15 it'll be excellent 20:55:49 <mjg59> Which would not necessarily be the case otherwise 20:56:41 <nirik> so, where are we here? votes? further details? 20:57:18 <mjg59> I still lean towards +1 for shipping it 20:57:34 * gholms notes 45 minutes have passed 20:58:09 * nirik is still a weak +1 barring any data about blocking issues he doesn't currently have. 20:58:24 <notting> mclasen was +1 20:58:41 <notting> SMParrish: ? 20:58:43 <SMParrish> I'm still +1 as well. Just want to be prepared 20:58:56 <nirik> it's a short runway, and I think we should try and devote more resources to it until release if we can to make sure it works out well. 20:59:19 <notting> and we have four absent members 20:59:29 <jsmith> Some voted in the ticket, no? 20:59:41 <nirik> jsmith: nope. 20:59:48 <notting> none of whom commented in the ticket 21:00:21 <jsmith> :-( 21:00:26 <nirik> so where do we go from here? ;) 21:00:38 <drago01> option 3 21:00:41 <notting> was our quorum process always '5', or 'majority of present'? 21:00:41 <gholms> Anyone else here care to vote? 21:00:42 <drago01> i.e slip 21:01:17 <nirik> notting: I thought it was always 5. we did have 5 at the start of the meeting. 21:01:24 <notting> nirik: i mean for voting/approval 21:01:52 <nirik> yeah, at least 5 to approve something, by which case this isn't approved. ;) But it's deadline is already passed, so... 21:02:04 <gholms> notting: Have you voted yet? 21:02:18 <mjg59> Yeah, we're +4 and notting hasn't voted 21:02:43 <notting> gholms: that's sort of the point. i can stand up here and say '-1' and unilaterally sieze power and force it out myself. feels wrong, even if i'm not really thrilled about it 21:03:01 <mjg59> notting: If you don't feel comfortable with it, then we should push it to F15 21:03:19 <mjg59> I've voted based on my feelings, but I'm not averse to the alternative 21:04:00 <notting> mjg59: no, but i shouldn't be the sole decider on the feature just because pjones is flying to hawaii, etc. 21:04:01 * nirik values notting's opinion... especially since he's worked so closely on this 21:04:04 <notting> but bleah, democracy 21:04:38 <gholms> If you're -1 on it you should still say so. I'm sure you have reasons for your opinion either way. :-\ 21:05:02 <mjg59> Eh. Based on notting's discomfort and expertise, I'm happy to change to -1 21:05:31 <mjg59> If I'm going to argue that we need a more conservative approach to some of our updates, that should also apply to core functionality when we're this near a release 21:05:33 <notting> mjg59: i'm not a full -1. it's just that slipping gives us more time to fix the stuff i know needs to get fixed at some point (chkconfig, etc.) 21:05:59 <mjg59> Ok. So let's slip it to F15. 21:06:08 <mjg59> Lennart's sufficiently stoic to cope 21:06:32 <nirik> ok. 21:06:38 <SMParrish> notting: if thats the case then lets slip it. Would rather err on the side of caution 21:07:49 <nirik> ok, so slip to f15? final answer? ;) 21:08:04 <mjg59> +1 to slipping 21:08:21 <mjg59> But we're not going to get quorum on that either :) 21:08:24 <notting> 'defer' is probably better wording 21:08:47 <mjg59> Yeah, I agree 21:09:01 <nirik> action: will defer systemd to f15 release to give more time to fix small issues and docs and general polish. 21:09:02 <nirik> ? 21:09:17 <mjg59> Sounds good to me 21:09:21 <nirik> I guess we no longer have quorum, but if we don't approve this, doesn't it mean it's defered? 21:09:41 <notting> nirik: it's sort of the inverse of approving keeping it 21:10:19 <nirik> yeah, but that seems like a tricky thing... just propose something and don't get it passed and that means to revert it? 21:10:36 <SMParrish> with today being the cutoff we have to act either by approving it or short of that it goes to f15 by default 21:10:53 <notting> nirik: consider it a late feature exception? i duno. 21:10:54 <mjg59> I think if we don't explicitly approve it then it's reasonable to think that it's defered 21:11:16 <nirik> SMParrish: ok, as long as we decided that eariler with quorum I'd be ok with that. (which I think we did when the feature was approved?) 21:11:46 <fenris02> mjg59, wouldnt an upgrade simply retain upstart? 21:11:48 <mjg59> We approved it on the assumption that we'd think it was ready to be used by default 21:11:59 <notting> fenris02: not as the packages are currently constructed 21:12:11 <fenris02> notting, oh. euw. 21:12:24 <notting> so, does this mean i get to untangle the dependencies to enact the reversion? 21:12:25 * nirik wishes we had a clear quorum/vote on this... 21:12:35 <nirik> notting: sure! :) 21:12:43 <nirik> #action: will defer systemd to f15 release to give more time to fix small issues and docs and general polish. 21:12:55 <nirik> anything more on this? or move on now? 21:12:58 <fenris02> if an upgrade kept upstart it would be far easier to let systemd fly forward. 21:13:05 <drago01> no 21:13:06 * gholms lights the 60 minute fireworks 21:13:07 <fenris02> otherwise, it's massively problematic. 21:13:12 <drago01> that is inconsistent 21:13:24 <fenris02> drago01, sure. but systemd is not stable either. 21:13:35 <drago01> that wasn't the point 21:13:44 <notting> #action notting will look at what's required to flip the default in f14 21:13:46 <fenris02> multiple reboots == different results. that's not good. 21:13:48 <drago01> either it is good enough for *everybody* or it isn't 21:14:09 <drago01> fenris02: huh? 21:14:34 <poelcat> can we get a compose or nightly with the change made ASAP too so we can shake out any problems before the RC compose on Thursday? 21:14:42 <nirik> ok, moving along then.... 21:14:48 <fenris02> drago01, i've yet to see a properly working system on systemd. every iso has different problems. upgrades currently are disastrous if you switch to systemd forcibly 21:14:50 <nirik> poelcat: yeah, as soon as we sort the deps. 21:15:08 <nirik> fenris02 / drago01: can you guys take this discussion out of band? 21:15:08 <poelcat> cool, i'd hate for the RC to be the first shot at it 21:15:20 <drago01> nirik: was about to say that 21:15:31 <nirik> #topic #464 - Fix nss update issues 21:15:34 <notting> quick straw poll: do we want those currently on f14 branched to get 'upgraded' back to upstart, or to be left with a systemd install that we may not update with further systemd fixes? 21:15:34 <nirik> .fesco 464 21:15:35 <zodbot> nirik: #464 (Fix nss update issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/464 21:15:54 <nirik> notting: humm... back to upstart I would say. 21:16:39 <nirik> ok, so we are running low on time today... 21:16:59 <nirik> I filed this issue. Seems nss has issues more often than perhaps it should. 21:17:01 <notting> i am for this in general, but don't have time to donate to this effort 21:17:26 <nirik> I'd like to see if we can help the maintainer(s) deal with updates here better. 21:17:56 <emaldona_mtv> the maintainer welcomes any advise he can get 21:18:04 <nirik> hey, emaldona_mtv. Welcome. ;) 21:18:36 <emaldona_mtv> i have rectified some of my ways but I still need more to learn 21:18:43 <notting> emaldona_mtv: first question i have: why are nss-softokn, nss-util, and nss separate, if they're always updated as a unit? 21:18:44 <nirik> I guess I would say the first thing we could try and do is get some smart folks to look at the current packaging and make suggestions to make it less fragile. 21:19:54 <emaldona_mtv> the motivation stems from the fact that nss-softokn gets updated less frequently than the rest of nss 21:20:32 <nirik> are they seperate upstream tars? 21:20:43 <notting> that doesn't appear to be the case 21:20:56 <nirik> anyhow, perhaps we could gather a few people and get you together with them to try and make things less fragile. 21:20:57 <emaldona_mtv> Upstream there is one ane tar. Let me add some more info 21:21:38 <nirik> that would seem to me then that it should just be one nss package. 21:21:59 <emaldona_mtv> softoken is the cryptographic module of nss, it is submitted evry two years or so for FIPS 140 validation 21:22:33 <emaldona_mtv> it's an issue for RHEL not for fedora. We do want to keep the spec files as similar as possible 21:23:14 <emaldona_mtv> the previous way of doing things became a maintenance nightmare ... 21:23:32 <emaldona_mtv> new new one is better but has its drawbacks 21:23:47 <notting> emaldona_mtv: how was a single srpm a maintenance nightmare? 21:24:16 <nirik> I dislike that you need buildroot overrides... that leads to problems with dependending packages getting built against the not pushed version of nss. ;( 21:24:36 <nirik> also, it seems like nss gets updated a lot... if we could see how to make it update less often in stable releases that would be great. 21:24:57 <emaldona_mtv> there was an ugly hack done on nss.spc to keep softoken behing at the older fips version 21:25:49 <nirik> since fedora doesn't care at all about FIPS, could we simplify in fedora? 21:26:31 <emaldona_mtv> I don't know how to simplify it and welcome suggestions, .... 21:26:57 * mclasen_afk moves on to rawhide 21:27:38 <nirik> emaldona_mtv: ok, let me try and get a few sharp packaging folks to talk to you out of meeting? 21:27:56 <nirik> are you going to be available on #fedora-devel channel later? or is email better to get a hold of you? 21:29:13 <emaldona_mtv> I'm going to be online (give me an hour to grab something to eat) 21:29:20 <nirik> great. thanks. ;) 21:29:31 <nirik> emaldona_mtv: oh, what is the current status of nspr on f12/f13? 21:29:38 <nirik> ie, can the firefox update go out soon? 21:30:10 <emaldona_mtv> for f13 I have build again and as far as my testing goes there should be no breakage 21:30:54 <emaldona_mtv> making the BuildRequires different from the Requires was the cause of the breakage 21:31:18 <nirik> another idea I was thinking of is to make a doc on how to update... ie, all the exact steps, so they can be checked off... 21:31:24 <emaldona_mtv> it should not be done when the packages have devel subpackages 21:32:13 <emaldona_mtv> I was thinking writing a doc with what I have learned and have others review it 21:32:13 <nirik> anyhow, we can take it out of meeting. 21:32:20 <nirik> yes, I think that would be good. 21:32:28 <nirik> #topic Open Floor 21:32:37 <nirik> we have several more items, but are out of time. ;( 21:32:41 <nirik> anything quickly for open floor? 21:32:57 <gholms> Will everything else be pushed out to next week? 21:33:29 <nirik> I suppose so.... we seem to have a poor record working with trac tickets. ;( 21:33:35 <nirik> The other 2 items I had were: 21:33:56 <nirik> application installer issues 21:33:57 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=488968 21:34:04 <nirik> and 21:34:05 <nirik> BuildIdBuild infrastructure 21:34:06 <nirik> https://fedorahosted.org/fedora-infrastructure/ticket/2387 21:34:57 <mclasen> that needs more time, I'd say 21:35:08 <nirik> ok, will close out if no one has anything further... 21:36:13 <jankratochvil> The second one is more a question if someone can run createrepo on the Koji server and say - it takes too much time - or it eats too much memory etc. The right solution is to implement it natively into yum but maybe it would work even as-is. 21:37:26 <nirik> jankratochvil: well, the infrastructure lead and the buildsystem maintainer both say this is not practical currently, so I think another solution must be found. 21:38:05 <nirik> jankratochvil: we can discuss next week? is that ok? 21:38:27 <jankratochvil> ok, this problem lasts for years. 21:38:49 <nirik> yeah. 21:38:50 <nirik> :( 21:38:56 <nirik> ok, thanks for coming everyone! 21:38:58 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
