--- 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
bpeppleFESCo 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
caillonnot really here...
may be able to vote when votes are called though
(if someone pings me)
warrencaillon, is your vote for sale?
* f13
jwb is 30% here
dwmw2_AVF has 100,000 Mongolian Tugrugs
dwmw2_AVFcaillon: will that buy your vote?
caillonwarren, my price is probably too high.
bpeppleok, 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
caillondwmw2_AVF, and i'm guessing it's probably not enough ;)
* notting is here
bpeppleFPC had proposals for Ocaml and tcl.  any objections to them?
f13no objections here.
bpepplenone here either.
dwmw2_AVFcaillon: 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_AVFI 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_AVFit's because of the way interprocedural optimisation happen, iirc.
tibbsYeah, ocaml is rather messed up.
dwmw2_AVFif they fix it to require stuff of the correct arch, fine. Else, -1 broken.
tibbsdwmw2_AVF: How can you do arch-specific requires?
RPM doesn't actually support that.
dwmw2_AVFfix one of the rpm bugs on the multilib tracker :)
or virtual provides
* dgilmore is here
tibbsI can send it back to the submitter, I guess.
f13does ocamel even get multilibbed?
dwmw2_AVFit has various libraries and accompanying devel subpackages
nirikmain ocaml itself isn't multilib it seems like... but some ocaml packages are.
f13so it doesn't do any automagic arch specific requires/provides like c libraries do?
nottingf13: looks to be all hashes
and we don't get the core compiler in both versions either (nor -m32/-m64 support).
tibbsThere is some requires/provides magic, but those are turned on in the individual spec files.
dgilmoreocaml seems to be overly complex
dwmw2_AVFI think I'm about to be dragged out for food. I vote for sending this proposal back to have its multilib issues sorted out.
tibbsI will send a rejection message out to the submitter and fedora-packaging.
f13yeah, seems like a trap
dwmw2_AVFI accidentally wrote a ppc64 back end for its compiler. It's _definitely_ complex :)
bpeppletibbs: cool.  thanks.
tibbsDo note also that these were merely alteration to existing ocaml guidelines.
bpeppletibbs: will do.
tibbsI don't think the original, accepted guidelines are any better on this issue.
dgilmoredwmw2_AVF: you should write a sparc64 one also :)
tibbsSo we're basically rejecting good changes because the original document has something that someone doesn't like.
Which is... kind of backwards.
dwmw2_AVFI don't mind approving it with a "please improve it further" comment
dgilmorewe can accept the fixes,  but we should ask them to also go off and fix our issues
dwmw2_AVFif it's considered progress
bpeppledgilmore: +1
tibbsI will make that note; we will present something to fesco after our next meeting, twelve days hence.
bpeppleok, anything else, or should we move on?
bpepplemoving 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
bpeppleis poelcat about?
poelcatwe 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.
jwbit looked good to me at first glance
bpeppleyeah, I read it last night, and it seemed reasonable.
warrenWe should get some feedback from ignorant RH engineers?
nirikMy 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.
poelcatwarren: i've run it past RHEL eng managers
warrenpoelcat, ah
ok then
bpepplepoelcat: so is there anything else you need us to do today for this?
warrenWill this differentiate between NEEDINFO due to this process, and NEEDINFO created by someone else?
nirikit falls into the CADT model, but oh well. ;(
poelcatbpepple: no, just general awareness, initial concerns, and vote next week :)
bpeppleok, sounds good.
if no one else has anything to add, we can probably move on.
poelcatwarren: yes and no... part of ExtremeMakeOver does tag NEEDINFO bugs
for special identification
poelcatbpepple: that's all from me
--- bpepple has changed the topic to: FESCo-Meeting -- Features Completion - http://fedoraproject.org/wiki/Releases/9/FeatureList - poelcat
poelcatwe are this part of the feature cycle: http://fedoraproject.org/wiki/Features/Policy#freeze
nirikpoelcat: oh, does the proposal ignore review requests and fearure requests? or ?
poelcatin 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
rwmjonessorry I missed all that & didn't understand the multilib problems.  Any specific questions?
dgilmoreVirtual Storage  and Xen paravirt ops  seem dubious
* nirik doesn't see anything on the features list he knows won't make it...
poelcatby 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.
bpeppledgilmore: yeah, we may need to check w/ dberrange to see what the status is of those.
tibbsThe Xen stuff looks pretty huge and is only at 35%.
nottingxen pvops for dom0 did not happen
there is no dom0 kernel in rawhide
dgilmorenotting: so we should drop it?
tibbsAh, dom0 is for F10.
The F9-targeted bit is indicated at 80%.
warrendom0 is totally unsupported on F9 by their announcement
so there will be no kernel-xen
for F-9
nirikthere's always xenner too. ;)
warrenjust wait until somebody submits a package review for compat-kernel-xen
nirikkernel-xen in cvs is rebased against 2.6.25rc something...
and hey, it's building now.
dgilmorenotting: good to know
nirik: even
bpepplepoelcat: so, is there anything we need to decide today, or do we need to wait until after your nag-mail?
dgilmorepoelcat: so please stress in your email to Feature owners the importance that things need to get done and they need to update the wiki
poelcatbpepple: no; okay if I cc fesco on nag mails?
bpepplepoelcat: yup.
dgilmorepoelcat: 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 :)
poelcatthat is all
bpepplepoelcat: great, thanks.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleanything else people need to discuss?
dgilmorebpepple: i have nothing
ivazquezDid anyone decide anything re vcs-pkg?
tibbsWhat's vcs-pkg?
bpeppleivazquez: 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.
ivazquezFair enough.
nottingsigh, more mailing lists that probably need policed
bpepplenotting: 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.
tibbsDo we need to decide what we're going to do once and for all about DST?
f13ivazquez: wha twere we supposed to decide on?
ivazquez: I just have to read about it.
ivazquezWhether or not the effort is worth pursuing.
Or even thinking about, for that matter.
f13ivazquez: I'm going to look into it and see what happens
nottingivazquez: 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?
ivazquezThat's why I'm passing it on to wiser people than I.
dgilmorehistorically we have always changed meeting time with DST  id like to continue doing so
f13dgilmore: but who's DST?
bpeppletibbs: 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.
dgilmoref13: US DST
bpeppledgilmore: correct.  I believe we decided that last year.
nirikwell, US except for HI and AZ. ;)
dgilmorenirik: well yes since they dont bother
jwbi 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.
bpepplejwb: shoot/
jwbwell, let me know when the TZ stuff is done
* bpepple thinks it might be done.
jwbok, so...
bodhi and updates
and kernels
just a heads up that i plan on submitting two proposals to the list for review
warrenThat last kernel update was somewhat unhappy
was it ever cleared up how they were "forced" to push?
jwb1) kernel is exempt from bad karma auto un-pushes
jwb2) Anonymous comments shouldn't effect karma
tibbsWait, why do we want to exempt the kernel?
warrenbad karma auto unpush applies to both testing and released kernels?
nirikcan't 1 be overriden by the maintainer? shouldn't it be able to be?
jwbnirik, that's the more generic implementation yes
warren#1 is a lot more controversial than #2
tibbsWasn't ignored bad karma the cause of the recent problems?
nirik+1 for number 2 (ooh... that sounds nasty)
jwbtibbs, no
tibbsWell, there was bad karma on the update but it was pushed anyway.
nirikyeah, but it wasn't up to -3 yet
jwbtibbs, 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
warrenjwb, for the same reason we can't rely on +3 autopush either as being reliable
f13especially when somebody can anonymously vote -1 three times in a row
tibbsThere are many packages you could say the same about, though.
nirikperhaps allow maintainer to set the autounpush threshold? or ignore it? I would be fine with those.
ivazquezSo then we define a "complexity" factor for packages and base the votes required either way on that?
warrenjwb, #1 touches on the actual problem but I think we need a different solution
f13tibbs: which is why a maintainer override may be in order.
jwbok, i can phrase it as "maintainer overrideable"
* nirik thinks we should trust maintainers to listen to the feedback, but do the right thing.
jwbthis 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?
jwbisn't that what nirik said already?
* jwb says it is
warrenCase 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.
jwbthere are RFE's for this against bodhi already.  lmacken has promised not to make them live until FESCo approves the general idea
warrenCase 2) I don't want people's votes to influence pushing or not pushing.
cebbertlet the maintainer set a threshold, where 0 means never autopush
nottingsounds reasonable. also, having anon comments not allowed to set karma (when autopush is active) seems reasonable
warrenthreshold 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?
jwbok, anyway i'll take this initial feedback and work it into the proposals
nottingwarren: as long as the icons have little pitchforks
jwbcomment more on the list
jwbbpepple, i'm done for now :)
bpepplejwb: cool, thanks.
cebbertand let anon comments add or remove karma but just don't count it in the toals
bpeppleanything else, or do we call it quits for today?
jwbcebbert, 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
warrenDid we agree on maintainer can set threshold limits or zero?
bpeppleThanks, everyone!
warren: I think that wasn't decided, since jwb was going to work the feedback into his proposal.

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