bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
---|---|---|
bpepple | Hi everybody; who's around? | |
*jeremy is here | ||
*tibbs here | ||
*spot is heah | ||
*f13 present | ||
*warren here | ||
*c4chris is here | ||
*nirik is here. | ||
bpepple | ok, we can probably get started. | |
---bpepple has changed the topic to: FESCO-Meeting -- MISC -- http://fedoraproject.org/wiki/RahulSundaram/WhyUpstream - all | ||
bpepple | mether wanted us to look at this. | |
f13 | and do what exactly with it? | |
bpepple | bpepple: I believe he was looking for us to ratify it, though I'm not sure it's necessary. | |
notting | i'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 | |
warren | notting, +1 | |
*dgilmore is here | ||
f13 | notting: +1 | |
tibbs | I didn't see anything factually incorrect when I read through it, but I agree with notting . | |
tibbs | The "Why Upstream" section is a nice summary of why we want to work with upstream. I'd be happy if it stopped there. | |
f13 | so everything but the Exceptions section seems fine to me. | |
bpepple | f13: agreed. maybe we could have mether drop that section. | |
tibbs | This 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"? | |
mether | my idea behind doing this was to give packagers esp new ones some sort of best practices guidelines | |
dgilmore | the exceptions part while it pretty much makes sense, we dont want to be police. | |
f13 | I thought it would just so somewhere in the "what fedora is about" documents. | |
mether | not a strict interpretation of what is necessary or not | |
dgilmore | we can not force anyone to upstream things we can only encourage it | |
tibbs | Yes, because of the simple fact that we can't force upstream to take any of our patches. | |
dgilmore | indeed | |
*jwb is here | ||
*nirik agrees | ||
jwb | and conversation has died... | |
bpepple | are there any other thoughts on mether's proposal? | |
f13 | well, wtf are we supposed to put it | |
f13 | once we agree on the content? | |
bpepple | f13: maybe somewhere in the users section of the PackageMaintainers page? | |
dgilmore | f13: somewhere that deals with maintaining packages | |
*dwmw2 arrives | ||
bpepple | possibly the resources section, though that is pretty over-loaded already. | |
dwmw2 | what notting said. Let the kernel maintainers judge exceptions like they always have | |
dgilmore | dwmw2: thats not what we are talking about | |
f13 | how about this, we put it somewhere in the About Fedora pages, under a "Why we stress upstream" | |
dgilmore | f13: sounds fine | |
f13 | and then we can wikilink to that from wherever else in the wiki it makes sense. | |
bpepple | f13: works for me. | |
dwmw2 | dgilmore: ah, ok. I keep forgetting that userspace exists. :) | |
*c4chris likes the document except the Exceptions part | ||
nirik | sounds fine to me. Do we want to ask removal/re-wording of exceptions? | |
jwb | yes | |
dgilmore | dwmw2: :) | |
f13 | maybe change it to say "Some examples of when upstreaming is not possible" nad then drop the final sentance | |
f13 | sentence | |
bpepple | f13: +1 | |
tibbs | +1 | |
nirik | +1 | |
dgilmore | +1 | |
dwmw2 | +1 | |
c4chris | +1 | |
bpepple | ok, that's more than half of fesco. | |
jwb | +1 | |
bpepple | mether: anything else you want to add? Or should we move on? | |
caillon | dwmw2: +1 | |
mether | bpepple: works for me | |
bpepple | mether: great, thanks! | |
---bpepple has changed the topic to: FESCO-Meeting -- MISC -- transition plan for switching devel to rawhide - warren | ||
jwb | i don't understand this topic at all | |
c4chris | that's two of us, then :) | |
tibbs | We want to call it rawhide, right? | |
bpepple | jwb: this was something we talked about a few meetings back. | |
bpepple | tibbs: correct. | |
tibbs | Bugzilla still calls it "devel", for one. | |
dwmw2 | we already call it rawhide | |
dgilmore | jwb: we will use rawhide to revert to the development branch everywhere officially | |
nirik | in some places it's devel, and some places rawhide. People get confused. | |
dwmw2 | please, no more gratuitous renaming of stuff | |
jwb | dgilmore, s/revert/refer? | |
dgilmore | s/revert/refer/ | |
dwmw2 | 'devel' is better for people who aren't familiar with Fedora. | |
jwb | ok | |
caillon | i 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 | |
c4chris | old lore can be fun ... | |
notting | what? changing cvs? | |
caillon | if we're talking about "everywhere" that's one place that would have to change | |
c4chris | I think we've had enough changes for a while | |
c4chris | interested 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. | ||
bpepple | c4chris: +1 | |
jwb | i see no benefit here | |
notting | changing cvs is just wrong | |
caillon | notting: unless we do something useful like move to hg/git/whatever | |
caillon | but that's a different discussion :) | |
bpepple | Is 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 | ||
wwoods | Since we so commonly refer to rawhide as.. well, as rawhide | |
wwoods | we'll probably change the Bugzilla version name | |
jwb | for what reason? | |
caillon | i'm fine with that. does that warrant fesco involvement? | |
wwoods | but CVS is developer-focused, and the devs can Figure It Out | |
nirik | can you have it just be an alias for 'devel' ? have both show up? | |
wwoods | caillon: not really. just being informative. | |
caillon | wwoods: okay :) | |
wwoods | nirik: I'm kind of trying to have less versions in bugzilla, not more | |
notting | the only other place to maybe change is the tree name in the repos/web site | |
nirik | wwoods: true. | |
nirik | or 'development(rawhide)' or something... details tho... shall we move on? | |
caillon | aye | |
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
wwoods | right, having rawhide actually called "rawhide" in the repo names would be helpful, since we all call it rawhide all the dang time | |
c4chris | didn't see a releng report lately... | |
wwoods | but yes. moving on. | |
tibbs | I don't think FESCo covered the Python Eggs proposal submitted by FPC last week. | |
f13 | we haven't really done much deciding, mostly just working | |
tibbs | http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs | |
c4chris | f13: k | |
tibbs | This was approved by FPC but sort of got lost in the confusion while I was ill. | |
bpepple | tibbs: Yeah, I don't think anyone was aware the FPC had submitted that. | |
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 | |
poelcat | c4chris: after they waste an hour trying to figure out why? :) | |
tibbs | bpepple: Toshio did the summary for that meeting and sent it to fedora-devel-list. | |
bpepple | most 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 | |
jwb | 0. i don't know anything about eggs but i trust the FPC | |
tibbs | +1 (didn't get to vote in FPC) | |
c4chris | poelcat: I'm not sure why what ? | |
caillon | 0 for me, too | |
dgilmore | +1 i know there are a few projects that only distriute as eggs | |
bpepple | +1 here also. | |
poelcat | c4chris: sorry... my backscroll was stuck... was referring to your comment about people being confused about rawhide vs. development can ask/start a discussion | |
c4chris | poelcat: oh, I see... yes, that's part of the fun :) | |
notting | 0 | |
poelcat | c4chris: s/fun/frustration ... at least it was for me in the beginning | |
jwb | i need to head to a real-life meeting | |
*jwb & | ||
bpepple | ok, I see five '+1' and three '0'. | |
f13 | +1 | |
dwmw2 | 0 | |
bpepple | but more importantly I don't see any '-1', so I think we can consider this approved. | |
f13 | worksforme | |
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
bpepple | Anything else people want to discuss? | |
lkundrak | 19: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 | |
lkundrak | this | |
---bpepple has changed the topic to: http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft | ||
nirik | this will need: bodhi changes, and enough people in security_response to handle the load without delaying things. | |
lkundrak | there are enough people for that now. plus we can ensure timely reaction by having a timeout for security team reaction | |
lkundrak | like 2 days without approval/disapproval = approval | |
lmacken | works for me.. it's a pretty trivial bodhi change | |
caillon | lkundrak: you said there were a number of problems, especially 2. were there others that should be addressed? | |
tibbs | Do update pushes happen on any type of schedule? | |
lmacken | tibbs: nope | |
nirik | tibbs: not currently I don't think. | |
caillon | lkundrak: or is it just those 2 problems? | |
c4chris | IIUC, you'd like the people doing the push approval in bodhi to do additional checking ? | |
lkundrak | caillon: basically just these 2 | |
lkundrak | c4chris: just add one more approval to the regular testing | |
c4chris | from a secutity team member ? | |
lkundrak | yes | |
caillon | lkundrak: how many people are in security_response currently? | |
lkundrak | caillon: http://fedoraproject.org/wiki/Security/ResponseTeam | |
caillon | and also, how many non-RH employees? | |
*nirik doesn't think that group exists. | ||
lmacken | FC6 already does this, except it requires approval from the RH security team. This proposal gives more responsibility to the fedora security team | |
lmacken | the group is security_respons afaik | |
lkundrak | caillon: though I'd expect mostly thoger and me to care about those, as we do work in tracking. probably also nirik | |
lmacken | it's missing a letter or two | |
nirik | ah, ok. | |
nirik | there are 4 people in that group | |
nirik | https://admin.fedoraproject.org/accounts/dump-group.cgi?group=security_respons&format=plain | |
caillon | how 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) | |
lmacken | security team is not the bottleneck here. | |
caillon | (or close to 24/7) | |
lkundrak | caillon: 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... | ||
lkundrak | nirik: each security update should have a cve | |
jeremy | simple 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 | |
caillon | lkundrak: 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 | |
nirik | lkundrak: right. and it should be the right one too as a bonus. ;) | |
lkundrak | jeremy: sounds file | |
lkundrak | caillon: mjcox woudn't have time for that, holtmann left RH | |
lkundrak | jeremy: *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) | |
caillon | okay | |
nirik | sounds good. | |
caillon | I am in favor of this proposal in general | |
caillon | and agree the sec team should be on these bugs | |
bpepple | caillon: agreed. | |
caillon | just don't want to get into a place where a critical is stuck because nobody is awake | |
f13 | me too | |
caillon | because I have had that happen in the past before | |
caillon | for FC6 | |
caillon | and under | |
tibbs | Perhaps then we need to be able to wake people up. | |
c4chris | fine with me | |
*f13 isn't wearing a pager to push updates. | ||
lmacken | admin.fp.o/pager ;) | |
jeremy | tibbs: infrastructure has some capability for that, it could be extended for more people | |
tibbs | That's not just an empty muse; I'm on the list of security people. | |
jeremy | we 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) | |
caillon | tibbs: 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 :) | |
lkundrak | caillon: 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") | |
caillon | lkundrak: 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) | |
nirik | I 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. | |
lkundrak | caillon: there are not many updates like that. for firefox the security response usually know in advance that it is coming out. you know. | |
f13 | jeremy: indeed, silly things like F8 keep getting in the way of my signing server work (: | |
jeremy | f13: I know, I'm just saying that adding security response isn't going to be the bottleneck here so let's just do it :) | |
caillon | lkundrak: i know. but sometimes there are other issues which means it gets delayed to after hours | |
caillon | anyway | |
f13 | jeremy: I agree | |
caillon | +1 on this in general | |
jeremy | +1 | |
nirik | +1 here. | |
f13 | +1 | |
tibbs | +1 | |
notting | +1 | |
c4chris | +1 | |
lmacken | lkundrak: you sure are putting me to work this week | |
lkundrak | thanks | |
bpepple | +1 | |
caillon | okay, that's 7 +1 (since bpepple missed it) | |
caillon | 8 | |
bpepple | caillon: thanks. | |
dgilmore | +1 | |
bpepple | ok, anything else? Or should we move on? | |
dgilmore | move on | |
nirik | I guess bressers is the one to ping to add to the security_respons group then? | |
caillon | i'd say so | |
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
lkundrak | nirik: yes | |
bpepple | anything else people want to discuss this week before wrapping up? | |
*nirik can't think of anything off hand. | ||
*c4chris has naught | ||
bpepple | caillon: what's the status of xulrunner? (I've been gone most of the week) | |
tibbs | When should we raise the merge review issue again? | |
f13 | tibbs: probably start of F9 | |
f13 | although I think F9 conflicts pretty horribly with RHEL5.2 schedule | |
tibbs | Is there a release that doesn't conflict in some way with the RHEL schedule? | |
bpepple | tibbs: probably not. ;) | |
f13 | tibbs: F10 may fare better | |
spot | caillon: are we going to get firefox built against xulrunner? soon? :) | |
nirik | f13: did you have an updated list of things that need buildid/ppc rebuilds? | |
f13 | nirik: I'll spin one up now. | |
dwmw2 | spot: and more to the point, will it work when we do? :) | |
f13 | spot: not for F8 | |
tibbs | Perhaps 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. | |
f13 | spot: nothing will be built against xul for F8 | |
f13 | spot: xul made itself unsuitable to build things against it. | |
tibbs | I thought xulrunner was the holy grail. | |
jeremy | I don't think there's a lull... so it's going to be a matter of just continuing to chip away | |
nirik | tibbs: we might try at a fudcon again, but thats not going to get response from maintainers any better. | |
f13 | tibbs: FF upstream isn't ready to switch to xul. | |
jeremy | and I'll try to mention some "encouragement" to appropriate people as well | |
bpepple | ok, I think we can wrap up for this week. | |
tibbs | As 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. | |
nirik | wow... thats the first time in a while we have finished on time. ;) | |
bpepple | nirik: yeah, been a long time. ;) | |
*bpepple will end the meeting in 60 | ||
c4chris | woot | |
*bpepple will end the meeting in 30 | ||
*bpepple will end the meeting in 15 | ||
nirik | tibbs: 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!