| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * dgilmore will be a couple of minutes late | ||
| jima | how rude! | |
|---|---|---|
| dgilmore | stupid websites falling over | |
| * jima will stop, sorry. | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
| Hi everybody; who's around? | ||
| * tibbs here | ||
| f13 | here. | |
| dwmw2_BOS | fish | |
| * notting is here | ||
| spot stirs | ||
| * jima is in the cheap seats | ||
| poelcat here | ||
| notting | jima: get them off of stubhub? | |
| * jeremy is here | ||
| jima | notting: as i don't know what that is (scalping website?), i'll say "no." | |
| * nirik is here. | ||
| * bpepple gives folks another minute or so before starting the meeting. | ||
| f13 | I'm going to have to multitask at 1:30 | |
| --- bpepple has changed the topic to: Misc - Quick Note about: https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat | ||
| bpepple | poelcat: you wanted to give a quick update? | |
| poelcat | Overall I am looking for more concensus and support from FESCo and a unified front for for the F9 feature cycle. F8 worked pretty well, but I would like to iron our the parts that didn't work or committee members did not agree with now so the process can run smoother during the F9 feature cycle | |
| I am also open to things that I can do better or different to make it run smoother | ||
| I have started a wiki page here: http://fedoraproject.org/wiki/Features/F9PolicyReview | ||
| t next week's FESCo meeting I would like to get concensus on the issues raised there, which I will summarize in advance | ||
| that's all :) | ||
| bpepple | poelcat: that sounds good. | |
| thanks for the quick update. | ||
| --- bpepple has changed the topic to: Misc - Proposed Devel Changes - http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal - f13 | ||
| * warren here | ||
| f13 | I have not received any feedback in a while on this. | |
| * bpepple likes the proposal. | ||
| * poelcat added a detailed schedule including the weekly snapshots | ||
| f13 | nod. | |
| * nirik also likes it. | ||
| nirik | wwoods: how do you feel about it from the QA side? | |
| wwoods | I haven't really had time to go over it carefully. Generally I like the idea of dropping Test1 and giving the test releases better names | |
| dwmw2_BOS | "Also due to the way that our CVS is set up we end up blocking developers from working on next release type changes" | |
| I consider that a _feature_ of the current process | ||
| jeremy | f13: I suspect we'll need to be a little flexible the first time around, but am in favor | |
| wwoods | and having an official RC1 date is good | |
| since the "freeze" isn't real freeze-y | ||
| * poelcat wonders if the testing blocks are long enough particularly at the end? | ||
| poelcat | http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html | |
| f13 | dwmw2_BOS: I don't find making developers sit on their hands for long periods of time an effective use of time or money. | |
| wwoods | so at least there's a day I can point to and say "all bugfix builds must be in by this day" | |
| nirik | does this also mean an end to new bugzilla components for all the test releases? or would there still be alpha/beta/rc in there instead of telling everyone devel? | |
| warren | f13, +1 | |
| wwoods | I find the versions for test releases to be useless | |
| * nirik does too. | ||
| f13 | but until we can scrub all the ones that are currently in there.... | |
| we'll probably have to keep adding them as it just led to too much confusion. | ||
| wwoods | no | |
| refuse | ||
| heh | ||
| f13 | I left the bugzilla stuff out as that's really an ongoing effort with wwoods | |
| wwoods | we just need people to understand that test releases are rawhide snapshots | |
| and rename 'devel' to 'rawhide' | ||
| nirik | yeah, kinda another topic... I think we should not make them, but a fight for another day. | |
| poelcat | wwoods is 7 days enough time to test an RC? | |
| wwoods | it's more than we get now | |
| f13 | poelcat: it's not really an RC, but we're calling it that to make people feel better about testing it | |
| poelcat | okay; how about the 2 days testing for the final compose? | |
| f13 | The new proposed changes gives us about the same amount of qa time as the tail end of F8 did, and I think that went pretty well as a balance between time to QA and having rotten bits to release | |
| wwoods | but as I've said I haven't had a chance to go over the whole schedule and review this release and figure out how much time I think we need to test an RC | |
| f13 | poelcat: the testing of the final compose really should jsut be sanity check that the compose process itself didn't fall over. | |
| dwmw2_BOS | as long as the CVS branching remains optional, I don't really see a problem. I wouldn't like to be _forced_ to maintain separate devel/ and F-9/ branches, for example, if I could just have one. | |
| I mean, don't see a problem with the proposal | ||
| f13 | dwmw2_BOS: correct, it would only be mandatory at the mass branch date. | |
| wwoods | ..except that we didn't even try to restrict changes after the RC | |
| f13 | dwmw2_BOS: which is the final freeze point. | |
| jima | where would the packages from the devel/ branch end up? | |
| f13 | warren: sure we did. | |
| er | ||
| warren | wwoods, couldn't your parents have chosen a different letter? =) | |
| f13 | wwoods: sure we did. It just happened that most the changes proposed after the "rc" were reasonable and not worth denying. | |
| wwoods: had somebody proposed a rebase of something or a soname change or something that would require rebuilding a bunch of stuff we would have said no. | ||
| dwmw2_BOS | f13: I'm a bit dubious about making it mandatory ever -- if I'm not changing the package in devel/ it's kind of suboptimal if I have to build there specially, so that devel gets the last-minute-panic bugfix from the upcoming release | |
| f13 | jima: at which point? | |
| warren | wwoods, it wasn't just rubber stamping whatever people asked either, I actually examined most of what I approved and sent back a few with comments. Some were just NO. | |
| wwoods | but that's no different from the normal freeze, is it? | |
| dwmw2_BOS | but I'll not argue much about it. | |
| poelcat | wwoods: +1 | |
| jima | f13: after an F-9 branch is split off | |
| f13 | jima: a holding pen for F9 builds. | |
| wwoods | I didn't see a difference in the rate of changes or the standard for accepting changes | |
| maybe there was a change in the standard and I just didn't see it | ||
| f13 | jima: until we get to a point where we can compose two trees nightly. | |
| jeremy | f13: something I'd like to investigate is using bodhi for accepting changes once we are locking things down for the release | |
| * poelcat thinks RC needs to be an RC (which means 99% chance it won't change) | ||
| wwoods | well, yeah, that's what I want to shoot for | |
| jima | f13: okay; otherwise i wasn't seeing the point in maintaining two branches for the same target. | |
| f13 | look, I don't want this to become RHEL were we turn people away from fixing things jsut becuase they don't have th emagic power to put it on a blocker list somewhere | |
| wwoods | the RC date should actually be "seriously, unless there is a bug that sets orphans on fire, these are the final bits" | |
| I don't want it to be like that either | ||
| dwmw2_BOS | poelcat: indeed. calling something a release candidate when there's almost no chance that it's actually what'll get released is a little disingenuous | |
| f13 | and once we "final freeze" it takes us time to sort out all the changes that have been made up to that point, there isn't much reaosn why we can't take reasonable bugfixes in while working on the really nasty bugs. | |
| dwmw2_BOS: I tried making that argument, but it happens all the time. | ||
| dwmw2_BOS | so if we let rawhide continue while the F-9 branch is still making (slow) progress, will we have nightly composes of F-9 on the mirrors too? | |
| jeremy | poelcat: have a better term for it? | |
| wwoods | I just want to have what we believe are the Seriously Final Bits more than 36 hours before the go/no-go date | |
| poelcat | wwoods: +1 | |
| f13 | I'm open to a better term for the snapshot we do at the final slush point. | |
| uh... | ||
| warren | Don't call anything RC until it is truly considered as a RC. | |
| dwmw2_BOS | to a certain extent, nomenclature is irrelevant. Get the process right, and we can decide what to call it later | |
| f13 | wwoods: so what, so we can sit on those bits for 5 days and look at them? | |
| wwoods | ... | |
| wwoods | because.. that's what you think QA is? | |
| f13 | except you ant them to be seriously final bits, so we won't take in any fixes unless it's seriously broken | |
| poelcat | f13: then you are always testing against a moving target | |
| dwmw2_BOS | hehe | |
| f13 | which if we're doing our jobs right, we'd know if it was seriously broken before that point. | |
| dwmw2_BOS | fsvo 'moving' | |
| if one game package changes, for example, that doesn't invalidate much of the prior testing | ||
| pp_ | Even if fixes don't get in the final, you get time to get the "known bugs" and 0-day updates done. | |
| warren | wwoods, bottom line is this cycle was far more productive because we didn't disallow reasonable fixes in while we worked on the nasty bugs. | |
| wwoods | right, no, that was OK | |
| poelcat | if we want a higher quality release we need more polishing/finish == QA time at end | |
| tibbs | I can't disagree with that. | |
| bpepple | Are we getting slightly off-topic? The schedule is only an example at this point isn't it? | |
| f13 | and we have far less 'stupid but not really blocker" bugs left in our tree at GA. | |
| wwoods | those changes were vetted and whatnot, I'm not unhappy with the way the release has gone up to this point | |
| * dgilmore is here now | ||
| wwoods | I'm unhappy with the distance between this point and the handoff to mirrors | |
| f13 | poelcat: what defines 'higher quality' though? How is the bugs you find at the end any more important than the bugs other maintainers find and ask to be included? | |
| jeremy | wwoods: the reason for the short runway there is to get the bits out as fast as we can. and to help get work started on the next release sooner | |
| nirik | wwoods: should be shorter? or longer? | |
| wwoods | nirik: longer. seriously, though, this is not the time for this discussion | |
| f13 | again, what are you going to do with that longer time? | |
| poelcat | f13: shipping with fewer gotchas | |
| dwmw2_BOS | poelcat: it's true that QA time at end improves quality. It also increases the amount by which we're already out of date on the day we release. There is a trade-off. We're not trying to produce RHEL. | |
| f13 | tell more people that no, your bugs can't be fixed because our QA people didn't find it? | |
| tibbs | If the tree compose was quicker, would that free up enough time to make a difference? | |
| wwoods | f13: give it to testers (who have waaaay more hardware/weird setups/aggregate free time) | |
| f13 | poelcat: what defines a "gotcha" though? These "gotchas" are /EXACTLY THE SAME THINGS/ we're fixing and mkaing things "moving". | |
| wwoods: our community /IS OUR TESTERS/ | ||
| wwoods | and they can't get the bits | |
| to test 'em | ||
| f13 | wwoods: they're finding bugs, building fixes, and asking us to include them. You want us to say no, so that you can find these things, and fix them, and ask us to get the fixes in? | |
| jeremy | tibbs: it would help some, but it's not really the blocking factor at this point | |
| f13 | wwoods: the bits are sitting in rawhide. | |
| wwoods | seriously, this is not the time for this conversation | |
| bpepple | wwoods: agreed. | |
| f13 | wwoods: thats the point of the final freeze is to stop the random builds from getting in, and allow people test against it, to provide the actual bugfix builds so that we can get them in. | |
| wwoods | I don't want to argue this point because I still haven't had time to review and actually come up with something that makes sense | |
| Instead I'm being made to improvise a solution in the middle of a meeting and justify that solution | ||
| let's get the release out and talk about it later | ||
| jeremy | wwoods: indeed | |
| wwoods | as I said, I'm happy with the release process up to this point | |
| f13 | wwoods: so are you on board with these changes or not? Because we have to set a schedule very soon, and I would like to base said schedule on this proposal. | |
| * c4chris_ is here now... (darn DST) | ||
| wwoods | the changes, yes, but we may end up debating the finer points of the definition of "Release Candidate" and/or exact dates (+/- 1wk) | |
| everything else seems solid to me | ||
| f13 | ok. | |
| To be fair, I don't like calling that snapshot at the start of the final freeze a "release candidate", so I'm open for terms that make sense for what it is, but also invites people to actually look at it rather than waiting for when it will "stablalize" and be too late to take any input from them. | ||
| nirik | preview release? | |
| poelcat | f13: gotcha = suspend/hibernate doesn't work (admitedly a F7 problem, but it could happen again); i'm concerned about the GA bits because they are what matters on the Media we burn for LUGS and tradeshows, etc. | |
| f13 | case in point RC3 today. We really don't care what little bugs people find, so its somewhat a crapshoot to throw it out there althought it is really a "release candidate" | |
| poelcat: wwoods: I really want to have this conversation, but not here. Please find a time were we can hash it out | ||
| wwoods | But we're still finding stuff and adding it to the CommonBugs page and/or getting stuff ready for 0-day updates | |
| QA doesn't stop just 'cuz we've frozen the bits for the media | ||
| jeremy | f13: if something really awful were found, we could still stop the train | |
| wwoods | we can talk about it in next week's QA meeting (1500UTC Wed.) | |
| bpepple | anything else people want to discuss regarding f13's proposal, or are we at a point where we can vote on it? | |
| poelcat | f13: wwoods QA meeting sounds like good idea | |
| f13 | jeremy: yes, we could. I just don't see that happening except for we invited more people to look at these basically same bits because we named it differently. | |
| wwoods | It's still worth knowing what needs fixing even if we can't fix it | |
| has zero impact on the actual rel-eng/infrastructure side of the release process | ||
| pp_ | alpha, beta, preview, series of RC's at T-7 days or so.? | |
| wwoods | but it's still important | |
| mdomsch | gonna churn the mirrors daily with the RCs? | |
| * nirik remembers preview releases from BeOS... PR1, PR2, etc... | ||
| f13 | wwoods: so is getting the bits out so that we can point rawhide at the F9 bits and have a chance in hell in getting the next release done :/ | |
| mdomsch: so far, RCs have been torrent only. | ||
| wwoods | but you could kick rawhide over to f9 now | |
| couldn't you? | ||
| f13 | no | |
| that would screw people who installed pre-release images | ||
| mdomsch | it's a nit, but I'd like to see RCs available for download, just probably not from the full mirror set | |
| wwoods | but the pre-release images point at Fedora/Updates | |
| f13 | wwoods: which is really counter productive to inviting people to test pre-releases. | |
| wwoods: those are just updates, there is no tree to point to for depsolving. | ||
| or for installing new packages | ||
| nirik | mdomsch: perhaps a opt-in checkbox for mirrormanager? and another rsync target? | |
| wwoods | then probably the actual RC point should include moving all the (signed) packages into the actual fedora/updates repos | |
| jeremy | mdomsch: unfortunately, with how we currently have to populate the mirror master, that's not really practical :( | |
| mdomsch | nirik, just an excludeable dir | |
| f13 | honestly, I want to stage RCs in the actual final location and point at /that/ for stuff. | |
| as a second rawhide type thing. | ||
| tibbs | Letting end users say "pin this machine to whatever will evolve to the F8 release" is a great way to get more testing. | |
| f13 | but until we make some significant changes in how we're allowed to touch those directories I don't see that happening. | |
| mdomsch | f13, +1 | |
| tibbs | The earlier that's possible, the more testers you can get. | |
| lmacken | if we point the RC at an updates-testing repo, bodhi could then be used to QA/vote on updates. | |
| we already have 127 pending F8 updates | ||
| which aren't getting tested at all | ||
| warren | fedora-release pointing at fedora.repo and fedora-updates.repo wasn't that with a goal? (Except we screwed up by doing it too soon.) | |
| f13 | I think we're getting off intot he weeds. | |
| jeremy | tibbs: one thing we've discussed for making that possible is deciding the name early (like, right after we release f8) and then we can have a foobar symlink pointing to development that then moves to point to 8 | |
| f13 | this is a great topic for the next FUDCon | |
| but not something we're going to solve today | ||
| jeremy | indeed | |
| f13 | my proposal is a first step at getting there, and something we /can/ accomplish for F9 | |
| jeremy | I think that we're all in basic agreement that the structure looks good and that we still want to leave some room for playing with the end game | |
| f13 | which we can build from to do even better in F10+ | |
| bpepple | jeremy: +1 | |
| tibbs | jeremy: +1 | |
| c4chris | jeremy: +1 | |
| notting | +1 to f13's propsal | |
| nirik | yep. agreed. | |
| +1 here. | ||
| spot | +1 | |
| warren | +1 | |
| jeremy | although we want to have a schedule for f9, we can and do change things in the schedule. so doing so with the end game isn't problematic | |
| tibbs | One comment about "no new Features considered", though. | |
| wwoods | right, the only things I have any desire to discuss further is the definition of Release Candidate (as opposed to, say, Preview Release) | |
| f13 | I +1 it myself obviously. | |
| wwoods | I guess that should just be "thing" | |
| tibbs | Even March is too late for big destabilizing things like the NM overhaul. | |
| f13 | tibbs: "considered" doesn't mean accepted. | |
| tibbs | Well, sure, but if someone expects to be able to submit whatever features they want on March 4, the may be disappointed. | |
| pp_ | are all features equal? no. | |
| f13 | tibbs: not really my problem. | |
| or a problem IMHO | ||
| tibbs | The point is that we give no indication that earlier is better. | |
| f13 | tibbs: that's clearly just a communication thing. | |
| tibbs | We just say "have all your features submitted by March 4". | |
| When March 4 is clearly too late for some things. | ||
| jeremy | tibbs: I think clarification around that is one of the things poelcat is trying to do | |
| f13 | tibbs: poelcat's schedule shows when we start processing features. | |
| bpepple | jeremy: right. this probably make more sense to discuss next week when we talk about the feature process. | |
| f13 | indeed. | |
| tibbs | BTW, the gantt chart link is broken in that proposal page. | |
| dgilmore | tibbs: we probably need to make a case by case decsion when reviewing feature requests. depending on how much testing, is needed how invasive the change is etc | |
| * poelcat schedule also shows an end | ||
| poelcat | tibbs: oops | |
| f13 | dgilmore: we do make case by case decisions. | |
| dgilmore: thats the entire purpose of the Feature review. | ||
| poelcat | "open feature review" 105 days | |
| dgilmore | f13: sure but we may say you need to have this done earlier because its invasive and needs lots of testing and adjustments elsewhere | |
| f13: im probably confused right now | ||
| poelcat | tibbs: fixed now | |
| bpepple | Ok, is there anything else? Or should we move on? | |
| tibbs | move on++ | |
| bpepple | done. | |
| --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02797.html | ||
| tibbs | Note that we've done something we haven't done before. | |
| We've asked that a change be pushed via the feature process | ||
| because it gives a nice basis for coordinating a change to all of the involved packages. | ||
| bpepple | tibbs: Who would be the driver for this feature? | |
| nirik | and also advertising to 3rd parties to change their stuff too. | |
| tibbs | bpepple: Patrice. | |
| tibbs | Unfortunately I've forgotten his nick. | |
| bpepple | tibbs: np. | |
| tibbs | But the overarching question is whether people think this is a useful avenue to travel. | |
| Using the feature process, I mean. | ||
| * f13 is on another call right now and not paying much attention. | ||
| c4chris | sounds sane enough to me | |
| nirik | yeah, I think that makes sense... as long as he is willing to drive it. | |
| tibbs | So we'll try to have that whipped up for presentation next week even though FPC won't meet before then. | |
| c4chris | just need to make enough noise on f-d-l too, of course | |
| bpepple | c4chris: agreed. | |
| tibbs | We're trying to avoid the case where someone just goes off and files a ton of bugs with no coordination plan. | |
| Because I think that's happened at least three times now and has pissed off a bunch of maintainers. | ||
| c4chris | yea, that tends to annoy people :) | |
| bpepple | tibbs: agreed. | |
| tibbs | The other proposal is straightforward: | |
| specifying the directory for f90 .mod files. | ||
| * bpepple has no objections to it. | ||
| c4chris | +1 | |
| * nirik has no objections to any of the FPC report. | ||
| jeremy | +1 | |
| notting | +1 | |
| bpepple | ok, I don't see anyone having a problem with these proposals, so I think we can move on. | |
| tibbs | We will vote on-list on that open proposan and should be able to present it next week even though we won't have a meeting before then. | |
| move on ++ | ||
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | anything else people want to discuss before wrapping up for today? | |
| poelcat | When is the go/no-go decision on F8 or has it already been made? | |
| wwoods | tomorrow would be the handoff to IT | |
| bpepple | wwoods: we're looking pretty good at this point aren't we? | |
| wwoods | 294/295 blockers closed, the last one just needs retesting with Live+dmraid | |
| bpepple | cool. | |
| * wwoods has no mdraid hardware, f13/pjones were on that one | ||
| jeremy | bpepple: do we have a fesco election coming up? (I don't remember) | |
| bpepple | nope. we do it once a year. | |
| wwoods | so yeah, everything is looking good for an on-time release (wee!) | |
| jeremy | bpepple: good enough for me! | |
| wwoods | but we'll continue to test and add things to F8Target (which is "stuff we want fixed in updates ASAP") and/or Bugs/F8Common | |
| bpepple | I don't think I'd want to go through the pain of setting up the election more than once a year. ;) | |
| ok, unless there is anything else I think we can wrap up the meeting. | ||
| c4chris | wrap++ for me | |
| * 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 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!