bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
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.
warren here
jwb is here
spot is here
c4chris_ waves
dgilmore is here
* jds2001 waves
jwbok, good meeting.  let's wrap
bpepplejwb: ;)
ok, we can probably get started.
--- bpepple has changed the topic to: FESCo-Meeting -- jds2001 -- http://fedoraproject.org/wiki/JonStanley/BugWorkflow
jds2001this is the lifecycle of a bug proposal that's gotten some feedback
* poelcat here
bpepplejds2001: the proposal seem pretty reasonable to me.
nirikso, ON_DEV should be removed, right?
jds2001based on that, i've removed ON_DEV as a requirement.  Multiple maintainer packages (kernel, anaconda, etc) should have individuals take over ownership from the list when they start working on it.
nirik: yes
nirik: it's crossed out on that wiki page
jwbso why is NEEDINFO_REPORTER not done until it's in the stable updates?
i'd think we'd want the reporter to test it from -testing, so we don't screw over everyone else if it's a bad package
jds2001it needs to be either closed or needinfo'ed at that point.
good point - but bodhi throws a comment in there that it's in -testing
and changes the state to ON_QA at that point
jwbyeah, at the point it hits stable it should have already been QA'd and verified.  so it should go to closed
i think ON_QA and NEEDINFO_REPORTER are sort of redundant
wwoods, ?
jds2001yep, some folks had issues with just closing em.
it's an option in pkgdb
jwbother than that i have no objections
poelcatON_QA indicates that the bug is in process of being verified/tested
NEEDINFO could be for anything
jwbpoelcat, yes.  ON_QA is where you need the bug reporter to go actually test it
jds2001NEEDINFO also fast-tracks to closure
poelcatjwb: it doesn't have to be just the reporter to test it
jwbpoelcat, no, it doesn't.  but it would be good
NEEDINFO_REPORTER implies that the reporter has to test it before the bug goes to closed state
which is wrong
poelcatjwb: I don't make the same inference
jwbhaving a fixed bug in a package in the stable updates repository with an open bugzilla ticket for 30 days seems silly
* wwoods not here yet, 1sec
jwball i'm saying is that ON_QA and NEEDINFO_REPORTER are the same thing
poelcatjwb: i see what you're saying... if the package goes to 'updates'... then auto close the bug
jds2001jwb: NEEDINFO(reporter) can me any of a number of things
lmackenat the moment bodhi closes bugs for stable updates as ERRATA.  My development branch puts bugs in ON_QA in -testing, which I'm going to be pushing live tonight
jwbif a package makes it through QA to updates, the bug should be closed.
lmackenI also need to add in the NEEDINFO_REPORTER when they hit stable
jwblmacken, why??
that's what we're discussing here. just hold on a sec code ninja ;)
poelcatjwb: i agree ... we don't need more latency
f13I'm here, late.
lmackenif the bugs don't auto-close, then needinfo_reporter (according to jons proposal)
jwblmacken, yes we're discussing the proposal.  don't change code yet
jds2001jwb: there's an option in pkgdb to make them auto-close or not.
lmackenno worries :)
wwoodsON_QA and NEEDINFO_REPORTER are not the same thing.
jwbexplain the difference
wwoodsNEEDINFO_REPORTER is a superset. there's a bunch of different reasons you'd request info from the reporter
jwbno, that's NEEDINFO
f13jds2001: pkgdb or bodhi?
wwoodsone is a specific stage of the bug lifecycle that we want to track separately
jds2001f13: i thought pkgdb, but maybe bodhi per individual update (i thought it was set on the package, i could be wrong - you'd know better  :) )
f13jds2001: it's a per-update state.
jds2001jwb: there is no such thing as NEEDINFO_REPORTER
nirikyeah, it's in bodhi
wwoodsthe others are things like: need more info about which software, info on triggering, etc
f13rather, per-update request, which could be one or more builds associated with it.
jwbjds2001, there is in your proposal...
f13NEEDINFO_REPORTER was removed in favor of just a generic NEEDINFO
jwb"When the update is pushed to stable, Bodhi optionally closes the bug automatically. If the update does not auto-close the bug, it transitions to NEEDINFO_REPORTER, with a comment explaining that the update has been pushed to stable, and to update and test in the new release."
f13(with targetted emails as the NEEDINFO of)
wwoods(as a side note, we can't currently do flag requestees from XMLRPC, so that's a tricky state to implement)
jds2001jwb: grr, should have been NEEDINFO(reporter)
jwbeither way, why would you put the bug back in NEEDINFO for a package that is already out the door to the masses?
it's just another step that i don't see as having benefit
jds2001jwb: is there some other state (thisi s if the amintainer has not flagged it to auto-close in bodhi)
nirikso should we remove the ability to not close the bug on stable push in bodhi?
jds2001jwb: i don't see it being used often
bpepplenirik: yeah, I think that is what jwb is driving at.
jwbsomething like that
f13jwb: NEEDINFO would be valid if it were being pushed to testing
lmackenthats how it was originally, but I recall someone filed a ticket, so I added a checkbox
jwbf13, that's ON_QA in the proposal
f13it's slightly higher than just ON_QA, more targetted as "Hey, go look at this"
jwbbut yeah, that's fine
f13jwb: ON_QA doesn't trigger entries in bugzilla front pages
jwb: but needinfo requested of you does
jwbi'm cool with NEEDINFO/ON_QA when it's in -testing
jds2001well as wwoods pointed out, we've got technical issues with NEEDINFO
we can't do requestees via XMLRPC right now.
f13k, so ON_QA it is (:
jwbbasically, at the time the package hits the updates repo the bug should be fixed.  if it's not, and the reporter didn't bother to test it from -testing, the bug can always be REOPENED
poelcatjwb: +1
c4chrisjwb: agreed
poelcatso why not have bodhi auto-close ALL bugs after moving to 'updates' ?
and if owner want to reopen them they can do it manually
lmackenI'll elaborate on the bug comment a bit more too, link back to bodhi and encourage feedback
poelcat: There are actually a lot of people that uncheck that box.
* lmacken isn't sure why though
poelcatso take the box away :)
lmackeni'd be happy to
bpepplelmacken: could that be do to one bug that covers multiple releases?
lmackendo it, and see who complains ?
bpepplelmacken: +1
poelcatbpepple: good point... like a blocker or tracker bug?
c4chrisfine with me
f13there is reasons
there /are/ reasons
jds2001bpepple: that's another pet peeve of mine.  One bug == one problem with one release
f13for not autoclosing the bug
lmackencould be.. but the next bodhi update will support the new bug tracking policy with parent/child bugs
f13but we should just allow folks to either opt into automunging or opt out.  Plain and simple
you either get all the munging, or you don't and you do it on your own.
f13we design for the folks that want automunging
jds2001lmacken: ignore bugs with the Tracking keyword set
wwoodsit'd be nice if we were keeping metrics on maintainer bug count
jds2001or maybe some other set
wwoodsto encourage people to use the autoclose thing to keep their dang bug counts down
jwbwwoods, that would make people like davej look horrid
lmackenjds2001: something like that.. It should comply with this: http://fedoraproject.org/wiki/Security/TrackingBugs
jwbwhich is simply untrue
wwoodshe's an outlier
jds2001wwoods: de-cookify reports for me (or get dkl to do it) and I'd be happy too :)
wwoodsnot statistically significant
nirikwwoods: there is... in the packagereport.
poelcatf13: except when they don't do it on their own there is no check/balance to bring about resolution is there?
f13poelcat: there isn't, however I don't think we should necessarily dictate how folks choose to deal with their bugs, apart from the outlandish.
poelcat: we're providing them a tool to manage it for them, but if they disagree, then it's up to them to deal with it how they see fit.
poelcatf13: isn't that what we are doing with the bug lifecycle?
f13poelcat: if there is an issue with how a particular member is dealing with their bugs, that
that's something that can be brought to FESCO and/or the member's sponsor
nottingnirik: hm, you may want to exclude extras-orphan from 'people with no cvs activity'
bpeppleok, are we at a point to vote on jds2001's proposal (taking into account jwb's suggestion about item #7 in Lifecycle of a bug)?
niriknotting: not my script. ;) But yeah.
poelcatf13: i'm all for freedom except when/if it makes the rest of the prjoect look bad.... bugs not closed in a timely manner
c4chrisnotting: noted :)
nirik+1 here.
jwbjds2001, good work btw
jwbwarren, ?
* nirik notes that we should make sure and announce to devel-announce, blog, etc... otherwise people might not realise whats going on.
bpepplenirik: agreed.
warrenjwb, just a noise.
f13poelcat: like all things we create, these are guidelines, and guidelines can and do have exceptions.  I don't feel that this hsould be a stone slab for which to beat people over the head with.
bpeppleok, I see eight '+1' to jds2001's proposal, so it has been approved.
nottingdo we have a link to 'meet the triage team' so maintainers can easily pick them out from random bug commenters?
jwbgood question
jds2001notting: i was planning something like that.
* poelcat makes a note for a new wiki page
bpeppleok, we can probably move on to the next topic since it also deals with bugs.
--- bpepple has changed the topic to: FESCo-Meeting -- nirik -- FedoraBugs Group - Approval to make it require cla_done and how sponsors for that group should be approved
bpepplenirik: ?
nirikok, is it ok to require cla_done for fedorabugs group? Any objections?
nirikand does Fesco want to approve sponsors for fedorabugs? or leave it to fedorabugs admins? or other ideas?
f13I'm still not seeing the need for it.
tibbsWould we be requiring cla_done for some legal reason?
Or just as a membership test?
jds2001yes, if they started writing docs, we couldn't use them.
poelcatwe need a some sort of minor bar for entry
nirikf13: for cla_done? or ?
jds2001or pieces of comments in docs, etc.
wwoodsa little of both - We want to strongly encourage triagers to contribute triaging notes and whatnot on the wiki
poelcatand this seems like a simple way
tibbswriting docs in bugzilla tickets doesn't seem to be a good idea.
They can't get on the wiki without cla_done, of course.
jds2001lol agreed :)
warrencla_done -> fedorabugs automatic could be a self-serve option of getting fedorabugs
f13cla_done I can see, sortof.  But sponsors doesn't make a whole lot of sense
that just raises the bar for people to help out
bpepplef13: agreed.
wwoodsand since you can flag a bugzilla entry as requires_release_note, that's implicit contribution of documentation
jds2001well, not sponsors in the traditional sense
spotcla_done seems like a good CYA from my perspective
nirikwell, the reason for sponsors is that they get email about new people asking... not that they need sponsorship
wwoodsit's a very low technical hurdle - anyone unable to overcome it would be of questionable use as a triager
jds2001what i propose is that folks watch other folks in bz for a week or two
poelcatwwoods: +1
f13I'm cla_done +1, sponsor -1
jwbcla_done +1, sponsor -1
f13if you've got cla_done, and you want to help out with bugs, you should be able to place your self in the fedora-bugs group.
poelcatso who approves sponsors?
wwoodsI thought we decided that we'd bugzilla-watch new triagers for a week or two
and if they start screwing up all over the place, we drop 'em from fedorabugs
jds2001just ot make sure they ge thte hang of it, etc.
poelcatwwoods: who is going to do that?
jds2001poelcat: the sponsors that are getting voted down :)
jwbthe other triagers?
jds2001jwb: exactly
poelcati think we'll hear about it if someone does some badness so I don't think we need to watch people
bpepplepoelcat: agreed.
jwbi don't see that as sponsorship.  i see it as peer accountability
nottingthe problem is, *someone* needs to add people to/from fedorabugs. which implies some sort of sponsorship/admin overhead
jds2001jwb: sponsor is the only term that FAS lets us use.
jwbwhere's FAS2?
jds2001but yes, peer accountability
f13notting: wrong
f13notting: the group could be setup as sponsorship not needed, just cla_done required
notting: then the user themselves can add themself to the group
nottingf13: i'm not sure that's as wise
f13if they can't handle that, then come back when you can.
notting: why not?
notting: it's not like they can't make comments in bugs already
and be really disruptive if they wanted to
jds2001yes, but they can close them and make us lose em.
nottingf13: because if they then go nuts, we can't reliably kick people out (they'll just re-add themselves)
f13we're not really protecting anything, we're just making more processes for the sake of process.
nirikso should cla_done auto add fedorabugs then?
f13notting: if they go nuts enough, we can flat out remove their account.
tibbsOnce people have fedorabugs, they can change anything, right?
jds2001tibbs: yes
jwbunless it's a RHEL bug
jds2001jwb: even RHEL ones
tibbsBecause there's an issue with folks approving review tickets why might not have cvsextras access.
jds2001that aren't private, that is.
tibbsNot that we didn't have it already, but it sounds like there could be more potential for confusion.
jds2001well, i don't have cvsextras, nor do I approve reviews :)
tibbsBut if you had fedorabugs, you could.
tibbsI guess the cvs admins will need to check that before importing.  Just something to think about.
nirikyeah, I am sure the set of fedorabugs and the cvsextras set already arent the same. :)
jds2001difference of around 60
nirikwell, if we are not requiring any sponsorship or the like, shouldn't cla_done just get you fedorabugs?
warrentibbs, "I guess the cvs admins will need to check that before importing."
tibbs, Apache's Bugzilla has an interesting thing that might help us here.
tibbs, next to people's names are color coded medallions denoting their membership level
tibbs, nothing for non-members, and a color for apache members
just a thought
tibbsI doubt Red Hat would let us do that kind of thing to their bugzilla.
warrentibbs, with enough lead-time and planning we could eventually get it.
f13maybe you could require a sufficient Karma level to be in fedorabugs
when FAS2
earn karma by commenting on bugs and contributing patches
since a lot of triage work can be done without fedorabugs level access
jds2001i rather like what mozilla does
warrenwhich is?
jds2001"send me three comments that you made"
warrenlike ... references to yourself?
jds2001very low barrier for entry
tibbsBut we're still back to sponsorship.
jds2001essentially, yes.
f13with karma points the sponsorship is implicit rather than explicit
and we don't have to go hunting down some person to click a button
nottingwell, 'administrative action to get fedorabugs membership'
f13if the user has enough karma points, they get in.
tibbsSounds great, but....
jds2001well, now that i am a fedorabugs sponsor, i get mail when ppl want in
c4chrisbut the attribution of karma points is not automated, right?
tibbsWe kind of don't have that system yet.
jds2001and i can easily go click buttons quickly :)
f13tibbs: sure, I'm just thinking ahead as ways to solve this problem with better tooling
nirikyeah, I think down the road karma would work nicely... and tie into the maintainers karma stuff too.
tibbsNo objection to that, but unfortunately we have to do somehting today.
warrenf13, how do we handle if a user is being an ass-hat and constantly reopening a bug that has been closed for good reason?
f13warren: karma -1
c4chrisjds2001: you really wanna watch over all the incoming requests ?
warrenkarma -10000
jds2001c4chris: i do now, yes.
poelcatc4chris: i don't think there are that many
f13warren: if an individual acts out bad enough, they can be un-sponsored
and dropped from all groups
and all karma removed.
nirikthere were piles of people in the fedorabugs queue... it should be smaller moving forward.
f13but these are extreme cases, something to be handled case by case rather than programatically
poelcatclear the queue and start over
c4chrisI'm fine with cla_done and jds2001 or poelcat pushing the button for now
jds2001c4chris: i get everyone that gets into cvsextras, too - so it's a little work
c4chrisrevisit when karma is implemented...
jds2001c4chris: to check they aren't already auto-approved via cvsextras
nirikjds2001: really? oh, just an email that they were added?
jds2001but even the volume of that is low
spotc4chris: that works for me as well.
nottingc4chris: +1
nirikc4chris: +1
niriknote that there are a small # of people in fedorabugs now that are not in cla_done. We will need to ping them and remove them if they don't add into cla_done.
bpepplenirik: sounds fine to me.
does anyone disagree with c4chris's proposal, otherwise we should move on since we still got the upstart feature to discuss.
warrengo go
--- bpepple has changed the topic to: FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat
poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/Upstart
nirikso this can't be parallel installed with sysvinit/initng? it conflicts?
bpepplenirik: I believe that is correct.
tibbsI can only say that I support "making things better", but I can't really evaluate the particulars of upstart.
spotyes, but it does provide the same functionality
wwoodsupstart really seems.. right-thinking
tibbsIf it could be installed and switched over to temporaily, it would be easier to get testers.
sadmacnirik: It could be, but dealing with two init systems at once is probably more of a pain than its worth for everyone.
nirikyeah, that was my thinking...
tibbsI guess that's why folks are adding for parallel installs.
lmackena code audit was done by some people at fudcon, and I heard the code is good.
niriknotting: you are the current sysvinit maintainer... thoughts? :)
tibbsHonestly, though, being able to rise above NIH is a good thing.
f13I'm +1 for this, I trust that those involved will do it right.
wwoodsthe test plan needs to be expanded to indicate how you install the dang thing to test with it
spotwwoods: ideally, the package will Obsoletes/Provides sysvinit
nottingnirik: i'm for it. if all else fails, we may stage this like spot is doing perl-5.10
tibbsI would also like to know if upstart will have additional dependencies.
spotand sysvinit will be blocked from rawhide
sadmacwwoods: current idea is you do "yum update" and suddenly you have it.
niriknot parallel installable also makes it harder to decide before release which one to use... but yeah...
wwoodsyeah but unless it's fully backwards compatible and/or easy to remove
warrenThe way it was described during FUDCon, it is a drop-in replacement that at first behaves exactly like the current thing.
spotwwoods: it is fully backwards compat.
wwoodsthen "suddenly you have upstart" sounds like "suddenly you have herpes"
bpepplewwoods: ;)
sadmactibbs: there are a few miscellaneous tools that are in sysvinit that are needed by the initscripts package itself. Those are going to have to be put into a new package which upstart will depend upon
* poelcat was thinking "suddenly you have a brick"
nirikI'm ok with it, but I would suggest it get in as soon as possible to try and get max testing time in devel...
bpepplenirik: agreed.
wwoodsbut, yes, in the f7(?) era I actually sat around messing with upstart and it supported launching all your old initscripts in a nicely backwards way
warrenThere is no SysV "mode", but rather one of the "events" that upstart does by default is simply "run that rc.d stuff" so in that way it behaves exactly like SysV
tibbssadmac: My concern is that it will need to pull in things like python or X or even dbus.
sadmactibbs: none of the above :)
tibbsI just want to be able to keep the minimal system minimal.
warren"it supported launching all your old initscripts in a nicely backwards way" =)
sadmactibbs: no concerns there.
spottibbs: keep in mind that debian is using this, so its about as minimal as you can get
tibbsThen again, init=/bin/sh should still work.
wwoodswarren: so yeah, so long as that assumption hasn't broken, I'm all for it
sadmacspot: is that true? Last I heard they were still teetering over it because "ubuntu did it"
nottingnirik: post-alpha, i'm all for getting it in as soon as possible. need to get some selinux bits in mkinitrd first
spotsadmac: last time i looked they had it in the bleeding edge tree
warrenwwoods, I just had imagery in my mind where initscripts ran literally backwards
nottingnirik: and then sanitize policy
poelcatis that enough +1s ?
jwbnotting, post-alpha is now, eh?
sadmacnotting: what were your thoughts about splitting those tools off of sysvinit? Do you still prefer another way?
* spot has plans to spend some time testing this out, making sure the package is in good shape
bpepplepoelcat: I believe so, and more importantly I don't see any '-1'.
nirikyeah, +1 here.
poelcatin the interest of time... move on?
nottingjwb: post-alpha means 'after we're not running around like a chicken with our heads cut off getting the alpha out'
bpepplepoelcat: were there other features to discuss today?
tibbsAlso, could we please get guidelines for what we should do with our initscripts to increase awesomeness?
jwbnotting, but what i'm saying is that there's only a few people doing the chicken thing for alpha.  upstart could hit rawhide whenever, yes?
poelcatbpepple 4 more if you like :)
poelcatthey came in after tuesday
nottingjwb: see above about selinux, etc.
sadmac: no real problems, just need to do it
sadmacnotting: cool
bpepplepoelcat: ah.  Let's try to do one more since we're just about at the hour point.
jwboh, i forgot you own sysvinit too
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/GCC4.3
nottingsadmac: do you have any problems with building the first upstart pkgs in dist-f9-upstart (or somesuch) so we can land changes as a whole?
f13hrm, he didn't put it in the wiki
sadmacnotting: works fine for me
f13but I talked to Jakub, and after we land gcc43 into rawhide, he wanted to give some time for natural builds against it to happen before we coordinate any mass rebuild for it
sadmacnotting: I don't have any build system access yet, since this is my first package, and I don't believe the review has gone through
* nirik notes that upstart must first pass review. ;)
f13so there is still the possibility of a mass rebuild of packages against gcc43, but not immediately.
jwbhow long?
f13jwb: I think he said 2 weeks~
jwbreason ?
spotsadmac: i'll work with you on that
sadmacspot: cool
spotsadmac: i've just been buried in ... paperwork lately.
sadmacspot: lol
f13while they found a bunch of stuff in test rebuilds, they're still not 100% sure that it's ready to build everythin gagainst it, without finding something an dhaving to rebuild everything /again/
c4chrisI'm fine with gcc 4.3 in F9
tibbsI think the gcc43 stuff has been handled fine so far.
I see no reason why we shouldn't go for it, although the sooner the better.
c4chrisworse comes to worst, we could have a compat-gcc pkg...
bpeppletibbs: agreed
f13yeah, I'm +1 on the feature, just not going to schedule a mass rebuild for it this week
c4chrisno kidding :)
tibbsIt would also be nice if someone who understands the intricate details of the possible breakages could be highly available for a while after the rebuild starts.
jakub is on the hook for that
bpeppleok, I see five '+1' anyone else have an opinion?
* nirik is really happy with the seperate tag and mass rebuilding testing done. Thats been great.
spoti've still got stuff to fix, but, well, i always have stuff to fix.
* nirik also has a few things to fix.
c4chrissame here...
warrenIs jakub back from vacation now?
bpepplepoelcat: ok, it looks like we have a majority for this feature.
spotwarren: i think so, yes.
warrenbut wait, wont we need a mass rebuild immediately upon gcc-4.3?
it breaks ABI
nottingwell, anyone rebuilding C++ will need to be careful
poelcatbpepple: save the others for next week?
f13warren: jakub says we don't need one immediately
bpepplepoelcat: yeah, I think that makes sense since we're already over the hour point.
warrenf13, perhaps only for the C++ packages?
f13warren: he didn't say any.
poelcatbpepple: okay: http://fedoraproject.org/wiki/Features/Dashboard will remain updated
bpepplepoelcat: great, thanks.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleanything else to discuss before wrapping up for this week?
tibbsLots of progress on the review queue recently.
bpeppletibbs: sweet.
* c4chris needs to leave... cheers and later folks
warren needs food
bpeppleok, let's wrap up then.
tibbsAlso, I colorized the ticket list a bit to show tickets needing sponsors (green) or guidelines (red).
* 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

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