FESCo-2007-09-27

bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
bpeppleHi everybody; who's around?
*jeremy is here
*tibbs here
*spot is heah
*f13 present
*warren here
*c4chris is here
*nirik is here.
bpeppleok, we can probably get started.
---bpepple has changed the topic to: FESCO-Meeting -- MISC -- http://fedoraproject.org/wiki/RahulSundaram/WhyUpstream - all
bpepplemether wanted us to look at this.
f13and do what exactly with it?
bpepplebpepple: I believe he was looking for us to ratify it, though I'm not sure it's necessary.
nottingi'm uncomfortable with mandating 'upstream if not one of these exceptions'. i don't think we a) will really be able to quantify all the situations where an exception may be needed b) want to be in the business of approving/disproving exceptions
warrennotting, +1
*dgilmore is here
f13notting: +1
tibbsI didn't see anything factually incorrect when I read through it, but I agree with notting .
tibbsThe "Why Upstream" section is a nice summary of why we want to work with upstream.  I'd be happy if it stopped there.
f13so everything but the Exceptions section seems fine to me.
bpepplef13: agreed.  maybe we could have mether drop that section.
tibbsThis isn't intended to be some sort of packaging guideline, is it?  With people going to through and asking "did you upstream that patch yet"?
methermy idea behind doing this was to give packagers esp new ones some sort of best practices guidelines
dgilmorethe exceptions part while it pretty much makes sense,  we dont want to be police.
f13I thought it would just so somewhere in the "what fedora is about" documents.
methernot a strict interpretation of what is necessary or not
dgilmorewe can not force anyone to upstream things  we can only encourage it
tibbsYes, because of the simple fact that we can't force upstream to take any of our patches.
dgilmoreindeed
*jwb is here
*nirik agrees
jwband conversation has died...
bpeppleare there any other thoughts on mether's proposal?
f13well, wtf are we supposed to put it
f13once we agree on the content?
bpepplef13: maybe somewhere in the users section of the PackageMaintainers page?
dgilmoref13: somewhere that deals with maintaining packages
*dwmw2 arrives
bpepplepossibly the resources section, though that is pretty over-loaded already.
dwmw2what notting said. Let the kernel maintainers judge exceptions like they always have
dgilmoredwmw2: thats not what we are talking about
f13how about this, we put it somewhere in the About Fedora pages, under a "Why we stress upstream"
dgilmoref13: sounds fine
f13and then we can wikilink to that from wherever else in the wiki it makes sense.
bpepplef13: works for me.
dwmw2dgilmore: ah, ok. I keep forgetting that userspace exists. :)
*c4chris likes the document except the Exceptions part
niriksounds fine to me. Do we want to ask removal/re-wording of exceptions?
jwbyes
dgilmoredwmw2: :)
f13maybe change it to say "Some examples of when upstreaming is not possible" nad then drop the final sentance
f13sentence
bpepplef13: +1
tibbs+1
nirik+1
dgilmore+1
dwmw2+1
c4chris+1
bpeppleok, that's more than half of fesco.
jwb+1
bpepplemether: anything else you want to add? Or should we move on?
caillondwmw2: +1
metherbpepple: works for me
bpepplemether: great, thanks!
---bpepple has changed the topic to: FESCO-Meeting -- MISC -- transition plan for switching devel to rawhide - warren
jwbi don't understand this topic at all
c4christhat's two of us, then :)
tibbsWe want to call it rawhide, right?
bpepplejwb: this was something we talked about a few meetings back.
bpeppletibbs: correct.
tibbsBugzilla still calls it "devel", for one.
dwmw2we already call it rawhide
dgilmorejwb: we will use rawhide to revert to the development branch  everywhere officially
nirikin some places it's devel, and some places rawhide. People get confused.
dwmw2please, no more gratuitous renaming of stuff
jwbdgilmore, s/revert/refer?
dgilmores/revert/refer/
dwmw2'devel' is better for people who aren't familiar with Fedora.
jwbok
cailloni agree with dwmw2 on this.  not important enough to change things.  i'm fine with cvs being in project/devel and don't care to have to recheck out everything to see project/rawhide
c4chrisold lore can be fun ...
nottingwhat? changing cvs?
caillonif we're talking about "everywhere" that's one place that would have to change
c4chrisI think we've had enough changes for a while
c4chrisinterested parties can ask, and that starts a dialogue of some sort
*nirik would prefer everything was rawhide, but it's not probibly worth all the hassle to change it.
bpepplec4chris: +1
jwbi see no benefit here
nottingchanging cvs is just wrong
caillonnotting: unless we do something useful like move to hg/git/whatever
caillonbut that's a different discussion :)
bpeppleIs anyone interested in pursuing this?  Otherwise I think we can probably move on then.
*caillon takes that to be a no
*bpepple agrees with caillon
wwoodsSince we so commonly refer to rawhide as.. well, as rawhide
wwoodswe'll probably change the Bugzilla version name
jwbfor what reason?
cailloni'm fine with that.  does that warrant fesco involvement?
wwoodsbut CVS is developer-focused, and the devs can Figure It Out
nirikcan you have it just be an alias for 'devel' ? have both show up?
wwoodscaillon: not really. just being informative.
caillonwwoods: okay :)
wwoodsnirik: I'm kind of trying to have less versions in bugzilla, not more
nottingthe only other place to maybe change is the tree name in the repos/web site
nirikwwoods: true.
nirikor 'development(rawhide)' or something... details tho... shall we move on?
caillonaye
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
wwoodsright, having rawhide actually called "rawhide" in the repo names would be helpful, since we all call it rawhide all the dang time
c4chrisdidn't see a releng report lately...
wwoodsbut yes. moving on.
tibbsI don't think FESCo covered the Python Eggs proposal submitted by FPC last week.
f13we haven't really done much deciding, mostly just working
tibbshttp://fedoraproject.org/wiki/PackagingDrafts/PythonEggs
c4chrisf13: k
tibbsThis was approved by FPC but sort of got lost in the confusion while I was ill.
bpeppletibbs: Yeah, I don't think anyone was aware the FPC had submitted that.
lkundrakI need some more opinions about http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft Basically it is request for requirement to approve security updates by Security Response team to ensure quality
poelcatc4chris: after they waste an hour trying to figure out why? :)
tibbsbpepple: Toshio did the summary for that meeting and sent it to fedora-devel-list.
bpepplemost of got lost in the mountain of mail I got last week. ;)
---bpepple has changed the topic to: FPC Proposal: http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs
nirik+1 on pythoneggs... seems fine.
c4chris+1
jwb0.  i don't know anything about eggs but i trust the FPC
tibbs+1 (didn't get to vote in FPC)
c4chrispoelcat: I'm not sure why what ?
caillon0 for me, too
dgilmore+1  i know there are a few projects that only distriute as eggs
bpepple+1 here also.
poelcatc4chris: sorry... my backscroll was stuck... was referring to your comment about people being confused about rawhide vs. development can ask/start a discussion
c4chrispoelcat: oh, I see... yes, that's part of the fun :)
notting0
poelcatc4chris: s/fun/frustration ... at least it was for me in the beginning
jwbi need to head to a real-life meeting
*jwb &
bpeppleok, I see five '+1' and three '0'.
f13+1
dwmw20
bpepplebut more importantly I don't see any '-1', so I think we can consider this approved.
f13worksforme
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleAnything else people want to discuss?
lkundrak19:13 < lkundrak> I need some more opinions about http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft Basically it is request for requirement to  approve security updates by Security Response team to ensure quality
lkundrakthis
---bpepple has changed the topic to: http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft
nirikthis will need: bodhi changes, and enough people in security_response to handle the load without delaying things.
lkundrakthere are enough people for that now. plus we can ensure timely reaction by having a timeout for security team reaction
lkundraklike 2 days without approval/disapproval = approval
lmackenworks for me.. it's a pretty trivial bodhi change
caillonlkundrak: you said there were a number of problems, especially 2.  were there others that should be addressed?
tibbsDo update pushes happen on any type of schedule?
lmackentibbs: nope
niriktibbs: not currently I don't think.
caillonlkundrak: or is it just those 2 problems?
c4chrisIIUC, you'd like the people doing the push approval in bodhi to do additional checking ?
lkundrakcaillon: basically just these 2
lkundrakc4chris: just add one more approval to the regular testing
c4chrisfrom a secutity team member ?
lkundrakyes
caillonlkundrak: how many people are in security_response currently?
lkundrakcaillon: http://fedoraproject.org/wiki/Security/ResponseTeam
caillonand also, how many non-RH employees?
*nirik doesn't think that group exists.
lmackenFC6 already does this, except it requires approval from the RH security team.  This proposal gives more responsibility to the fedora security team
lmackenthe group is security_respons afaik
lkundrakcaillon: though I'd expect mostly thoger and me to care about those, as we do work in tracking. probably also nirik
lmackenit's missing a letter or two
nirikah, ok.
nirikthere are 4 people in that group
nirikhttps://admin.fedoraproject.org/accounts/dump-group.cgi?group=security_respons&format=plain
caillonhow many hours of coverage does that get us?  if not 24/7 then i'm not comfortable with it.
lmacken(as opposed to 1 person responsible for signing/pushing updates)
lmackensecurity team is not the bottleneck here.
caillon(or close to 24/7)
lkundrakcaillon: probably 8x5
*nirik would be happy to help if it's just checking security marked packages against CVE... I keep up on the security stuff pretty well...
lkundraknirik: each security update should have a cve
jeremysimple way to address caillon's concern -- make it so pushers/signers can also mark as "okay" and then if it's critical, the pusher/signer can just do it
caillonlkundrak: we should add some emea/apac people to that list then.  why aren't people like mjcox/holtmann in the group?  that adds another 8 hours
niriklkundrak: right. and it should be the right one too as a bonus. ;)
lkundrakjeremy: sounds file
lkundrakcaillon: mjcox woudn't have time for that, holtmann left RH
lkundrakjeremy: *fine
jeremy(we should still have more people to help out, but that will avoid that being a blocking case ever... and then the pushers/signers are just aware and _try_ to get security response involved but doesn't have to block on them)
caillonokay
niriksounds good.
caillonI am in favor of this proposal in general
caillonand agree the sec team should be on these bugs
bpepplecaillon: agreed.
caillonjust don't want to get into a place where a critical is stuck because nobody is awake
f13me too
caillonbecause I have had that happen in the past before
caillonfor FC6
caillonand under
tibbsPerhaps then we need to be able to wake people up.
c4chrisfine with me
*f13 isn't wearing a pager to push updates.
lmackenadmin.fp.o/pager ;)
jeremytibbs: infrastructure has some capability for that, it could be extended for more people
tibbsThat's not just an empty muse; I'm on the list of security people.
jeremywe really need to get the signing stuff going as then we can have more signers/pushers.  which is the current bottleneck.  (well, plus mashing takes a while)
caillontibbs: I have the home/cell phone numbers for bressers which wakes him usually but not sure how many do and how many he wishes to dish that out to :)
lkundrakcaillon: basically, I would say it's better when update waits a day or two than when it comes out in horrible state (lacking bugzilla/cve references, with a comment "Sec FIX")
caillonlkundrak: in some cases yes.  firefox gets high visibility though and i would not necessarily say that is the case.
caillon(although i've done this enough so they will almost never go out with missing info)
nirikI think between more security_respons folks, and allowing signers/pushers to check/allow security updates we should be ok, or at least not worse off than now.
lkundrakcaillon: there are not many updates like that. for firefox the security response usually know in advance that it is coming out. you know.
f13jeremy: indeed, silly things like F8 keep getting in the way of my signing server work (:
jeremyf13: I know, I'm just saying that adding security response isn't going to be the bottleneck here so let's just do it :)
caillonlkundrak: i know.  but sometimes there are other issues which means it gets delayed to after hours
caillonanyway
f13jeremy: I agree
caillon+1 on this in general
jeremy+1
nirik+1 here.
f13+1
tibbs+1
notting+1
c4chris+1
lmackenlkundrak: you sure are putting me to work this week
lkundrakthanks
bpepple+1
caillonokay, that's 7 +1 (since bpepple missed it)
caillon8
bpepplecaillon: thanks.
dgilmore+1
bpeppleok, anything else? Or should we move on?
dgilmoremove on
nirikI guess bressers is the one to ping to add to the security_respons group then?
cailloni'd say so
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
lkundraknirik: yes
bpeppleanything else people want to discuss this week before wrapping up?
*nirik can't think of anything off hand.
*c4chris has naught
bpepplecaillon: what's the status of xulrunner? (I've been gone most of the week)
tibbsWhen should we raise the merge review issue again?
f13tibbs: probably start of F9
f13although I think F9 conflicts pretty horribly with RHEL5.2 schedule
tibbsIs there a release that doesn't conflict in some way with the RHEL schedule?
bpeppletibbs: probably not. ;)
f13tibbs: F10 may fare better
spotcaillon: are we going to get firefox built against xulrunner? soon? :)
nirikf13: did you have an updated list of things that need buildid/ppc rebuilds?
f13nirik: I'll spin one up now.
dwmw2spot: and more to the point, will it work when we do? :)
f13spot: not for F8
tibbsPerhaps a better question is whether there's ever a lull where we can try to agressively deal with some of the merge reviews.  I suspect there isn't.
f13spot: nothing will be built against xul for F8
f13spot: xul made itself unsuitable to build things against it.
tibbsI thought xulrunner was the holy grail.
jeremyI don't think there's a lull... so it's going to be a matter of just continuing to chip away
niriktibbs: we might try at a fudcon again, but thats not going to get response from maintainers any better.
f13tibbs: FF upstream isn't ready to switch to xul.
jeremyand I'll try to mention some "encouragement" to appropriate people as well
bpeppleok, I think we can wrap up for this week.
tibbsAs I wrote on #fedora-devel, if a particular maintainer feels they have time to deal with some merge reviews, I'll try to work on them.
nirikwow... thats the first time in a while we have finished on time. ;)
bpepplenirik: yeah, been a long time. ;)
*bpepple will end the meeting in 60
c4chriswoot
*bpepple will end the meeting in 30
*bpepple will end the meeting in 15
niriktibbs: yeah, I would be happy to do likewise. I should try and work on some more reviews here. Might have time this weekend.
bpepple-- MARK -- Meeting End

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