| bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo 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 | ||
| jwb | ok, good meeting. let's wrap | |
| bpepple | jwb: ;) | |
| ok, we can probably get started. | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- jds2001 -- http://fedoraproject.org/wiki/JonStanley/BugWorkflow | ||
| jds2001 | this is the lifecycle of a bug proposal that's gotten some feedback | |
| * poelcat here | ||
| bpepple | jds2001: the proposal seem pretty reasonable to me. | |
| nirik | so, ON_DEV should be removed, right? | |
| jds2001 | based 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 | ||
| jwb | so 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 | ||
| jds2001 | it 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 | ||
| jwb | yeah, 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, ? | ||
| jds2001 | yep, some folks had issues with just closing em. | |
| it's an option in pkgdb | ||
| jwb | other than that i have no objections | |
| poelcat | ON_QA indicates that the bug is in process of being verified/tested | |
| NEEDINFO could be for anything | ||
| jwb | poelcat, yes. ON_QA is where you need the bug reporter to go actually test it | |
| jds2001 | NEEDINFO also fast-tracks to closure | |
| poelcat | jwb: it doesn't have to be just the reporter to test it | |
| jwb | poelcat, 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 | ||
| poelcat | jwb: I don't make the same inference | |
| jwb | having 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 | ||
| jwb | all i'm saying is that ON_QA and NEEDINFO_REPORTER are the same thing | |
| poelcat | jwb: i see what you're saying... if the package goes to 'updates'... then auto close the bug | |
| jds2001 | jwb: NEEDINFO(reporter) can me any of a number of things | |
| lmacken | at 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 | |
| jwb | if a package makes it through QA to updates, the bug should be closed. | |
| lmacken | I also need to add in the NEEDINFO_REPORTER when they hit stable | |
| jwb | lmacken, why?? | |
| that's what we're discussing here. just hold on a sec code ninja ;) | ||
| poelcat | jwb: i agree ... we don't need more latency | |
| f13 | I'm here, late. | |
| lmacken | if the bugs don't auto-close, then needinfo_reporter (according to jons proposal) | |
| jwb | lmacken, yes we're discussing the proposal. don't change code yet | |
| jds2001 | jwb: there's an option in pkgdb to make them auto-close or not. | |
| lmacken | no worries :) | |
| wwoods | ON_QA and NEEDINFO_REPORTER are not the same thing. | |
| jwb | explain the difference | |
| wwoods | NEEDINFO_REPORTER is a superset. there's a bunch of different reasons you'd request info from the reporter | |
| jwb | no, that's NEEDINFO | |
| f13 | jds2001: pkgdb or bodhi? | |
| wwoods | one is a specific stage of the bug lifecycle that we want to track separately | |
| jds2001 | f13: 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 :) ) | |
| f13 | jds2001: it's a per-update state. | |
| jds2001 | jwb: there is no such thing as NEEDINFO_REPORTER | |
| nirik | yeah, it's in bodhi | |
| wwoods | the others are things like: need more info about which software, info on triggering, etc | |
| f13 | rather, per-update request, which could be one or more builds associated with it. | |
| jwb | jds2001, there is in your proposal... | |
| f13 | NEEDINFO_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) | |
| poelcat | s/NEEDINFO_RPORTER/NEEDINFO | |
| jds2001 | jwb: grr, should have been NEEDINFO(reporter) | |
| jwb | either 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 | ||
| jds2001 | jwb: is there some other state (thisi s if the amintainer has not flagged it to auto-close in bodhi) | |
| nirik | so should we remove the ability to not close the bug on stable push in bodhi? | |
| jds2001 | jwb: i don't see it being used often | |
| bpepple | nirik: yeah, I think that is what jwb is driving at. | |
| jwb | something like that | |
| f13 | jwb: NEEDINFO would be valid if it were being pushed to testing | |
| lmacken | thats how it was originally, but I recall someone filed a ticket, so I added a checkbox | |
| jwb | f13, that's ON_QA in the proposal | |
| f13 | it's slightly higher than just ON_QA, more targetted as "Hey, go look at this" | |
| jwb | but yeah, that's fine | |
| f13 | jwb: ON_QA doesn't trigger entries in bugzilla front pages | |
| jwb: but needinfo requested of you does | ||
| jwb | i'm cool with NEEDINFO/ON_QA when it's in -testing | |
| jds2001 | well as wwoods pointed out, we've got technical issues with NEEDINFO | |
| we can't do requestees via XMLRPC right now. | ||
| f13 | k, so ON_QA it is (: | |
| jwb | basically, 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 | |
| jds2001 | yep | |
| poelcat | jwb: +1 | |
| c4chris | jwb: agreed | |
| poelcat | so why not have bodhi auto-close ALL bugs after moving to 'updates' ? | |
| and if owner want to reopen them they can do it manually | ||
| lmacken | I'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 | ||
| poelcat | so take the box away :) | |
| lmacken | i'd be happy to | |
| bpepple | lmacken: could that be do to one bug that covers multiple releases? | |
| lmacken | do it, and see who complains ? | |
| bpepple | lmacken: +1 | |
| poelcat | bpepple: good point... like a blocker or tracker bug? | |
| c4chris | fine with me | |
| f13 | there is reasons | |
| erm | ||
| there /are/ reasons | ||
| jds2001 | bpepple: that's another pet peeve of mine. One bug == one problem with one release | |
| f13 | for not autoclosing the bug | |
| lmacken | could be.. but the next bodhi update will support the new bug tracking policy with parent/child bugs | |
| f13 | but 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. | ||
| jwb | yeah | |
| f13 | we design for the folks that want automunging | |
| jds2001 | lmacken: ignore bugs with the Tracking keyword set | |
| wwoods | it'd be nice if we were keeping metrics on maintainer bug count | |
| jds2001 | or maybe some other set | |
| wwoods | to encourage people to use the autoclose thing to keep their dang bug counts down | |
| jwb | wwoods, that would make people like davej look horrid | |
| lmacken | jds2001: something like that.. It should comply with this: http://fedoraproject.org/wiki/Security/TrackingBugs | |
| jwb | which is simply untrue | |
| wwoods | he's an outlier | |
| jds2001 | wwoods: de-cookify reports for me (or get dkl to do it) and I'd be happy too :) | |
| wwoods | not statistically significant | |
| nirik | wwoods: there is... in the packagereport. | |
| poelcat | f13: except when they don't do it on their own there is no check/balance to bring about resolution is there? | |
| nirik | http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-181b0c70022aca0d7aa42d42f7ed12a553189882 | |
| f13 | poelcat: 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. | ||
| poelcat | f13: isn't that what we are doing with the bug lifecycle? | |
| f13 | poelcat: 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 | ||
| notting | nirik: hm, you may want to exclude extras-orphan from 'people with no cvs activity' | |
| bpepple | ok, 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)? | |
| nirik | notting: not my script. ;) But yeah. | |
| notting | +1 | |
| poelcat | f13: i'm all for freedom except when/if it makes the rest of the prjoect look bad.... bugs not closed in a timely manner | |
| c4chris | notting: noted :) | |
| nirik | +1 here. | |
| jwb | +1 | |
| warren | meh | |
| bpepple | +1 | |
| warren | +1 | |
| c4chris | +1 | |
| jwb | jds2001, good work btw | |
| spot | +1 | |
| f13 | +1 | |
| jwb | warren, ? | |
| * nirik notes that we should make sure and announce to devel-announce, blog, etc... otherwise people might not realise whats going on. | ||
| bpepple | nirik: agreed. | |
| warren | jwb, just a noise. | |
| f13 | poelcat: 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. | |
| bpepple | ok, I see eight '+1' to jds2001's proposal, so it has been approved. | |
| notting | do we have a link to 'meet the triage team' so maintainers can easily pick them out from random bug commenters? | |
| jwb | good question | |
| jds2001 | notting: i was planning something like that. | |
| * poelcat makes a note for a new wiki page | ||
| bpepple | ok, 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 | ||
| bpepple | nirik: ? | |
| nirik | ok, is it ok to require cla_done for fedorabugs group? Any objections? | |
| nirik | and does Fesco want to approve sponsors for fedorabugs? or leave it to fedorabugs admins? or other ideas? | |
| f13 | I'm still not seeing the need for it. | |
| tibbs | Would we be requiring cla_done for some legal reason? | |
| Or just as a membership test? | ||
| jds2001 | yes, if they started writing docs, we couldn't use them. | |
| poelcat | we need a some sort of minor bar for entry | |
| nirik | f13: for cla_done? or ? | |
| jds2001 | or pieces of comments in docs, etc. | |
| wwoods | a little of both - We want to strongly encourage triagers to contribute triaging notes and whatnot on the wiki | |
| poelcat | and this seems like a simple way | |
| tibbs | writing docs in bugzilla tickets doesn't seem to be a good idea. | |
| They can't get on the wiki without cla_done, of course. | ||
| jds2001 | lol agreed :) | |
| warren | cla_done -> fedorabugs automatic could be a self-serve option of getting fedorabugs | |
| f13 | cla_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 | ||
| jwb | yeah | |
| bpepple | f13: agreed. | |
| wwoods | and since you can flag a bugzilla entry as requires_release_note, that's implicit contribution of documentation | |
| jds2001 | well, not sponsors in the traditional sense | |
| spot | cla_done seems like a good CYA from my perspective | |
| nirik | well, the reason for sponsors is that they get email about new people asking... not that they need sponsorship | |
| wwoods | it's a very low technical hurdle - anyone unable to overcome it would be of questionable use as a triager | |
| jds2001 | what i propose is that folks watch other folks in bz for a week or two | |
| poelcat | wwoods: +1 | |
| f13 | I'm cla_done +1, sponsor -1 | |
| jwb | cla_done +1, sponsor -1 | |
| f13 | if 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. | |
| poelcat | so who approves sponsors? | |
| wwoods | I 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 | ||
| jds2001 | just ot make sure they ge thte hang of it, etc. | |
| poelcat | wwoods: who is going to do that? | |
| jds2001 | poelcat: the sponsors that are getting voted down :) | |
| jwb | the other triagers? | |
| jds2001 | jwb: exactly | |
| poelcat | i think we'll hear about it if someone does some badness so I don't think we need to watch people | |
| bpepple | poelcat: agreed. | |
| poelcat | expclicitly | |
| jwb | i don't see that as sponsorship. i see it as peer accountability | |
| notting | the problem is, *someone* needs to add people to/from fedorabugs. which implies some sort of sponsorship/admin overhead | |
| jds2001 | jwb: sponsor is the only term that FAS lets us use. | |
| jwb | where's FAS2? | |
| jds2001 | but yes, peer accountability | |
| f13 | notting: wrong | |
| jwb | :) | |
| f13 | notting: the group could be setup as sponsorship not needed, just cla_done required | |
| notting: then the user themselves can add themself to the group | ||
| jwb | yeah | |
| notting | f13: i'm not sure that's as wise | |
| f13 | if 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 | ||
| jds2001 | yes, but they can close them and make us lose em. | |
| notting | f13: because if they then go nuts, we can't reliably kick people out (they'll just re-add themselves) | |
| f13 | we're not really protecting anything, we're just making more processes for the sake of process. | |
| nirik | so should cla_done auto add fedorabugs then? | |
| f13 | notting: if they go nuts enough, we can flat out remove their account. | |
| tibbs | Once people have fedorabugs, they can change anything, right? | |
| jds2001 | tibbs: yes | |
| jwb | unless it's a RHEL bug | |
| jds2001 | jwb: even RHEL ones | |
| jwb | no | |
| tibbs | Because there's an issue with folks approving review tickets why might not have cvsextras access. | |
| jds2001 | that aren't private, that is. | |
| jwb | right | |
| tibbs | Not that we didn't have it already, but it sounds like there could be more potential for confusion. | |
| jds2001 | well, i don't have cvsextras, nor do I approve reviews :) | |
| tibbs | But if you had fedorabugs, you could. | |
| jds2001 | indeed | |
| tibbs | I guess the cvs admins will need to check that before importing. Just something to think about. | |
| nirik | yeah, I am sure the set of fedorabugs and the cvsextras set already arent the same. :) | |
| jds2001 | difference of around 60 | |
| nirik | well, if we are not requiring any sponsorship or the like, shouldn't cla_done just get you fedorabugs? | |
| warren | tibbs, "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 | ||
| tibbs | I doubt Red Hat would let us do that kind of thing to their bugzilla. | |
| warren | tibbs, with enough lead-time and planning we could eventually get it. | |
| f13 | maybe 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 | ||
| jds2001 | i rather like what mozilla does | |
| warren | which is? | |
| jds2001 | "send me three comments that you made" | |
| warren | like ... references to yourself? | |
| jds2001 | very low barrier for entry | |
| tibbs | But we're still back to sponsorship. | |
| jds2001 | essentially, yes. | |
| f13 | with karma points the sponsorship is implicit rather than explicit | |
| and we don't have to go hunting down some person to click a button | ||
| notting | well, 'administrative action to get fedorabugs membership' | |
| f13 | if the user has enough karma points, they get in. | |
| tibbs | Sounds great, but.... | |
| jds2001 | well, now that i am a fedorabugs sponsor, i get mail when ppl want in | |
| c4chris | but the attribution of karma points is not automated, right? | |
| tibbs | We kind of don't have that system yet. | |
| jds2001 | and i can easily go click buttons quickly :) | |
| f13 | tibbs: sure, I'm just thinking ahead as ways to solve this problem with better tooling | |
| nirik | yeah, I think down the road karma would work nicely... and tie into the maintainers karma stuff too. | |
| tibbs | No objection to that, but unfortunately we have to do somehting today. | |
| f13 | yep | |
| warren | f13, how do we handle if a user is being an ass-hat and constantly reopening a bug that has been closed for good reason? | |
| f13 | warren: karma -1 | |
| c4chris | jds2001: you really wanna watch over all the incoming requests ? | |
| warren | karma -10000 | |
| jds2001 | c4chris: i do now, yes. | |
| poelcat | c4chris: i don't think there are that many | |
| f13 | warren: if an individual acts out bad enough, they can be un-sponsored | |
| and dropped from all groups | ||
| and all karma removed. | ||
| nirik | there were piles of people in the fedorabugs queue... it should be smaller moving forward. | |
| f13 | but these are extreme cases, something to be handled case by case rather than programatically | |
| poelcat | clear the queue and start over | |
| c4chris | I'm fine with cla_done and jds2001 or poelcat pushing the button for now | |
| jds2001 | c4chris: i get everyone that gets into cvsextras, too - so it's a little work | |
| c4chris | revisit when karma is implemented... | |
| jds2001 | c4chris: to check they aren't already auto-approved via cvsextras | |
| nirik | jds2001: really? oh, just an email that they were added? | |
| jds2001 | but even the volume of that is low | |
| spot | c4chris: that works for me as well. | |
| notting | c4chris: +1 | |
| nirik | c4chris: +1 | |
| bpepple | +1 | |
| nirik | note 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. | |
| bpepple | nirik: 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. | ||
| warren | go 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 | ||
| nirik | so this can't be parallel installed with sysvinit/initng? it conflicts? | |
| bpepple | nirik: I believe that is correct. | |
| tibbs | I can only say that I support "making things better", but I can't really evaluate the particulars of upstart. | |
| spot | yes, but it does provide the same functionality | |
| wwoods | upstart really seems.. right-thinking | |
| tibbs | If it could be installed and switched over to temporaily, it would be easier to get testers. | |
| sadmac | nirik: It could be, but dealing with two init systems at once is probably more of a pain than its worth for everyone. | |
| nirik | yeah, that was my thinking... | |
| tibbs | I guess that's why folks are adding for parallel installs. | |
| lmacken | a code audit was done by some people at fudcon, and I heard the code is good. | |
| nirik | notting: you are the current sysvinit maintainer... thoughts? :) | |
| tibbs | Honestly, though, being able to rise above NIH is a good thing. | |
| f13 | I'm +1 for this, I trust that those involved will do it right. | |
| wwoods | the test plan needs to be expanded to indicate how you install the dang thing to test with it | |
| spot | wwoods: ideally, the package will Obsoletes/Provides sysvinit | |
| notting | nirik: i'm for it. if all else fails, we may stage this like spot is doing perl-5.10 | |
| tibbs | I would also like to know if upstart will have additional dependencies. | |
| spot | and sysvinit will be blocked from rawhide | |
| sadmac | wwoods: current idea is you do "yum update" and suddenly you have it. | |
| nirik | not parallel installable also makes it harder to decide before release which one to use... but yeah... | |
| wwoods | yeah but unless it's fully backwards compatible and/or easy to remove | |
| warren | The way it was described during FUDCon, it is a drop-in replacement that at first behaves exactly like the current thing. | |
| spot | wwoods: it is fully backwards compat. | |
| wwoods | then "suddenly you have upstart" sounds like "suddenly you have herpes" | |
| warren | lol | |
| bpepple | wwoods: ;) | |
| sadmac | tibbs: 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" | ||
| nirik | I'm ok with it, but I would suggest it get in as soon as possible to try and get max testing time in devel... | |
| bpepple | nirik: agreed. | |
| +`1 | ||
| wwoods | but, 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 | |
| warren | There 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 | |
| tibbs | sadmac: My concern is that it will need to pull in things like python or X or even dbus. | |
| sadmac | tibbs: none of the above :) | |
| tibbs | I just want to be able to keep the minimal system minimal. | |
| warren | "it supported launching all your old initscripts in a nicely backwards way" =) | |
| sadmac | tibbs: no concerns there. | |
| c4chris | +1 | |
| spot | tibbs: keep in mind that debian is using this, so its about as minimal as you can get | |
| warren | +1 | |
| tibbs | Then again, init=/bin/sh should still work. | |
| wwoods | warren: so yeah, so long as that assumption hasn't broken, I'm all for it | |
| notting | +1 | |
| spot | +1 | |
| sadmac | spot: is that true? Last I heard they were still teetering over it because "ubuntu did it" | |
| notting | nirik: post-alpha, i'm all for getting it in as soon as possible. need to get some selinux bits in mkinitrd first | |
| spot | sadmac: last time i looked they had it in the bleeding edge tree | |
| warren | wwoods, I just had imagery in my mind where initscripts ran literally backwards | |
| notting | nirik: and then sanitize policy | |
| poelcat | is that enough +1s ? | |
| jwb | notting, post-alpha is now, eh? | |
| sadmac | notting: 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 | ||
| bpepple | poelcat: I believe so, and more importantly I don't see any '-1'. | |
| nirik | yeah, +1 here. | |
| poelcat | in the interest of time... move on? | |
| notting | jwb: post-alpha means 'after we're not running around like a chicken with our heads cut off getting the alpha out' | |
| bpepple | poelcat: were there other features to discuss today? | |
| tibbs | Also, could we please get guidelines for what we should do with our initscripts to increase awesomeness? | |
| jwb | notting, 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? | |
| poelcat | bpepple 4 more if you like :) | |
| poelcat | they came in after tuesday | |
| notting | jwb: see above about selinux, etc. | |
| sadmac: no real problems, just need to do it | ||
| sadmac | notting: cool | |
| bpepple | poelcat: ah. Let's try to do one more since we're just about at the hour point. | |
| jwb | oh, i forgot you own sysvinit too | |
| nevermind | ||
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/GCC4.3 | ||
| notting | sadmac: 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? | |
| f13 | hrm, he didn't put it in the wiki | |
| sadmac | notting: works fine for me | |
| f13 | but 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 | |
| sadmac | notting: 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. ;) | ||
| f13 | so there is still the possibility of a mass rebuild of packages against gcc43, but not immediately. | |
| jwb | how long? | |
| f13 | jwb: I think he said 2 weeks~ | |
| jwb | reason ? | |
| spot | sadmac: i'll work with you on that | |
| sadmac | spot: cool | |
| spot | sadmac: i've just been buried in ... paperwork lately. | |
| sadmac | spot: lol | |
| f13 | while 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/ | |
| c4chris | I'm fine with gcc 4.3 in F9 | |
| tibbs | I 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. | ||
| c4chris | worse comes to worst, we could have a compat-gcc pkg... | |
| notting | +1 | |
| bpepple | tibbs: agreed | |
| +1 | ||
| nirik | +1 | |
| f13 | yeah, I'm +1 on the feature, just not going to schedule a mass rebuild for it this week | |
| c4chris | no kidding :) | |
| tibbs | It 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. | |
| f13 | right | |
| jakub is on the hook for that | ||
| bpepple | ok, I see five '+1' anyone else have an opinion? | |
| spot | +1 | |
| * nirik is really happy with the seperate tag and mass rebuilding testing done. Thats been great. | ||
| spot | i've still got stuff to fix, but, well, i always have stuff to fix. | |
| * nirik also has a few things to fix. | ||
| dgilmore | +1 | |
| warren | +1 | |
| c4chris | same here... | |
| warren | Is jakub back from vacation now? | |
| bpepple | poelcat: ok, it looks like we have a majority for this feature. | |
| spot | warren: i think so, yes. | |
| warren | but wait, wont we need a mass rebuild immediately upon gcc-4.3? | |
| it breaks ABI | ||
| notting | well, anyone rebuilding C++ will need to be careful | |
| poelcat | bpepple: save the others for next week? | |
| f13 | warren: jakub says we don't need one immediately | |
| bpepple | poelcat: yeah, I think that makes sense since we're already over the hour point. | |
| warren | f13, perhaps only for the C++ packages? | |
| f13 | warren: he didn't say any. | |
| warren | mm | |
| poelcat | bpepple: okay: http://fedoraproject.org/wiki/Features/Dashboard will remain updated | |
| bpepple | poelcat: great, thanks. | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | anything else to discuss before wrapping up for this week? | |
| tibbs | Lots of progress on the review queue recently. | |
| bpepple | tibbs: sweet. | |
| * c4chris needs to leave... cheers and later folks | ||
| warren needs food | ||
| warren | bbl | |
| bpepple | ok, let's wrap up then. | |
| tibbs | Also, 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!