| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| * jds2001 is in the peanut gallery | ||
| dwmw2_AVF | mmm | |
|---|---|---|
| peanuts | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
| Hi everybody; who's around? | ||
| * warren here | ||
| tibbs here | ||
| nirik here | ||
| caillon | not really here... | |
| may be able to vote when votes are called though | ||
| (if someone pings me) | ||
| dwmw2_AVF | fish | |
| warren | caillon, is your vote for sale? | |
| * f13 | ||
| jwb is 30% here | ||
| dwmw2_AVF has 100,000 Mongolian Tugrugs | ||
| dwmw2_AVF | caillon: will that buy your vote? | |
| caillon | warren, my price is probably too high. | |
| bpepple | ok, let's go ahead and get started. | |
| --- 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/2008-March/msg00995.html | ||
| caillon | dwmw2_AVF, and i'm guessing it's probably not enough ;) | |
| * notting is here | ||
| bpepple | FPC had proposals for Ocaml and tcl. any objections to them? | |
| f13 | no objections here. | |
| warren | no | |
| tibbs | no | |
| bpepple | none here either. | |
| dwmw2_AVF | caillon: about 100 merkinpesos | |
| ocaml packages require: ocaml | ||
| library packages, I mean | ||
| not ocaml of the same arch | ||
| * nirik is fine with the ocaml guidelines. | ||
| * bpepple notes that jeremy didn't have any objections either. | ||
| dwmw2_AVF | I think they should require ocaml of the _same_ arch. | |
| otherwise it's broken | ||
| other than that, fine,. | ||
| notting | "Rationale: OCaml does not offer binary compatibility between releases of the compiler (even between bugfixes)." | |
| wow, quality. | ||
| dwmw2_AVF | it's because of the way interprocedural optimisation happen, iirc. | |
| tibbs | Yeah, ocaml is rather messed up. | |
| dwmw2_AVF | if they fix it to require stuff of the correct arch, fine. Else, -1 broken. | |
| tibbs | dwmw2_AVF: How can you do arch-specific requires? | |
| RPM doesn't actually support that. | ||
| dwmw2_AVF | fix one of the rpm bugs on the multilib tracker :) | |
| or virtual provides | ||
| * dgilmore is here | ||
| tibbs | I can send it back to the submitter, I guess. | |
| f13 | does ocamel even get multilibbed? | |
| dwmw2_AVF | it has various libraries and accompanying devel subpackages | |
| nirik | main ocaml itself isn't multilib it seems like... but some ocaml packages are. | |
| f13 | so it doesn't do any automagic arch specific requires/provides like c libraries do? | |
| notting | f13: looks to be all hashes | |
| dwmw2_AVF | no | |
| and we don't get the core compiler in both versions either (nor -m32/-m64 support). | ||
| tibbs | There is some requires/provides magic, but those are turned on in the individual spec files. | |
| dgilmore | ocaml seems to be overly complex | |
| dwmw2_AVF | I think I'm about to be dragged out for food. I vote for sending this proposal back to have its multilib issues sorted out. | |
| tibbs | I will send a rejection message out to the submitter and fedora-packaging. | |
| f13 | yeah, seems like a trap | |
| dwmw2_AVF | I accidentally wrote a ppc64 back end for its compiler. It's _definitely_ complex :) | |
| notting | 'accidentally'? | |
| bpepple | tibbs: cool. thanks. | |
| tibbs | Do note also that these were merely alteration to existing ocaml guidelines. | |
| bpepple | tibbs: will do. | |
| tibbs | I don't think the original, accepted guidelines are any better on this issue. | |
| dgilmore | dwmw2_AVF: you should write a sparc64 one also :) | |
| tibbs | So we're basically rejecting good changes because the original document has something that someone doesn't like. | |
| Which is... kind of backwards. | ||
| dwmw2_AVF | I don't mind approving it with a "please improve it further" comment | |
| dgilmore | we can accept the fixes, but we should ask them to also go off and fix our issues | |
| dwmw2_AVF | if it's considered progress | |
| +0 | ||
| bpepple | dgilmore: +1 | |
| tibbs | I will make that note; we will present something to fesco after our next meeting, twelve days hence. | |
| bpepple | ok, anything else, or should we move on? | |
| bpepple | moving on...... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Bugzapper's Proposals - https://www.redhat.com/archives/fedora-test-list/2008-March/msg00425.html -- poelcat | ||
| bpepple | is poelcat about? | |
| poelcat | we are proposing some new changes to Fedora bug tracking which we think might be fairly disruptive | |
| so far we have received little to no feedback. we would like to give one more week for feedback | ||
| and then have FESCo approve next meeting so we can get started and finish by F9 GA. | ||
| jwb | it looked good to me at first glance | |
| bpepple | yeah, I read it last night, and it seemed reasonable. | |
| warren | We should get some feedback from ignorant RH engineers? | |
| jwb | huh? | |
| nirik | My only issue is that I think we will still be closing legit bugs due to lack of maintainer response, but not sure there is any better way to do things... so I am ok with the proposal. | |
| poelcat | warren: i've run it past RHEL eng managers | |
| warren | poelcat, ah | |
| ok then | ||
| bpepple | poelcat: so is there anything else you need us to do today for this? | |
| warren | Will this differentiate between NEEDINFO due to this process, and NEEDINFO created by someone else? | |
| nirik | it falls into the CADT model, but oh well. ;( | |
| poelcat | bpepple: no, just general awareness, initial concerns, and vote next week :) | |
| bpepple | ok, sounds good. | |
| if no one else has anything to add, we can probably move on. | ||
| poelcat | warren: yes and no... part of ExtremeMakeOver does tag NEEDINFO bugs | |
| for special identification | ||
| poelcat | bpepple: that's all from me | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features Completion - http://fedoraproject.org/wiki/Releases/9/FeatureList - poelcat | ||
| poelcat | we are this part of the feature cycle: http://fedoraproject.org/wiki/Features/Policy#freeze | |
| nirik | poelcat: oh, does the proposal ignore review requests and fearure requests? or ? | |
| poelcat | in the interest of time for today, for features are not at 100% done here: http://fedoraproject.org/wiki/Releases/9/FeatureList | |
| are there any that people know are obviouly NOT going to make it for Fedora 9? | ||
| nirik: right now it does not | ||
| wait flip that around | ||
| right now we are not proposing special treatment to features or review requests | ||
| rwmjones | sorry I missed all that & didn't understand the multilib problems. Any specific questions? | |
| dgilmore | Virtual Storage and Xen paravirt ops seem dubious | |
| * nirik doesn't see anything on the features list he knows won't make it... | ||
| poelcat | by tomorrow I will send nag mail to all feature owners (not at 100%) asking for a status update and whether their feature is testable for F9. | |
| at next week's meeting I'll bring forward the exception cases or where there has been no repsonse. | ||
| bpepple | dgilmore: yeah, we may need to check w/ dberrange to see what the status is of those. | |
| tibbs | The Xen stuff looks pretty huge and is only at 35%. | |
| notting | xen pvops for dom0 did not happen | |
| there is no dom0 kernel in rawhide | ||
| dgilmore | notting: so we should drop it? | |
| notting | (iirc) | |
| tibbs | Ah, dom0 is for F10. | |
| The F9-targeted bit is indicated at 80%. | ||
| warren | dom0 is totally unsupported on F9 by their announcement | |
| dgilmore | intresting | |
| so there will be no kernel-xen | ||
| for F-9 | ||
| nirik | there's always xenner too. ;) | |
| warren | just wait until somebody submits a package review for compat-kernel-xen | |
| nirik | kernel-xen in cvs is rebased against 2.6.25rc something... | |
| and hey, it's building now. | ||
| http://koji.fedoraproject.org/koji/buildinfo?buildID=42808 | ||
| dgilmore | notting: good to know | |
| nirik: even | ||
| bpepple | poelcat: so, is there anything we need to decide today, or do we need to wait until after your nag-mail? | |
| dgilmore | poelcat: so please stress in your email to Feature owners the importance that things need to get done and they need to update the wiki | |
| poelcat | bpepple: no; okay if I cc fesco on nag mails? | |
| bpepple | poelcat: yup. | |
| dgilmore | poelcat: that would be good | |
| * poelcat realizes we have a very short window before beta release :( | ||
| poelcat makes note for F10 to handle this a little better :) | ||
| poelcat | that is all | |
| bpepple | poelcat: great, thanks. | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | anything else people need to discuss? | |
| dgilmore | bpepple: i have nothing | |
| ivazquez | Did anyone decide anything re vcs-pkg? | |
| tibbs | What's vcs-pkg? | |
| ivazquez | http://vcs-pkg.org/ | |
| bpepple | ivazquez: not yet. I've only read the thread on fdo, and they move the discussion over to vcs-pkg mailing list, which I haven't had a chance to read yet. | |
| ivazquez | Fair enough. | |
| notting | sigh, more mailing lists that probably need policed | |
| bpepple | notting: yeah, I wouldn't have know about that vcs-pkg discussion, until ivazquez pointed me to it yesterday. | |
| ok, if there's nothing else we can probably wrap it up. | ||
| btw, sorry about the confusion about the start time today. | ||
| tibbs | Do we need to decide what we're going to do once and for all about DST? | |
| f13 | ivazquez: wha twere we supposed to decide on? | |
| ivazquez: I just have to read about it. | ||
| ivazquez | Whether or not the effort is worth pursuing. | |
| Or even thinking about, for that matter. | ||
| f13 | ivazquez: I'm going to look into it and see what happens | |
| notting | ivazquez: maybe i'm a cynic, but why do i see this heading down the road of the lsb and people who have nothing better to do than write standards doing standardizing on things that shouldn't be? | |
| ivazquez | That's why I'm passing it on to wiser people than I. | |
| dgilmore | historically we have always changed meeting time with DST id like to continue doing so | |
| f13 | dgilmore: but who's DST? | |
| bpepple | tibbs: I think we have decided it before, it's just a case of me not remembering to adjust for dst before sending out the agenda. | |
| dgilmore | f13: US DST | |
| bpepple | dgilmore: correct. I believe we decided that last year. | |
| nirik | well, US except for HI and AZ. ;) | |
| dgilmore | nirik: well yes since they dont bother | |
| jwb | i have something | |
| * nirik is +1 for just following DST in the US... would be good for folks that have lunch or specifically set aside that time for fesco meetings. | ||
| bpepple | jwb: shoot/ | |
| jwb | well, let me know when the TZ stuff is done | |
| * bpepple thinks it might be done. | ||
| jwb | ok, so... | |
| bodhi and updates | ||
| and kernels | ||
| just a heads up that i plan on submitting two proposals to the list for review | ||
| warren | That last kernel update was somewhat unhappy | |
| was it ever cleared up how they were "forced" to push? | ||
| jwb | 1) kernel is exempt from bad karma auto un-pushes | |
| jwb | 2) Anonymous comments shouldn't effect karma | |
| tibbs | Wait, why do we want to exempt the kernel? | |
| warren | bad karma auto unpush applies to both testing and released kernels? | |
| nirik | can't 1 be overriden by the maintainer? shouldn't it be able to be? | |
| jwb | nirik, that's the more generic implementation yes | |
| warren | #1 is a lot more controversial than #2 | |
| tibbs | Wasn't ignored bad karma the cause of the recent problems? | |
| nirik | +1 for number 2 (ooh... that sounds nasty) | |
| jwb | tibbs, no | |
| tibbs | Well, there was bad karma on the update but it was pushed anyway. | |
| nirik | yeah, but it wasn't up to -3 yet | |
| jwb | tibbs, the kernel supports hundreds of devices. if you have 3 people with a broken device it can prevent the kernel getting pushed out. it's just silly | |
| cebbert, feel free to chime in here | ||
| warren | jwb, for the same reason we can't rely on +3 autopush either as being reliable | |
| f13 | especially when somebody can anonymously vote -1 three times in a row | |
| tibbs | There are many packages you could say the same about, though. | |
| nirik | perhaps allow maintainer to set the autounpush threshold? or ignore it? I would be fine with those. | |
| ivazquez | So then we define a "complexity" factor for packages and base the votes required either way on that? | |
| warren | jwb, #1 touches on the actual problem but I think we need a different solution | |
| f13 | tibbs: which is why a maintainer override may be in order. | |
| jwb | ok, i can phrase it as "maintainer overrideable" | |
| * nirik thinks we should trust maintainers to listen to the feedback, but do the right thing. | ||
| jwb | this is not a big deal to me. i just want the ability | |
| warren | #1 ... perhaps in general we need a way to turn off auto-unpush and autopush because it is inappropriate in such cases. The maintainer should decide if auto*push is allowed or not? | |
| jwb | isn't that what nirik said already? | |
| * jwb says it is | ||
| warren | Case 1) I'm pushing a tiny bugfix to leaf-node application that only a few people use. I don't necessarily want to manually push it after a few days of testing. Let others autpush it at +3. | |
| jwb | there are RFE's for this against bodhi already. lmacken has promised not to make them live until FESCo approves the general idea | |
| warren | Case 2) I don't want people's votes to influence pushing or not pushing. | |
| cebbert | let the maintainer set a threshold, where 0 means never autopush | |
| notting | sounds reasonable. also, having anon comments not allowed to set karma (when autopush is active) seems reasonable | |
| warren | threshold for both negative and positive? (otherwise the interface can get complicated) | |
| I like the idea of anon comments showing bad or good icons though so you can visually see how happy people are. | ||
| nirik | "give control about autopushing to maintainers per package" and let lmacken figure out implementation? | |
| jwb | ok, anyway i'll take this initial feedback and work it into the proposals | |
| notting | warren: as long as the icons have little pitchforks | |
| jwb | comment more on the list | |
| jwb | bpepple, i'm done for now :) | |
| bpepple | jwb: cool, thanks. | |
| cebbert | and let anon comments add or remove karma but just don't count it in the toals | |
| totals | ||
| bpepple | anything else, or do we call it quits for today? | |
| jwb | cebbert, i can tweak the RFE for that | |
| * 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 | |
| warren | Did we agree on maintainer can set threshold limits or zero? | |
| bpepple | Thanks, everyone! | |
| warren: I think that wasn't decided, since jwb was going to work the feedback into his proposal. | ||
| warren | ok | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!