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.
mmcgrath notes dgilmore is on a train and probably won't be around.
notting is here
* spot is here
abadger1999 sits in the bleachers
warren here
jeremy is mostly here
jeremyf13 says he's missing the meeting and to punt his stuff to after the new year
bpepplejeremy: ok.
--- bpepple has changed the topic to: MISC - automate the mailings of multiarch conflicts, it is hard to test for people without biarch computers - from Patrice Dumas
bpepplePatrice wanted us to discuss this.
nirikI think nagmail would be fine if someone can set it up...
warrenand nagmail must be individual
nottingthe problem is automating the checks
bpepplenirik: agreed.  I think it's a fine idea, we just need someone to implement it.
tibbsDo we have automatic detection of the conflicts, though?
nirikcan we get mdomsch to add a check to the mass rebuilds?
tibbsIs it more than "install everything; see what conflicts"?
bpeppletibbs: didn't jeremy write a script to detect them?
nirikyeah, there is a script...
jeremyyes, there is a script
it just need ssomeone to run it
warrenmight one of the serverbeach boxes (or VM there) be useful for this?
* nirik wonders if we shouldn't try and get a QA server setup... run this, run source check, run anything else thats automated qa tasks?
jeremywarren: the problem is they don't have easy access to all the packages
jeremyyou don't want to have sync all of the bits across the 'net to do things like this really
nirikyeah, local mirror needed.
nottingnirik: realistically, there's a lot of stuff we should be checking post-build
bpepplenotting: definitely.
tibbsOne thing at a time, though.
nirikI might be able to look over the holiday break at making a local mirror and tests against it...
nottingyeah, i'm just saying rather than create another one-off, do we want to set up a framework for these sorts of things
nirikit shouldn't be hard to script once there is a local mirror to hit against.
tibbsI have a local mirror already set up, and some fast machines.
nirikyeah, thats why I was wondering if we shouldn't look at making a QA box somewhere
warrenwould broken dep tests be for both stable + updates (and testing?) and rawhide?
is anyone still here/
* jeremy just doesn't really know what fesco as a group can do about this. we can say "yeah, that sounds great", but someone still has to actually *do* it
nirik nods at jeremy.
bpepplejeremy: +10000
I think we need to ask for help from the mailing lists on implementing post-build checking.
nirikI'd be happy to work on it... should I ask Infrastructure if there is any resource/good place for a qa machine that needs to run tests against packages?
jeremynirik: can't hurt
(not that I know of any spare resources right now)
bpeppleok, I'll mention in the meeting summary that we agree that this is a good idea, but that someone is needed to implement it.
tibbsIf someone feeds me code, I can provide the resources until we can get in-house machines.
niriktibbs: would you have a machine with local mirror access we could try and test scripts on?
cool. I can try and whip up some things for multiarch at least.
tibbsYeah, machines are no problem for me.
bpeppleok, anything else? or should we move on?
nirikmove on
--- bpepple has changed the topic to: Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy
bpepplehave you had a chance to look at this at all?
warrenWould a compat package have made the transition of openldap and openssl a lot easier?
(live with compat for 2 weeks, remove it)
jeremybpepple: sadly, no
bpepplejeremy: totally understandable with you starting up school.
jeremywarren: a little.  it also would have made it so that people wouldn't have done anything
jeremybpepple: yeah, been trying to finish up high priority pre-beta things as I'm not going to have much time in january
nirikyeah, I expect it would have still resulted in breakage after the compat was removed.
bpepplejeremy: maybe we can have someone else run with this, since your probably going to be pretty busy in the next few months.
tibbsYeah, I don't see this as a real problem early in the cycle.
nottingwell... if we had someone doing scripted mass rebuilds, this would have helped
tibbsCloser to Test1, though, and I think we'd have had a real problem.
jeremyif someone else wants to run with it, they can feel more than free.  and I'll be glad to comment :-)
nottingbut it doesn't help with encouraging people to do rebuilds on their own
tibbsIt didn't take us long to get everything built that would build, but several problem had (and still have) real problems.
Erm, "several packages"
jeremya few of which still need to be built :)
bpeppledoes anyone want to work on the compat-packages draft?
* bpepple expects to hear crickets. ;)
tibbsI hate to say it, but you could always punt to FPC.
warrenwe need to be very anti-compat package
bpepplewarren: I tend to feel the same way also.
warrenit should be a huge PITA to get approval to introduce a compat package
tibbsSo, how huge?
Must go through FESCo?
warrenFESCo needs to approve a compat package on an individual basis
that should be high enough of a hurdle
some of the idea for compat packages is easing the burden for things *not* in fedora
do we care about those?
nottingpick-your-isv-software here
notting, what if we provide only runtime, not -devel
notting, discourages buliding against it
nottingthat's how we've normally done it
warrenhow do we draw the line of what is worthwhile to ship as compat and what is not?
python(oldversion for zope)?
nirikno on that case, as the maintainer is against it. ;)
nottingi'd be more worried about libraries used by third-party apps, (openssl, etc)
warrenIsn't that arbitrary?  We provide compat libs for arbitrary binary-only apps but not a FOSS one?
DgilmorebbWarren what about opera. It needs compat-c++
nottingright, we've always shipped compat-libstdc++
warrenWe provide compat libs for arbitrary binary-only apps but not a FOSS one?
Seems a little mixed up.
spotFWIW, i think the meat of Jeremy's proposal is enough of a bar for compat packages: If there is a willing maintainer and the maintainer of the non-compat version signs off on it, its OK.
warrenand discourage building against the compat version?
i don't think we need more bureaucracy than that.
tibbsDo we need tracker bugs for builds against compat packages?
spottibbs: thats a good idea
DgilmorebbWe should not be police
bpepplespot: yeah, the less bureaucracy the better.
tibbsAnd do we need some guidelines for how many releases the compat packages should be kept around for?
spotdo we need to? if there is a willing maintainer, then why not let them stay?
tibbsWell, the prevailing attitude in the discussion until recently was that we wanted to limit them as much as possible.
* spot isn't opposed to reviewing them after a set number of releases (maybe after each release) to determine if they are still useful
spotbut i don't think we want to do a "2 releases and its gone"
tibbsCan we all agree that we don't want to carry then around if nothing needs them?
* spot nods
nottingnothing... in fedora? in existence?
nirikalthough if they are for 3rd party junk it's hard to tell.
spotif the maintainer can't present a compelling case for its inclusion, either of Fedora bits or other bits
then it goes
bpepplespot: +1
ok, how about I work on tweaking jeremy's compat policy based on some of the discussion here over the holiday's, and try to have something to present here after the New Year.
spotthe tracker bugs will help us track the Fedora dependant packages
spotbpepple: sounds good to me.
abadger1999My only complaint about the policy is that it only addresses the easy question -- has a willing owner, primary package owner agrees.  It's pretty much common sense.
jeremybpepple: sounds good to me
tibbsPeople could note in the tracker bugs which non-Fedora applications need the compat package so we could at least have some record of them.
abadger1999What do you do in the hard case?  Someone wants a compat package but primary package owner doesn't?
bpeppleabadger1999: They bring it to FESCo to decide.
abadger1999k.  Add a sentence and that's fine.
bpeppleabadger1999: cool.  anything else? or should we move on?
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleok, anything else people wish to discuss? floor's open.
nirikare we going to have a fesco meeting and/or "talk to fesco" session at fudcon?
bpepplehow many members of fesco are going to be there?
* jeremy is not going to be there
nirik just got his flight/hotel info... will be there.
notting will
spot will be present
bpeppleif a majority of member are there, it probably makes sense to get together like we did at the last FUDCon.
tibbsI'll be there.
* Dgilmorebb will be there
warrenI will be at fudcon
* bpepple won't be/
nottingwe can certainly conf people in
at least if we're in the RH office. dunno what ncsu uses for phone conf
tibbsOne problem with those meetings is that we have no log.
warrenIt can be both voice with real-time IRC summaries
tibbsI recall some annoyance that we met last fudcon but had no independent record of the meeting.
DgilmorebbWe have it we should use it
tibbsBTW, I'm making my way through the chosen merge reviews.
bpeppleok, so I think we can plan on having a FESCo meetup at FUDCon, the logistics just need to be worked out.
bpeppletibbs: yeah, I saw your tracker bugs being opened earlier.
ok, anything else? or should we call it quits for today?
tibbsNothing from me.
* nirik has nothing.
warrennotting, there is one trouble with asterisk
notting, due to the time delay, it is VERY confusing to both hear someone next to you and their delayed voice in a headset
anyway, that's all.
* 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!
DgilmorebbWarren we should have a speaker phone that we use for the prole there

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!