--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
* nirik is here
dwmw2 here
jwb is here
bpeppleI'm assuming spot & dgilmore won't be here, since there down south.
bpeppleThe 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
f13well, I'm uploading PR to torrent now
tibbsHow's the blocker list?
f13and I'm not too dissapointed with the state of things
jeremyin 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
we've never done a PR release before
so why is this all of a sudden a major concern?
jeremyjwb: we've done 3 test releases in the past
jwbtest3 wasn't scheduled so close to release though was it?
jeremyand 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 :)
nottingsorry i'm late
bpepplenotting: np.  we're just discussing whether we need to slip the release or not.
* wwoods here, as requested
bpepplewwoods: your thoughts on the state of the blocker list?
wwoodsmy gut feeling is that there's a lot of fiddly little problems
but nothing of pants-messing magnitude
jeremyand 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
bpeppleI 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.
buggbotBug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=435969 low, low, ---, Adam Jackson, ASSIGNED , gnome (with compiz) crashes on Alt-Tab
wwoodsat least, nothing I'm aware of. it's possible that I'm just blissfully unaware.
blockers are determined by the ReleaseCritera page
jeremybpepple: it's on the blocker list
wwoodsthe one-sentence summary is: anything that breaks installs, yum, or new features *may* be a blocker
bpepplejeremy: ok, I wasn't sure whether it was or not.  thanks.
wwoodscompiz, generally, is not
jeremywwoods: the one thing that the ReleaseCriteria page doesn't really cover, though, is "makes Fedora look bad".  because that's a subjective thing
wwoodsjeremy: right
nottingwwoods: what happened to 'services start cleanly', etc?
wwoodswe 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
wwoodsthe Release Criteria are *sufficient* conditions for blockers, but not *necessary*
we can opt to block the release for things that are outside of that
jeremywwoods: *nod*
wwoodslike 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.
bpepplewwoods: agreed.
tibbsjeremy: So you think we should slip?
jeremythings 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
wwoodsfwiw alt-tab doesn't crash my intel-based compiz-running machine
tibbsI was going to ask "for how long", but you preempted me.
jeremywwoods: 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)
tibbsI heard that he had fixed it for 945 and was working on 965.
stickstertibbs: We really need to stick with a week as a unit of time for any possible slip.
wwoodsand 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
tibbsstickster: Yes, I understand.
wwoods(that's bug 436099)
buggbotBug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=436099 high, low, ---, Alan Cox, NEW , [ata_piix] booting has failed
wwoodsI really haven't gotten to look at F9Target very closely though
tibbsBTW are we trying to have the 2.6.25 release kernel in for release?
jeremywwoods: I started to last night but then I saw the time
wwoodsI'm with jeremy - It'd be possible to do the 29th if we were forced, but it would make everyone involved nervous and unhappy
jeremytibbs: I think it got built last night
tibbsBuilt, yes, but tagged for the release or as an update?
jeremytibbs: 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 :)
wwoodswhich always, ALWAYS leads to rushed fixes, which introduce nasty last-minute regressions, which makes everything spiral out of control
dwmw2and we get a lot of flak when we ship non-released software :)
tibbswwoods: The way to avoid that is to have defined criteria for what we're trying to accomplish during the slip.
nirikdwmw2: non released? 2.6.25 is out...
bpepplef13, 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
dwmw2makes sense
tibbsI can't argue with that.
* bpepple is inclined to agree w/ jeremy on the slip.
tibbsWhat's the possible fallout of a two week slip?
tibbsI don't recall any hard deadlines that we're trying to meet, like a specific conference.
bpeppletibbs: It might bump some of our marketing people's plans.
jeremywe're at 6 months + 5 days for the release instead of 6 months - 9 ? :)
dwmw2the kernel nutters start sending all their patches, and we accidentally ship 2.6.26-rc1?
nottingbpepple: 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
jwbf13 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.
nottingjwb: to be able to hand it out at a specific show, iirc
bpeppleok, it sounds like most of fesco is in favor of slipping, but we should probably get a show of hands.
f13jwb: I'm going to be out of the state starting next thursday for a week
wwoodsis one week sufficient?
f13jwb: 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.
jeremywwoods: one week is probably on the border of enough, I'd feel far more comfortable with 2
f13If 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
tibbsf13: Do you think a slip is necessary?
sticksterThere'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_
f13tibbs: I think slipping will get us a better release.  I think that's almost always the case though.
jeremywe've got too much good going on with Fedora 9 -- let's get it right and not cut corners
sticksterjeremy++, f13++
tibbsWell, if we have too much good, we should obviously try for less good.
bpeppleProposal: Slip the release 2 weeks.
f13I'm just not sure if slipping will fix /enough/ to make it worth the slip
wwoodsIt's *always* true that more time -> more bugs fixed.
jwbwwoods, and more found
nottingstickster: elaborate?
f13wwoods: also, this would be more frozen time, which just adds to either the churn or more saying "no, you can't update that"
wwoodsI might need to more closely examine what actually needs fixing before making a decision here.
tibbsf13: And more zero day updates.
jeremybpepple: +1
wwoodsright. devs hate freeze time, and I don't blame them
* nirik wonders if a special session later to decide might be in order?
wwoodsand users hate delays
and I like making things more stable but I hate prolonging the end-of-release insanity
f13and releng hates slips (:
tibbsI think we pretty much need to decide now.
sticksternotting: Mainly to do with our tools for art and how they translate to the CD printer's preferred input formats (in this case, PDF)
nirikfair enough.
* nirik goes to look at blocker list.
sticksternotting: There's also color matching involved, although we *may* have solved that last release.
* stickster still waiting for some other answers.
tibbsstickster: Do we need to tie artwork and printing to our actual release date?
nottingstickster: i mean, do you need to slip?
f13note, the last round of printed media came pretty well after the release
sticksterNo, 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.
tibbsIt's theoretically possible for the printed releases to be available later than the torrents.
sticksterf13: 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.
f13I'm just not in favor of slipping for the fear of getting stuff done, without specifics of /what/ we are slipping for
f13other than just "more time for bugs"
wwoodsI 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
nottingthe x blocker/target list worries me
wwoodsbut it's kind of shady to go on gut feelings alone
tibbsThe x blocker list has one open bug on it.
wwoodsI wanna back up my gut with some bug IDs.
jeremywwoods: I want to bloody give the PR time to actually be OUT THERE
otherwise, it's a waste of everyone's time
wwoodsjeremy: as do I
nottingtibbs: f9-x-target
f13jeremy: are you just hoping for more PR users than our typical rawhide users?
or wanting more (split)media testing?
or both?
jeremywwoods: how the hell do we do that and release in less than two weeks?
wwoodsbut I want some more concrete reasons for slipping
tibbsThat's different from f9-x-blocker, though.
jeremyf13: both.  and live testing.
wwoodsno, I'm not suggesting that we don't need to slip
I think we do
jeremywwoods: the concrete reasons for slipping is that we've slipped *every* *single* *milestone* except for the final
poelcathow can we determine the quality of the blocker list if PR isn't released?
nottingtibbs: hence blocker/target :)
wwoodspoelcat: plenty of rawhide / internal testing happens
people test more than just the releases.
bpepplejeremy: +1
jeremywwoods: on very limited sets of hardware
poelcatwwoods: we have a historical disagreement there :)
wwoodsdude, I am not arguing against the slip. I am arguing for having some time to flesh out the *reasoning* for the slip
jeremywwoods: 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"
f13poelcat: PR is absolutely not necessary to validate fixed bugs on the blocker list.
wwoodsa week? no, I mean, like, an hour
nirikis 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 ;-)
jeremynirik: he's back next week iirc.  just XDC this week
poelcatf13: but i think it is necessary to generate a better final blocker list
jeremywwoods: 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
nirikjeremy: ok, so limited X fixes this week?
wwoodsokay, so we're missing ajax *and* f13 for part of the next two weeks?
jeremyand we keep putting it off
f13poelcat: I'm not so sure about that if we actually use the real definition of release blocker critera.
jeremywwoods: we've been missing ajax most of this week
nottingtibbs: to be specific - 239125 (which involves 429183), 435969, 441373,
wwoodsthe 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.
f13and seriously, how many bugs on our "blocker" list are actually Release Blockers by our definition?
tibbsThe one open X blocker doesn't seem to be.
nottingf13: installs and then three-clicks-to-a-system-crash technically 'passes' the release criteria
doesn't mean we should ship that way
bpeppleok, 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?
poelcatbpepple: and decide whether or not PR is a gating factor?
f13how 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
bpepplef13: I'm fine with that.
* bpepple agrees with jeremy that that can be one of the reasons.
f13jeremy: 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
jeremyf13: 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
wwoodsIt'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.
bpeppletibbs, jwb, caillon, dwmw2: ?
dwmw2if pushed to opine I'd probably go for the slip
dwmw21 week or maybe 2 if that makes more sense
tibbsIt seems like most of the people who are working in this stuff agree that we need to slip.
dwmw2but I think I'm closer to a 0 too
f13it's going to have to be 2 unless we want somebody else to do the release.
wwoods2 weeks, then. How many weeks did we slip the Alpha and Beta by?
bpepplewwoods: about 2 or 3 weeks I believe.
wwoodswell, individually and combined
jeremybeta was 12 days off of the original schedule
wwoodsIt'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
jeremyalpha was the same
wwoodsso, call it two weeks each?
caillonbpepple, +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.
wwoodsokay. I don't think I actually get a vote here, but I'd give +1 to a 2-week slip
bpeppleok, I don't hear any strong objections to a 2-week slip, so I think we've made our decision.
wwoodsand I'd like to remember, in the future, that we ended up needing half of the time we lost from the Alpha/Beta schedules
f13wwoods: as QA guy, I think you absolutely get a vote on this.
bpepplef13: agreed.
f13wwoods: I don't know if we can count on that to happen every time
wwoodsheh. 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
bpepplewwoods: maybe not a formal vote, but obviously your opinion is going to be taking into account since you head up the QA team.
wwoodsbpepple: right on.
bpeppleok, so who gets the joy of announcing this?
caillontypically, it's rel-eng
* bpepple is fine with that. ;)
cailloni could do it though if they don't want to
wwoodsheh doh. all those counter images will need resettin' too
f13wwoods: eh, we warned 'em.
ha ha! now it's 26 again.
f13wwoods: all computer timers go backwards in time at some point
wwoodswith or without the help of Doc Brown.
bpeppleok, anything else we need to discuss in regard to the release?
f13cvs mass branching
I'd like to do that tomorrow or over the weekend
wwoodsIt'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)
caillonf13, +1 to that
f13it will involve CVS outage, for perhaps an entire day
wwoodsdo we have cvs usage metrics that tell us when a good time for an outage is?
* wwoods just curious
caillonwow, an entire day?
* caillon didn't realize it took that long
wwoodscvs: not known for its speed
caillonwwoods, 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"
f13caillon: 15K packages to adjust pkgdb entries and then do cvs masturbations on
f13/hate/ the cvs
bpepplef13: do those changes kick off e-mails?
f13trying to not do that, which means an outage
wwoodsit kinda seems like everyone is gradually migrating towards git
f13(so that no untracked changes sneak through)
wwoodsat least in Fedoraland
caillonf13, which is slower?  pkgdb or cvs?
f13wwoods: yeah, that's the case.
* caillon hides
f13caillon: well, last time they were equally slow
caillon: but toshio improved things a bunch in pkgdb he claims
caillonf13, i haven't noticed it yesterday with my mass committing
nirikcvs is a lot slower than pkgdb these days
dwmw2ok, yaboot-1.3.13-12.fc9 seems to work, and is actually built from source. f13, please can we tag for f9?
nirikcaillon: what did your mass committing hit pkgdb for?
caillonnirik, cvshook hits it
to email peeps
caillon: I'm going to hopefully disable the cvshooks
dwmw2hm, btw can I stop being mailed about anything involving xulrunner just because I once committed a patch? :)
f13skip acl lookup (I have acls to everything), skip notify lookup (don't care)
niriksure, but I think it's cvs and/or sending the email thats slow... pkgdb answers pretty quickly I think
f13nirik: building up and tearing down the lookups take time
caillonnirik, it's something like O(n^2) where n is number of people approved
nirikdwmw2: yes, just go to the page and drop watchcommits
dwmw2: https://admin.fedoraproject.org/pkgdb/packages/name/xulrunner
caillonnirik, you might just be hitting pkgdb entries with few people on it
dwmw2doh. ta.
nirikcould be.
caillonnirik, the firefox pkgdb page takes something like 40s to load, while others with fewer people explicitly listed take ~1-2s to load
f13that's all I've got
bpeppleok, we're to the hour point.  Is there anything else that needs to be discussed, or should we wrap up?
* jeremy has to run
caillonnirik, i've been talking to toshio about it
nirikcaillon: ok.
caillonf13, are you going to send the slip notice?
nottingbpepple: yay feature complete!
f13caillon: I will.
caillonf13, hot
bpepplenotting: ;)
f13I 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
bpepplef13: that's a good thing.
f13it's a really really good thing
bpeppleok, 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!