--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* dwmw2_BOS arrives
tibbsdwmw2_BOS: I was thinking about raising the issue of adding ExcludeArch to a package in a stable release.
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* jeremy is here
tibbs here.
nirik is here.
f13 is here.
* wolfy lurking
dwmw2_BOStibbs: is there an issue to be addressed? Hopefully it shouldn't be something we're tempted to do, except in exceptional circumstances
tibbsdwmw2_BOS: Well, we have no rules about it that I know of.
tibbsI don't know if ppc64 is somehow special enough that excluding it for some things isn't really an issue.
bpeppleok, we can probably start.
--- bpepple has changed the topic to: Misc - Features - http://fedoraproject.org/wiki/Releases/8/FeatureList - poelcat
* dgilmore is here
bpepplepoelcat wanted to go over the last couple of features that haven't been completed on the wiki.
--- bpepple has changed the topic to: Features - http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements
tibbsThe FeatureList page seems to be out of date.
dwmw2_BOStibbs: yes, it's special -- because we didn't have it in F7 release for most packages.
but we'll come back to that later (or offline)
tibbsLaptop Support is at 100% now.
bpeppletibbs: yeah, your right.  must have been completed earlier this morning.
* poelcat here
tibbsLooks like it.
--- bpepple has changed the topic to: Features - http://fedoraproject.org/wiki/Releases/FeatureNetworkManager
caillonpinged dcbw to update the page
just to make sure that accurate information is there.
dwmw2_BOSdid the backlight problem get fixed?
caillonwill follow up
bpepplecaillon: thanks.
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity
jeremydanpb just sent an update on that one
one small libvirt patch outstanding for everything to be enabled for qemu/kvm (has to pass an option when running them iirc), but everything else is there
bpepplejeremy: cool.
jeremyhe said he'd update the page too
tibbsIt was updated today.
bpepplepoelcat: is there anything else you want to add regarding features?
poelcatbpepple: nope that's good :)
bpeppleok, we can move on then.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
f13I'd like to discuss some of the F9 changes
bpepplethere was nothing else set on the agenda for today, so is there anything people need to discuss?
* bpepple is to slow a typer.
caillonI have an annoucement, too, after f13.
f13since we should coordinate and make clear what all we'd like to change.
--- bpepple has changed the topic to: F9 changes - f13
f13First off, we're going to more aggressively bring back the "Rawhide".
* f13 waits.
jwb_goneif caillon's announcement is quick, maybe it would be better to do that first
f13sure, caillon go for it.
caillonquick makes it easy to do whenever, but sure
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora - caillon
caillonnext week, and for the next 3 months, I'll be in Brno, CZ.  I might miss next week's meeting depending on timing...
dgilmorembonnet: https://bugzilla.redhat.com/show_bug.cgi?id=199362  thats a bug with a patch that fixes the problem
jwb_gonedgilmore, wrong channel :)
dgilmorejwb_gone: opps
jwb_gonecaillon, ok.  have fun in CZ :)
nirikcaillon: cool. You gonna have net access out there? or off line?
caillonone of the things I wanted to do is promote communication with those guys and the rest of fedora, and if there are any suggestions for mini presentations on fedora, i'd like to hear them
nirik: I hope the Red Hat office there has net access :)
f13caillon: I'd like to see them get more involved in things which could benifit from round the clock manning, like cvs admins, releng stuff, security, etc...
caillon: language is a pretty hard barrier though :/
caillonf13: good points.
poelcatf13: language?
nottingi dunno. they all seem to be able to do e-mail in english
caillonyeah, they do type english well, if not speak it
* poelcat has nothing but great experiences working with the people there
* bpepple has a had good experiences with them also.
f13poelcat: I've had a hard time conversing with various folks from there
* nirik isn't sure who all is out there...
caillonf13: I've had issues speaking via phone with them, but in typing, they seem okay.
f13poelcat: a lot of it is my inability to decypher their accent or tell if what I'm saying is being comprehended or washing over them.
caillonand some are better than many americans IMO at speaking.
f13caillon: sure, in typing they're pretty good.
caillonjust need to get the right ones :)
caillonanwyay, I'll talk to you offline about what I can talk about re: cvsadmin, releng
f13and like I said, a lot of the problem is /me/ rather than them.
jeremycaillon: including the right americans? :)
caillonjeremy: the left leaning ones are better ;)
bpeppleanything else regarding caillon's trip, or should we move on?
dwmw2_BOScaillon: I thought it was the ones around the edges, and not in the middle?
nottingabsinthe makes the heart grow fonder?
f13we can probably move on.
--- bpepple has changed the topic to: FESCo meeting -- F9 Changes - f13
f13First off, we're going to more aggressively bring back the "Rawhide".
bpepplef13: the floor is yours.
f13This would involve changing bugzilla from having a 'devel' version to a 'rawhide' version
changing the mirror directory from pub/fedora/linux/development/ to pub/fedora/linux/rawhide/ or even perhaps pub/fedora/linux/releases/rawhide (not real sure/comfortable on that)
f13and just about everywhere else you see things listed as Devel or Development to Rawhide, except for cvs.
cvs... is special
cailloni saw it riding the short yellow bus the other day
f13also warren wants to change the cvs group from 'cvsextras' to 'cvspackagers' or some such
at the same time, I'd like to change the number of test releases we do and freezes for them.
tibbsMore or less?
notting<garth> change? WE FEAR CHANGE>
f13instead of doing three full test releases with full freezes involved cutting at least a month of development time, I'm proposing less, a beta, a release candidate, and then the final.
jeremyjust packagers, not cvspackagers -- so that it's not tied to if we change VCS in the future
f13between those we can do some snapshot releases, torrent only perhaps, that involve non-blocking package freezes.
jeremy: oh right.
jeremyf13: I think we have to somewhat commit to doing some form of additional snapshots in there
f13: perhaps not the same full set of everything, but maybe a live image subset one week, installable images another ...
f13So around the normal test2 time I'd like to do a beta, that is a blocking freeze, and an RC at the final freeze point
bpepplef13: what does the QA guys think?
wwoodsf13: still a month apart?
poelcat the delta between beta and RC will be huge?
considering rawhide churn
f13jeremy: nod.  details to be filled in.
wwoodshow far between RC and final?
f13wwoods: weeks?
caillonf13: is the RC at where test 3 normally is?  or?
f13wwoods: the idea woudl be RC is generated at final freeze time as soon as we can get a booting compose, and base all final fixes on thigns we find in the RCs
wwoodsah, so RC would fall between current test3 and final
f13caillon: maybe halfway between current test3 and final freeze?
wwoodsthat idea I like
f13the creation of the RC would essentially be the final freeze
caillonf13: how would that affect i18n, docs, etc?
and are they signed on?
wwoodsI'm also open to the idea of dropping test1, since it's generally kind of.. raw
half the features aren't even in yet
f13caillon: I haven't proposed it to anybody outside of this irc channel yet.
wwoodsit's kind of a waste to freeze/stabilize/release for something that doesn't even have the features we want tested
f13wwoods: we'd want to do non-blocking snapshots around the test1 time frame.
if we can properly mobilize people to make rawhide more stable and testable
f13caillon: they'd have to revise their schedules obviously
THe motivation is to stop getting in developments way, have fewer blocking freezes
wwoodsthen I'm happy to talk about this stuff some more
tibbsIt would be a good idea to set dates for things like cleaning up depenency issues and such.
* spoleeba makes a note to review this chat log
f13but still have the ability to get somewhat known good trees into people's hands
caillonf13: right.  i guess i meant more of "does it impact them to the point where it's no longer possible for them to get things done"
f13tibbs: right, we don't even really have that today.
caillonbut i guess we need to talk to them first
anyway, i'm not opposed.
f13caillon: I wouldn't think so, but their input is really wanted.
f13I feel that if this subject is not immediately thrown out, it deserves it's own meeting with all interested parties welcome to join
IRC of course
where we can discuss the idea, the schedule impact for each groups, etc.. and try to have something in place for the start of F9 planning
tibbsIs it fair to ask people to let fedora-devel know if they're building something that has the potential to introduce significant instability in rawhide?
caillonsounds good to me
wwoodsnormally we do snapshots because rawhide churns so hard that it's infrequently installable/testable
presuming that rawhide is constantly stable enough to install and test
freezing for snapshots becomes mostly unnecessary
if that's the goal, then I say HECK YEAH
tibbsrawhide has been pretty good throughout the F8 cycle.
f13wwoods: I don't think we can assume that rawhide won't be unstable.
wwoods: that said, we can still make use of koji's freeze tags, we just don't have to compose rawhide from them.
bpeppletibbs: agreed.
wwoodsf13: right, but I think we can change the assumption that it's OK if rawhide is completely hosed
dgilmorewwoods: weekly rawhide installable snapshots?
f13wwoods: we can still have mini-freezes for compose purposes but not distruptive ones.
cailloni'd argue that rawhide should never really be unstable.  the mozilla guys have gotten this part right.
wwoodsit's still gonna be unstable at times, but we want to aim for "occasionally", not "usually"
caillonthey back stuff out without hesitation if something breaks shit, and is unplanned.
f13caillon: I'd agree if there weren't so many moving parts and interdependant stacks maintained by different people on different schedules.
wwoodswell. we want to aim for "never" and hit "rarely" or "infrequently"
nirikmini-freeze each week so friday/monday people strive for more stable?
* poelcat votes for a separate meeting + a proposed schedule or two to illustrate the proposal
tibbsWe have difficulty backing things out, though.
Unless you like to see epochs tend towards infinity.
caillonf13: but we can get them to say "hey, guys, i'm gonna be breaking this shit"
for the most part, people know when they are about to do that
tibbsnirik: The problem with things like that is the community doesn't follow a work-week.
Some people only have the weekends to spare for Fedora work.
jeremylike "here comes python 2.6.  batten down the hatches, it's going to be a rough week"   (not sure if python 2.6 matches our schedule off-hand, but it's a good example case)
spoleebatibbs, amen
nottingi mean, you're always going to have the 'oops, policy broke today' moments
f13caillon: yes, we could certainly do with more heads ups.
caillonjeremy: right.  that type of breakage should be allowed if we have notification
niriktrue, but if there was some schedule about major possibly braking things changes, and when to stablize it might help
wwoodsespecially now that koji is public and we can say "policy broke, you can get the hotfix straight from here"
things are a lot nicer in rawhide-land
f13and if we get some multilib yum love we could make the static-repos more consumable.
jeremywwoods: yeah, that's a huge help.  if we can get to where static-repos is done more often, that'll help even more
f13IE multilib calculation done on the client at install time rather than in the repo at compose time.
* nirik would really really really like to see multilib revisted in f9... and early in the cycle too.
f13I keep starting and stopping a proposal to get people together for that.
I'm having a hard time putting the problem space into words.
wwoodsnirik: yeah, we're moving the multilib tracker to F9Target. Maybe F9Blocker
f13but that's a discussion for another time.
caillon(yes please)
nirikdo we have any high level "should really get done for f9" list? make sure we don't forget to do some of these things? I guess the blocker bugs.
f13anyway, since there seems to be general agreement in here with the schedule change, then I'll move forward with it.
caillonf13: sounds good
wwoodsnirik: NM by default, Multilib..?
f13also I wanted to hear feedback on the 'branch early' option we introduced this release, if people think it's going well or is useful.
jeremynirik: I'd like to see some sort of "let's get together feature ideas" phase... where people actually write up and take ownership of feature pages
caillonjeremy: *cough*fudcon*cough*
* mclasen really likes the branch early option
nirikwwoods: yeah, those 2 for sure...
f13caillon: too late to be relevant.
nirikjeremy: agreed.
bpepplef13: seems good to me, I haven't head anyone complain about it.
wwoodsYARLY. I wish for a pony and a post-release FUDCON every 6 months.
f13caillon: to be relevant fudcon needs to happen pretty much at a fedora release time.
nirikI think it's helped a few people... not many are taking advantage of it tho
tibbsSome people don't really understand the branch-early thing, but those who actually need it have it now and are happy.
caillonf13: maybe we should start having relevant fudcons then instead of the irrelevant ones :)
f13caillon: yeah, I've suggested this.  gregdek is rolling the dice on an early Dec fudcon which would be pretty Fedora 9 relevant.
caillon: but he gives it a 20% chance. We have a better chance at a Fedora 10 relevant fudcon in May
* caillon should have fudcon.cz
f13caillon: you should also host a Fedora 8 release party.cz
bpepplef13: are there any other F9 changes you wanted to bring up?
caillonf13: good plan
f13I think that's it from a high level.
bpepplef13: cool.  thanks.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
f13I'll work more on a proposal for a "town meeting" of sorts.
bpeppleanything else people want to discuss?
nirikwould it be worthwhile to have a post f8 release irc thing in #fedora or the like... get input from what people liked/didn't like about the release? Just a thought.
caillonyou typically find that out without doing that
tibbsWas there any more discussion about fudcon?  I recall mention of one in December.
jwb_gonesorry, had to step away.  did we figure out _why_ we're doing the rawhide renaming thing?
caillonthe moz guys do this though with the people involved in the release.  e.g. rel-eng, qa, engineering, planning, etc.
f13tibbs: I haven't seen an update from gregdek on it yet.
wwoodsjwb_gone: because we want rawhide to be more stable and we want more people to use it
caillonwe figure out what we could do better with getting the next release out
nirikI suppose. I think it would be nice to get more community input... but yeah, a lessons learned post release for developers would be nice too.
bpepplejwb_gone: to be more consistent for one.
* jwb_gone sighs
caillonfwiw, i think that rawhide has already gotten a bad rap as the unstable thing
f13jwb_gone: because we want to stregthen the brand of rawhide, stop the confusion between rawhide vs development, etc..
tibbsSome of us need to request travel allowances early.  Governments move slowly, after all.
caillonwe might consider using a newer, cooler name
wwoodsI still think it would be cool if we named the releases at the *start* of the cycle
f13wwoods: we could certainly consider that.
dwmw2_BOSwith utf-8 in :)
nim-nimbpepple: I'm creating a fonts SIG do I need it approived somewhere?
wwoodsrather than just reusing "rawhide" as the codename for every release
f13wwoods: there is no real reason why we name it late, other than things are slower later and we cna get more eyes on the name and such.
wwoodsup until the point at which we bless it with a name
jeremywwoods: yeah.  we used to have the per-release internal codename (more of a project name) and then the external final codename
dwmw2_BOSwwoods: actually, giving it the name early and calling it that instead of rawhide does make a lot of sense
nottingwhat won, anyway?
f13notting: warewolf.
wwoodsf13: right, so we'd just have to double-step to name F9 early. and then
bpepplenim-nim: nope.
nim-nimbpepple: ok, just wanted to be sure
wwoodserr. and then we'd have an actual name for the thing we're developing. which might help branding a bit.
f13wwoods: does that mean we do away with "rawhide" all together then?
wwoodsbut I'm no marketing guy.
jeremynim-nim: thanks for stepping up to drive that, btw
caillonnotting: you thought kvass had a chance?
* caillon expected werewolf to landslide win
f13it was less than a 50% win
* bpepple agrees with caillon
nim-nimjeremy: thanks but I'll expect more victims to help soon
nottingcaillon: not really. but i figured i'd ask
wwoodsf13: I dunno? I suspect people will keep using it out of habit, but..
dwmw2_BOSf13: there were spoiled ballots? I thought there were only two choices?
caillonf13: as in 70/30?
wwoodsit'd certainly help if there was a "werewolf" version in bugzilla
tibbsI was pulling for a non-ascii name.
f13caillon: yeah, closer to 70/30
wwoodsand everyone knew the next release was going to be called "werewolf"
dwmw2_BOSok, rawhide installed.
f13wwoods: do you really want to use the codename in bugzilla?
caillonwwoods: it would really help if bugzilla would look at people's useragents and just maybe, if they are using one with a fedora version in it, actually pre-select it.
dwmw2_BOSsweepstake on how long before I have to disable selinux this time? :)
wwoodsf13: we already do! even worse, we use the same code name every time!
f13dwmw2_BOS: try using it in permissive mode, it stays on much longer and you identify problems.
dwmw2_BOSf13: yeah, good idea
wwoodscaillon: there's a lot of information we'd want to pull from the client machine, which is why I want to make a bugzilla client, based on python-bugzilla
f13wwoods: that's because rawhide is rawhide is rawhide...
bpeppleok, is there anything else, or should we wrap up?
wwoodscaillon: but, yeah
f13I think we should wrap.
dwmw2_BOStibbs: did you want to discuss... er.. something?
oh, arch exclusions
tibbsWell, there was some consternation over it earlier in the week.
Someone added an excludearch to a library package and didn't announce it anywhere.
That broke consumers of the library.
dwmw2_BOSwhat library package? What was the problem which led to the excludearch?
jimashocking, that.
tibbsI wasn't sure if it was remotely OK to add an excludearch to a package within a stable release.
dwmw2_BOShopefull there was at least a bug filed?
in general, it shouldn't be needed.
tibbsIt was one of Ralf's package; osgcal or something like it.
dwmw2_BOSstable updates aren't supposed to be massively intrusive and break stuff
tibbsWell, yeah.  I don't know the circumstances.
f13it hadn't been built for that arch prior to
so it wasn't as if a package went away.
dwmw2_BOSf13: ah, right
f13it just continued not to be there.
dwmw2_BOSfine, so it just shouldn't be an issue
f13so it's a bad example to a real issue
tibbsThen how did it break things that weren't broken before?
dwmw2_BOSpackages going _away_ when they used to build would be something we care about
bpeppledwmw2_BOS: agreed.
dwmw2_BOStibbs: probably because those things hadn't been built for ppc64 before either
niriktibbs: the packages hadn't been rebuilt since ppc64 appeared
dwmw2_BOSthey hadn't been rebuilt since we added ppc64 to Extrass
f13tibbs: it didn't actually break things, chris just blew up again like he always does
tibbsNow you know why I was somewhat reticent to discuss this.
dwmw2_BOSand I've been a lot slower with the ppc64 ExcludeArch tracker than I am with the ppc one, because ppc64 userspace just isn't interesting, for the most part.
anyway, the best answer is for all affected packages to file a bug, put them on the ExcludeArch tracker
and forget it until someone makes osgcal build
bpeppletibbs: anything else on this?
bpeppleok, let's wrap up then.
* 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!