--- 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
jimahow rude!
dgilmorestupid websites falling over
* jima will stop, sorry.
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
* notting is here
spot stirs
* jima is in the cheap seats
poelcat here
nottingjima: get them off of stubhub?
* jeremy is here
jimanotting: 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.
f13I'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
bpepplepoelcat: you wanted to give a quick update?
poelcatOverall 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 :)
bpepplepoelcat: 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
f13I have not received any feedback in a while on this.
* bpepple likes the proposal.
* poelcat added a detailed schedule including the weekly snapshots
* nirik also likes it.
nirikwwoods: how do you feel about it from the QA side?
wwoodsI 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
jeremyf13: I suspect we'll need to be a little flexible the first time around, but am in favor
wwoodsand 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?
f13dwmw2_BOS: I don't find making developers sit on their hands for long periods of time an effective use of time or money.
wwoodsso at least there's a day I can point to and say "all bugfix builds must be in by this day"
nirikdoes 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?
warrenf13, +1
wwoodsI find the versions for test releases to be useless
* nirik does too.
f13but 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.
f13I left the bugzilla stuff out as that's really an ongoing effort with wwoods
wwoodswe just need people to understand that test releases are rawhide snapshots
and rename 'devel' to 'rawhide'
nirikyeah, kinda another topic... I think we should not make them, but a fight for another day.
poelcatwwoods is 7 days enough time to test an RC?
wwoodsit's more than we get now
f13poelcat: it's not really an RC, but we're calling it that to make people feel better about testing it
poelcatokay; how about the 2 days testing for the final compose?
f13The 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
wwoodsbut 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
f13poelcat: the testing of the final compose really should jsut be sanity check that the compose process itself didn't fall over.
dwmw2_BOSas 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
f13dwmw2_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
f13dwmw2_BOS: which is the final freeze point.
jimawhere would the packages from the devel/ branch end up?
f13warren: sure we did.
warrenwwoods, couldn't your parents have chosen a different letter? =)
f13wwoods: 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_BOSf13: 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
f13jima: at which point?
warrenwwoods, 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.
wwoodsbut that's no different from the normal freeze, is it?
dwmw2_BOSbut I'll not argue much about it.
poelcatwwoods: +1
jimaf13: after an F-9 branch is split off
f13jima: a holding pen for F9 builds.
wwoodsI 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
f13jima: until we get to a point where we can compose two trees nightly.
jeremyf13: 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)
wwoodswell, yeah, that's what I want to shoot for
jimaf13: okay; otherwise i wasn't seeing the point in maintaining two branches for the same target.
f13look, 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
wwoodsthe 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_BOSpoelcat: indeed. calling something a release candidate when there's almost no chance that it's actually what'll get released is a little disingenuous
f13and 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_BOSso 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?
jeremypoelcat: have a better term for it?
wwoodsI just want to have what we believe are the Seriously Final Bits more than 36 hours before the go/no-go date
poelcatwwoods: +1
f13I'm open to a better term for the snapshot we do at the final slush point.
warrenDon't call anything RC until it is truly considered as a RC.
dwmw2_BOSto a certain extent, nomenclature is irrelevant. Get the process right, and we can decide what to call it later
f13wwoods: so what, so we can sit on those bits for 5 days and look at them?
wwoodsbecause.. that's what you think QA is?
f13except you ant them to be seriously final bits, so we won't take in any fixes unless it's seriously broken
poelcatf13: then you are always testing against a moving target
f13which if we're doing our jobs right, we'd know if it was seriously broken before that point.
dwmw2_BOSfsvo '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.
warrenwwoods, bottom line is this cycle was far more productive because we didn't disallow reasonable fixes in while we worked on the nasty bugs.
wwoodsright, no, that was OK
poelcatif we want a higher quality release we need more polishing/finish == QA time at end
tibbsI can't disagree with that.
bpeppleAre we getting slightly off-topic?  The schedule is only an example at this point isn't it?
f13and we have far less 'stupid but not really blocker" bugs left in our tree at GA.
wwoodsthose changes were vetted and whatnot, I'm not unhappy with the way the release has gone up to this point
* dgilmore is here now
wwoodsI'm unhappy with the distance between this point and the handoff to mirrors
f13poelcat: 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?
jeremywwoods: 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
nirikwwoods: should be shorter? or longer?
wwoodsnirik: longer. seriously, though, this is not the time for this discussion
f13again, what are you going to do with that longer time?
poelcatf13: shipping with fewer gotchas
dwmw2_BOSpoelcat: 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.
f13tell more people that no, your bugs can't be fixed because our QA people didn't find it?
tibbsIf the tree compose was quicker, would that free up enough time to make a difference?
wwoodsf13: give it to testers (who have waaaay more hardware/weird setups/aggregate free time)
f13poelcat: 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/
wwoodsand they can't get the bits
to test 'em
f13wwoods: 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?
jeremytibbs: it would help some, but it's not really the blocking factor at this point
f13wwoods: the bits are sitting in rawhide.
wwoodsseriously, this is not the time for this conversation
bpepplewwoods: agreed.
f13wwoods: 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.
wwoodsI 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
jeremywwoods: indeed
wwoodsas I said, I'm happy with the release process up to this point
f13wwoods: 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)
wwoodsthe 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
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.
nirikpreview release?
poelcatf13: 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.
f13case 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
wwoodsBut 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
jeremyf13: if something really awful were found, we could still stop the train
wwoodswe can talk about it in next week's QA meeting (1500UTC Wed.)
bpeppleanything else people want to discuss regarding f13's proposal, or are we at a point where we can vote on it?
poelcatf13: wwoods QA meeting sounds like good idea
f13jeremy: 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.
wwoodsIt'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.?
wwoodsbut it's still important
mdomschgonna churn the mirrors daily with the RCs?
* nirik remembers preview releases from BeOS... PR1, PR2, etc...
f13wwoods: 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.
wwoodsbut you could kick rawhide over to f9 now
couldn't you?
that would screw people who installed pre-release images
mdomschit's a nit, but I'd like to see RCs available for download, just probably not from the full mirror set
wwoodsbut the pre-release images point at Fedora/Updates
f13wwoods: 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
nirikmdomsch: perhaps a opt-in checkbox for mirrormanager? and another rsync target?
wwoodsthen probably the actual RC point should include moving all the (signed) packages into the actual fedora/updates repos
jeremymdomsch: unfortunately, with how we currently have to populate the mirror master, that's not really practical :(
mdomschnirik, just an excludeable dir
f13honestly, I want to stage RCs in the actual final location and point at /that/ for stuff.
as a second rawhide type thing.
tibbsLetting end users say "pin this machine to whatever will evolve to the F8 release" is a great way to get more testing.
f13but until we make some significant changes in how we're allowed to touch those directories I don't see that happening.
mdomschf13, +1
tibbsThe earlier that's possible, the more testers you can get.
lmackenif 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
warrenfedora-release pointing at fedora.repo and fedora-updates.repo wasn't that with a goal?  (Except we screwed up by doing it too soon.)
f13I think we're getting off intot he weeds.
jeremytibbs: 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
f13this is a great topic for the next FUDCon
but not something we're going to solve today
f13my proposal is a first step at getting there, and something we /can/ accomplish for F9
jeremyI 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
f13which we can build from to do even better in F10+
bpepplejeremy: +1
tibbsjeremy: +1
c4chrisjeremy: +1
notting+1 to f13's propsal
nirikyep. agreed.
+1 here.
jeremyalthough 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
tibbsOne comment about "no new Features considered", though.
wwoodsright, the only things I have any desire to discuss further is the definition of Release Candidate (as opposed to, say, Preview Release)
f13I +1 it myself obviously.
wwoodsI guess that should just be "thing"
tibbsEven March is too late for big destabilizing things like the NM overhaul.
f13tibbs: "considered" doesn't mean accepted.
tibbsWell, 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.
f13tibbs: not really my problem.
or a problem IMHO
tibbsThe point is that we give no indication that earlier is better.
f13tibbs: that's clearly just a communication thing.
tibbsWe just say "have all your features submitted by March 4".
When March 4 is clearly too late for some things.
jeremytibbs: I think clarification around that is one of the things poelcat is trying to do
f13tibbs: poelcat's schedule shows when we start processing features.
bpepplejeremy: right. this probably make more sense to discuss next week when we talk about the feature process.
tibbsBTW, the gantt chart link is broken in that proposal page.
dgilmoretibbs: 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
poelcattibbs: oops
f13dgilmore: we do make case by case decisions.
dgilmore: thats the entire purpose of the Feature review.
poelcat"open feature review"  105 days
dgilmoref13: 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
poelcattibbs: fixed now
bpeppleOk, is there anything else? Or should we move on?
tibbsmove on++
--- 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
tibbsNote 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.
bpeppletibbs: Who would be the driver for this feature?
nirikand also advertising to 3rd parties to change their stuff too.
tibbsbpepple: Patrice.
tibbsUnfortunately I've forgotten his nick.
bpeppletibbs: np.
tibbsBut 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.
c4chrissounds sane enough to me
nirikyeah, I think that makes sense... as long as he is willing to drive it.
tibbsSo we'll try to have that whipped up for presentation next week even though FPC won't meet before then.
c4chrisjust need to make enough noise on f-d-l too, of course
bpepplec4chris: agreed.
tibbsWe'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.
c4chrisyea, that tends to annoy people :)
bpeppletibbs: agreed.
tibbsThe other proposal is straightforward:
specifying the directory for f90 .mod files.
* bpepple has no objections to it.
* nirik has no objections to any of the FPC report.
bpeppleok, I don't see anyone having a problem with these proposals, so I think we can move on.
tibbsWe 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
bpeppleanything else people want to discuss before wrapping up for today?
poelcatWhen is the go/no-go decision on F8 or has it already been made?
wwoodstomorrow would be the handoff to IT
bpepplewwoods: we're looking pretty good at this point aren't we?
wwoods294/295 blockers closed, the last one just needs retesting with Live+dmraid
* wwoods has no mdraid hardware, f13/pjones were on that one
jeremybpepple: do we have a fesco election coming up?  (I don't remember)
bpepplenope.  we do it once a year.
wwoodsso yeah, everything is looking good for an on-time release (wee!)
jeremybpepple: good enough for me!
wwoodsbut we'll continue to test and add things to F8Target (which is "stuff we want fixed in updates ASAP") and/or Bugs/F8Common
bpeppleI 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.
c4chriswrap++ 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!