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