| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| Hi everybody; who's around? | ||
| jeremy | hi | |
| * tibbs here | ||
| caillon | ||
| * nirik is here | ||
| dwmw2 here | ||
| jwb is here | ||
| f13 | ||
| bpepple | I'm assuming spot & dgilmore won't be here, since there down south. | |
| bpepple | The only thing I had on the agenda for today, was whether we need to slip the schedule or not. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Final Release Schedule - all | ||
| f13 | well, I'm uploading PR to torrent now | |
| tibbs | How's the blocker list? | |
| f13 | and I'm not too dissapointed with the state of things | |
| jeremy | in some ways, I'm feeling better about how the release is looking... but the fact that the PR still isn't out has me feeling very wary about getting feedback and being able to act on it and meet the release date | |
| jwb | um | |
| we've never done a PR release before | ||
| so why is this all of a sudden a major concern? | ||
| jeremy | jwb: we've done 3 test releases in the past | |
| jwb | test3 wasn't scheduled so close to release though was it? | |
| jeremy | and there's nothing more demoralizing to someone who takes the time to download and test something to have them report it as soon as they can and get told "whoops, sorry. too late!" | |
| jwb: the PR wasn't scheduled as close to the release as it is right now :) | ||
| jwb | point | |
| notting | sorry i'm late | |
| bpepple | notting: np. we're just discussing whether we need to slip the release or not. | |
| * wwoods here, as requested | ||
| bpepple | wwoods: your thoughts on the state of the blocker list? | |
| wwoods | my gut feeling is that there's a lot of fiddly little problems | |
| but nothing of pants-messing magnitude | ||
| jeremy | and if we're aiming for release on the 29th, that means at the absolute latest, the tree has to be synced by a week from today. which means we really need to be done on tuesday. I just don't see it | |
| bpepple | I get an e-mail last night from one of our contributors about the state of bug #435969, and if that is a blocker for the release. | |
| buggbot | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=435969 low, low, ---, Adam Jackson, ASSIGNED , gnome (with compiz) crashes on Alt-Tab | |
| wwoods | at least, nothing I'm aware of. it's possible that I'm just blissfully unaware. | |
| blockers are determined by the ReleaseCritera page | ||
| jeremy | bpepple: it's on the blocker list | |
| wwoods | the one-sentence summary is: anything that breaks installs, yum, or new features *may* be a blocker | |
| bpepple | jeremy: ok, I wasn't sure whether it was or not. thanks. | |
| wwoods | compiz, generally, is not | |
| jeremy | wwoods: the one thing that the ReleaseCriteria page doesn't really cover, though, is "makes Fedora look bad". because that's a subjective thing | |
| wwoods | jeremy: right | |
| notting | wwoods: what happened to 'services start cleanly', etc? | |
| wwoods | we should probably put something on the ReleaseCriteria page mentioning that | |
| notting: that's on the page | ||
| sadly it gets left out of the one-sentence summary | ||
| heh | ||
| wwoods | the Release Criteria are *sufficient* conditions for blockers, but not *necessary* | |
| we can opt to block the release for things that are outside of that | ||
| jeremy | wwoods: *nod* | |
| wwoods | like with that compiz bug. | |
| but accepting one compiz bug doesn't mean we'll block the release for everything and anything compiz-related | ||
| that way lies madness, hysteria, dogs & cats living together, etc. | ||
| bpepple | wwoods: agreed. | |
| tibbs | jeremy: So you think we should slip? | |
| jeremy | things are definitely headed in the right direction, but Gut Feeling (tm) tells me that we're somewhere between one and two weeks off | |
| tibbs: yes | ||
| wwoods | fwiw alt-tab doesn't crash my intel-based compiz-running machine | |
| tibbs | I was going to ask "for how long", but you preempted me. | |
| jeremy | wwoods: it's not every time. airlied was working on it and apparently had a lead on a fix according to the last I heard (a day or so ago) | |
| wwoods | cool. | |
| tibbs | I heard that he had fixed it for 945 and was working on 965. | |
| stickster | tibbs: We really need to stick with a week as a unit of time for any possible slip. | |
| wwoods | and I'm happy to note that the longstanding ata_piix thing that we could never reproduced has been reproduced by alan and friends, so yay | |
| tibbs | stickster: Yes, I understand. | |
| wwoods | (that's bug 436099) | |
| buggbot | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=436099 high, low, ---, Alan Cox, NEW , [ata_piix] booting has failed | |
| wwoods | I really haven't gotten to look at F9Target very closely though | |
| tibbs | BTW are we trying to have the 2.6.25 release kernel in for release? | |
| jeremy | wwoods: I started to last night but then I saw the time | |
| wwoods | I'm with jeremy - It'd be possible to do the 29th if we were forced, but it would make everyone involved nervous and unhappy | |
| jeremy | tibbs: I think it got built last night | |
| tibbs | Built, yes, but tagged for the release or as an update? | |
| jeremy | tibbs: kylem and cebbert at least were talking about. the amount of change from what we have right now is tiny and it's a "prettier" number :) | |
| wwoods | which always, ALWAYS leads to rushed fixes, which introduce nasty last-minute regressions, which makes everything spiral out of control | |
| dwmw2 | and we get a lot of flak when we ship non-released software :) | |
| tibbs | wwoods: The way to avoid that is to have defined criteria for what we're trying to accomplish during the slip. | |
| nirik | dwmw2: non released? 2.6.25 is out... | |
| bpepple | f13, notting: what are your thoughts on slipping a week? | |
| * jeremy would rather take the two weeks to make sure the release is polished and solid (which yes, means that we as a project and rel-eng especially, need to be more picky about what we pull in during the time period) than force for the 29th | ||
| dwmw2 | makes sense | |
| tibbs | I can't argue with that. | |
| * bpepple is inclined to agree w/ jeremy on the slip. | ||
| tibbs | What's the possible fallout of a two week slip? | |
| tibbs | I don't recall any hard deadlines that we're trying to meet, like a specific conference. | |
| bpepple | tibbs: It might bump some of our marketing people's plans. | |
| jeremy | we're at 6 months + 5 days for the release instead of 6 months - 9 ? :) | |
| dwmw2 | the kernel nutters start sending all their patches, and we accidentally ship 2.6.26-rc1? | |
| notting | bpepple: i'm in favor of at least a week slip, if not | |
| bpepple: i'm in favor of at least a week slip, if not 2 | ||
| jwb | f13 has repeatedly said he doesn't want to slip for selfish reasons. i wonder what those reasons are | |
| * nirik thinks one week might be good... but that should very much not be a "ok, slipped a week, can you throw in all my updates now?" for maintainers. | ||
| notting | jwb: to be able to hand it out at a specific show, iirc | |
| bpepple | ok, it sounds like most of fesco is in favor of slipping, but we should probably get a show of hands. | |
| f13 | jwb: I'm going to be out of the state starting next thursday for a week | |
| wwoods | is one week sufficient? | |
| f13 | jwb: in Seattle area, doing a Linux show (Linux Fest Northwest) | |
| I have 50 USB keys to hand out, I really wanted to hand out Fedora 9 preloaded on them. | ||
| jeremy | wwoods: one week is probably on the border of enough, I'd feel far more comfortable with 2 | |
| f13 | If we're going to slip, I'd rather slip 2 so that I don't have to beat my brains out doing composes while in Seattle | |
| tibbs | f13: Do you think a slip is necessary? | |
| stickster | There's another problem *possibly* cropping up, viz. artwork for the printed discs | |
| We may be able to resolve it shortly -- but it's questionable _right_now_ | ||
| f13 | tibbs: I think slipping will get us a better release. I think that's almost always the case though. | |
| jeremy | we've got too much good going on with Fedora 9 -- let's get it right and not cut corners | |
| stickster | jeremy++, f13++ | |
| tibbs | Well, if we have too much good, we should obviously try for less good. | |
| bpepple | Proposal: Slip the release 2 weeks. | |
| +1 | ||
| f13 | I'm just not sure if slipping will fix /enough/ to make it worth the slip | |
| -1 | ||
| jwb | 0 | |
| wwoods | It's *always* true that more time -> more bugs fixed. | |
| jwb | wwoods, and more found | |
| notting | stickster: elaborate? | |
| f13 | wwoods: also, this would be more frozen time, which just adds to either the churn or more saying "no, you can't update that" | |
| wwoods | I might need to more closely examine what actually needs fixing before making a decision here. | |
| tibbs | f13: And more zero day updates. | |
| jeremy | bpepple: +1 | |
| wwoods | right. devs hate freeze time, and I don't blame them | |
| * nirik wonders if a special session later to decide might be in order? | ||
| wwoods | and users hate delays | |
| and I like making things more stable but I hate prolonging the end-of-release insanity | ||
| f13 | and releng hates slips (: | |
| tibbs | I think we pretty much need to decide now. | |
| stickster | notting: Mainly to do with our tools for art and how they translate to the CD printer's preferred input formats (in this case, PDF) | |
| nirik | fair enough. | |
| * nirik goes to look at blocker list. | ||
| stickster | notting: There's also color matching involved, although we *may* have solved that last release. | |
| * stickster still waiting for some other answers. | ||
| tibbs | stickster: Do we need to tie artwork and printing to our actual release date? | |
| notting | stickster: i mean, do you need to slip? | |
| f13 | note, the last round of printed media came pretty well after the release | |
| stickster | No, I'm not suggesting that's a reason to slip. But if there are other reasons that might be compelling, it should be considered on balance with them. | |
| tibbs | It's theoretically possible for the printed releases to be available later than the torrents. | |
| stickster | f13: True, I mentioned that as well to the artwork folks. | |
| f13: I don't fully understand what the problem was originally, but like I said, it *may* have been a pipeline issue solved last release. | ||
| f13 | I'm just not in favor of slipping for the fear of getting stuff done, without specifics of /what/ we are slipping for | |
| stickster | agreed | |
| f13 | other than just "more time for bugs" | |
| wwoods | I agree with f13 here | |
| there's always "more time for bugs" | ||
| I want to be able to give specific reasons before I ask for a release slip | ||
| I have a feeling we'll be able to come up with some | ||
| notting | the x blocker/target list worries me | |
| wwoods | but it's kind of shady to go on gut feelings alone | |
| tibbs | The x blocker list has one open bug on it. | |
| stickster | wwoods++ | |
| wwoods | I wanna back up my gut with some bug IDs. | |
| jeremy | wwoods: I want to bloody give the PR time to actually be OUT THERE | |
| otherwise, it's a waste of everyone's time | ||
| wwoods | jeremy: as do I | |
| notting | tibbs: f9-x-target | |
| f13 | jeremy: are you just hoping for more PR users than our typical rawhide users? | |
| or wanting more (split)media testing? | ||
| or both? | ||
| jeremy | wwoods: how the hell do we do that and release in less than two weeks? | |
| wwoods | but I want some more concrete reasons for slipping | |
| tibbs | That's different from f9-x-blocker, though. | |
| jeremy | f13: both. and live testing. | |
| wwoods | no, I'm not suggesting that we don't need to slip | |
| I think we do | ||
| jeremy | wwoods: the concrete reasons for slipping is that we've slipped *every* *single* *milestone* except for the final | |
| poelcat | how can we determine the quality of the blocker list if PR isn't released? | |
| notting | tibbs: hence blocker/target :) | |
| wwoods | poelcat: plenty of rawhide / internal testing happens | |
| people test more than just the releases. | ||
| bpepple | jeremy: +1 | |
| jeremy | wwoods: on very limited sets of hardware | |
| poelcat | wwoods: we have a historical disagreement there :) | |
| wwoods | dude, I am not arguing against the slip. I am arguing for having some time to flesh out the *reasoning* for the slip | |
| jeremy | wwoods: why? so that it can be even more of a fire drill? | |
| "yes, we all think we're going to need to slip but let's wait a week to decide it so that we can pat ourselves on teh back for longer" | ||
| f13 | poelcat: PR is absolutely not necessary to validate fixed bugs on the blocker list. | |
| wwoods | a week? no, I mean, like, an hour | |
| nirik | is ajax going to be available the next few weeks? I seem to remember he was off traveling? | |
| * stickster suggests a supplemental (let's not say "emergency") FESCo meeting ;-) | ||
| jeremy | nirik: he's back next week iirc. just XDC this week | |
| poelcat | f13: but i think it is necessary to generate a better final blocker list | |
| jeremy | wwoods: it's not like the meeting with the discussion of the slip wasn't announced. and it's not like talking about this hasn't been on the fesco schedule every week for the past 3 or 4 | |
| nirik | jeremy: ok, so limited X fixes this week? | |
| wwoods | okay, so we're missing ajax *and* f13 for part of the next two weeks? | |
| jeremy | and we keep putting it off | |
| f13 | poelcat: I'm not so sure about that if we actually use the real definition of release blocker critera. | |
| jeremy | wwoods: we've been missing ajax most of this week | |
| notting | tibbs: to be specific - 239125 (which involves 429183), 435969, 441373, | |
| wwoods | the only question in my mind is: one week slip, or two? and I'm not personally comfortable voting on that yet. | |
| I'll defer to the judgement of others here | ||
| * wwoods handling SIGWIFE | ||
| nirik sees a pile of bugs, but doesn't have a feel for if any of them are big enough of a deal to slip. | ||
| f13 | and seriously, how many bugs on our "blocker" list are actually Release Blockers by our definition? | |
| tibbs | The one open X blocker doesn't seem to be. | |
| notting | f13: installs and then three-clicks-to-a-system-crash technically 'passes' the release criteria | |
| doesn't mean we should ship that way | ||
| bpepple | ok, I don't see us making much headway here. Do we need to review the blocker list, and call a special meeting to resolve this? | |
| poelcat | bpepple: and decide whether or not PR is a gating factor? | |
| f13 | how about this. | |
| We just suck it up, slip 2 weeks, and figure out how to message that and what we're slipping for in the next few hours. | ||
| (and I'll just be really cranky for those 2 weeks) | ||
| * jeremy doesn't see how "so that the PR isn't a waste of time" _isn't_ the message | ||
| bpepple | f13: I'm fine with that. | |
| * bpepple agrees with jeremy that that can be one of the reasons. | ||
| f13 | jeremy: if that's the case, do you want to delay PR for another 3 days so that we can mirror it and jigdo it? | |
| * notting is +1 for a slip of a week or so, so if 2 weeks is logistically more sane, +1 to that | ||
| jeremy | f13: let's mirror it but just have it available on torrent first. yeah, the mirrors get less happy with it, but sometimes you've got to do what you've got to do | |
| wwoods | It'd be nice if it wasn't the *entire* message. There's other stuff too. | |
| but collecting that list of reasons isn't hard, and giving PR some time is sufficient reasoning to slip | ||
| * nirik agrees with notting. | ||
| bpepple | tibbs, jwb, caillon, dwmw2: ? | |
| dwmw2 | if pushed to opine I'd probably go for the slip | |
| jwb | 0 | |
| dwmw2 | 1 week or maybe 2 if that makes more sense | |
| tibbs | It seems like most of the people who are working in this stuff agree that we need to slip. | |
| dwmw2 | but I think I'm closer to a 0 too | |
| f13 | it's going to have to be 2 unless we want somebody else to do the release. | |
| wwoods | 2 weeks, then. How many weeks did we slip the Alpha and Beta by? | |
| notting | combined? | |
| bpepple | wwoods: about 2 or 3 weeks I believe. | |
| wwoods | well, individually and combined | |
| jeremy | beta was 12 days off of the original schedule | |
| wwoods | It'd be good to know, for the next time around, whether (and by how much) we should slip the final release when/if we slip Alpha/Beta | |
| jeremy | alpha was the same | |
| wwoods | so, call it two weeks each? | |
| caillon | bpepple, +1 to a 2 week slip, actually. i've heard a lot of concern from halfline and co about not being quite ready yet for shipping. | |
| wwoods | okay. I don't think I actually get a vote here, but I'd give +1 to a 2-week slip | |
| bpepple | ok, I don't hear any strong objections to a 2-week slip, so I think we've made our decision. | |
| wwoods | and I'd like to remember, in the future, that we ended up needing half of the time we lost from the Alpha/Beta schedules | |
| f13 | wwoods: as QA guy, I think you absolutely get a vote on this. | |
| bpepple | f13: agreed. | |
| f13 | wwoods: I don't know if we can count on that to happen every time | |
| wwoods | heh. well, it's a FESCo meeting, and I don't recall being a member of FESCo, but cool | |
| f13: right, but it's nice to have guidelines | ||
| bpepple | wwoods: maybe not a formal vote, but obviously your opinion is going to be taking into account since you head up the QA team. | |
| wwoods | bpepple: right on. | |
| bpepple | ok, so who gets the joy of announcing this? | |
| caillon | typically, it's rel-eng | |
| * bpepple is fine with that. ;) | ||
| caillon | i could do it though if they don't want to | |
| wwoods | heh doh. all those counter images will need resettin' too | |
| f13 | wwoods: eh, we warned 'em. | |
| wwoods | http://fedoraproject.org/static/images/counter/en/fedora9-countdown-12.en.png | |
| ha ha! now it's 26 again. | ||
| f13 | wwoods: all computer timers go backwards in time at some point | |
| wwoods | with or without the help of Doc Brown. | |
| bpepple | ok, anything else we need to discuss in regard to the release? | |
| f13 | cvs mass branching | |
| I'd like to do that tomorrow or over the weekend | ||
| wwoods | It's worth mentioning that our previous delays cut 4 weeks off the schedule, but we're still going to deliver all this fabulous new stuff only 2 weeks late | |
| f13 | (preferrably prepare tomorrow, execute over the weekend) | |
| caillon | f13, +1 to that | |
| f13 | it will involve CVS outage, for perhaps an entire day | |
| wwoods | do we have cvs usage metrics that tell us when a good time for an outage is? | |
| * wwoods just curious | ||
| caillon | wow, an entire day? | |
| * caillon didn't realize it took that long | ||
| wwoods | cvs: not known for its speed | |
| caillon | wwoods, true, but at least cvs is becoming synonymous with fedora these days. "man, i'm glad i work on $other_distro. no cvs unlike fedora" | |
| f13 | caillon: 15K packages to adjust pkgdb entries and then do cvs masturbations on | |
| caillon | fun | |
| f13 | /hate/ the cvs | |
| bpepple | f13: do those changes kick off e-mails? | |
| f13 | trying to not do that, which means an outage | |
| wwoods | it kinda seems like everyone is gradually migrating towards git | |
| f13 | (so that no untracked changes sneak through) | |
| wwoods | at least in Fedoraland | |
| caillon | f13, which is slower? pkgdb or cvs? | |
| f13 | wwoods: yeah, that's the case. | |
| * caillon hides | ||
| f13 | caillon: well, last time they were equally slow | |
| caillon: but toshio improved things a bunch in pkgdb he claims | ||
| caillon | f13, i haven't noticed it yesterday with my mass committing | |
| nirik | cvs is a lot slower than pkgdb these days | |
| dwmw2 | ok, yaboot-1.3.13-12.fc9 seems to work, and is actually built from source. f13, please can we tag for f9? | |
| nirik | caillon: what did your mass committing hit pkgdb for? | |
| caillon | nirik, cvshook hits it | |
| to email peeps | ||
| f13 | yeah | |
| caillon: I'm going to hopefully disable the cvshooks | ||
| dwmw2 | hm, btw can I stop being mailed about anything involving xulrunner just because I once committed a patch? :) | |
| f13 | skip acl lookup (I have acls to everything), skip notify lookup (don't care) | |
| nirik | sure, but I think it's cvs and/or sending the email thats slow... pkgdb answers pretty quickly I think | |
| f13 | nirik: building up and tearing down the lookups take time | |
| caillon | nirik, it's something like O(n^2) where n is number of people approved | |
| nirik | dwmw2: yes, just go to the page and drop watchcommits | |
| dwmw2: https://admin.fedoraproject.org/pkgdb/packages/name/xulrunner | ||
| caillon | nirik, you might just be hitting pkgdb entries with few people on it | |
| dwmw2 | doh. ta. | |
| nirik | could be. | |
| caillon | nirik, the firefox pkgdb page takes something like 40s to load, while others with fewer people explicitly listed take ~1-2s to load | |
| f13 | that's all I've got | |
| bpepple | ok, we're to the hour point. Is there anything else that needs to be discussed, or should we wrap up? | |
| * jeremy has to run | ||
| caillon | nirik, i've been talking to toshio about it | |
| nirik | caillon: ok. | |
| caillon | f13, are you going to send the slip notice? | |
| notting | bpepple: yay feature complete! | |
| f13 | caillon: I will. | |
| caillon | f13, hot | |
| bpepple | notting: ;) | |
| f13 | I have to say, a whole lot more people have been interested and involved in the distro production cycle this time around | |
| and I think it really shows in the quality and polish we're seeing, as well as the decision making | ||
| bpepple | f13: that's a good thing. | |
| f13 | it's a really really good thing | |
| bpepple | ok, if there's nothing else..... | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
| Thanks, everyone! | ||
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
