17:30:33 <nirik> #startmeeting FESCO (2011-01-12)
17:30:33 <zodbot> Meeting started Wed Jan 12 17:30:33 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:34 <tibbs> Personally I still wish nothing would autostart and the installer would turn things on if it needs them to be on.
17:30:34 <nirik> #meetingname fesco
17:30:34 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:34 <nirik> #topic init process
17:30:34 <zodbot> The meeting name has been set to 'fesco'
17:30:34 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:31:05 <nirik> who all is around for meeting?
17:31:09 <mjg59> \o/
17:31:10 * notting is
17:31:45 * mclasen is here for a change
17:32:02 <notting> kylem and cwickert will not be here
17:32:25 * mmaslano here
17:33:41 <nirik> ok, lets go ahead and drive in I guess...
17:33:57 <nirik> #topic #516 Updates policy adjustments/changes
17:33:58 <nirik> .fesco 516
17:33:59 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516
17:34:09 <nirik> I had 2 new items pulled from the ideas bin this week...
17:34:26 <nirik> #info idea: reduce timeout for non critpath from 7 to 3 days.
17:34:41 <nirik> My thoughts on this one are in the ticket... what do other folks think?
17:34:48 <notting> too short.
17:35:15 <nirik> yeah, thats my thought. It takes a while to wind it's way to the end testers.
17:35:15 <mmaslano> do we have statistics about these updates?
17:35:25 <mmaslano> are they tested at all?
17:35:29 <mclasen> yeah 'we don't get enough testing so lets reduce the testing time' seems counterintuitive
17:35:32 * cwickert is actually here but can only lurk from his hospital bed and might leave any moment soon
17:35:32 <mjg59> Yes, I don't think 3 days is workable
17:35:50 <nirik> mmaslano: the only stats we have is the stuff from bodhi in the other ticket... but yeah, more info would be good.
17:36:01 <nirik> ok, so I am -1 to this. other votes?
17:36:02 <mclasen> cwickert: nothing serious, I hope ?
17:36:14 <nirik> cwickert: make sure and take it easy...
17:36:22 <mjg59> -1
17:36:37 <cwickert> mclasen: hopefully not so serious to prevent me to come to fudcon
17:37:06 <mclasen> -1
17:37:08 <SMParrish> I'm here  sorry I'm late
17:37:26 * notting makes his -1 official
17:37:31 <ajax> -1
17:37:41 <SMParrish> -1
17:37:51 <nirik> #agreed this idea is rejected for now.
17:37:54 <nirik> The other one was:
17:38:03 <nirik> #info idea: change default autokarma to 2 or 1.
17:38:12 <nirik> This would change the default in bodhi to 1 or 2 karma needed for non critpath updates to promote to stable. Currently this value is 3, and many maintainers leave it that way.
17:38:32 <nirik> so this is just changing a default. However it may lead to less testing.
17:39:19 <mjg59> 1 sounds like an amazingly bad idea
17:39:24 * nirik is a slight -1 on this one.
17:39:25 <SMParrish> I agree
17:39:27 <mjg59> I'd prefer to stay at 3
17:39:56 <notting> i often set it to 2 for non-critpath things
17:40:03 <nirik> mjg59: well, the maintainer can already set it to 1 if they want.
17:40:21 <mjg59> Well, I'd prefer that that not be possible either, but still :)
17:40:34 <nirik> ok, so any votes here?
17:40:41 <SMParrish> -1
17:40:45 <mmaslano> -1
17:40:47 <ajax> this all still sounds like "i don't like testing so let's have less of it"
17:41:16 <ajax> which, no.
17:41:18 <ajax> -1
17:41:32 <nirik> #agreed this idea is rejected for now.
17:41:44 <nirik> ok, I'll try and pick some next week that we might like... ;)
17:42:05 <nirik> #topic #515 Investigate a "features" repo for stable releases
17:42:05 <nirik> .fesco 515
17:42:07 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
17:42:12 <nirik> I don't think there is any news here...
17:42:42 <nirik> there was some interest on the list.
17:42:52 <nirik> I think I will try and ask the interested folks to write up ideas. ;)
17:43:09 * nirik will move on in a min if nothing on this topic.
17:43:20 <abadger1999> Are ideas needed or implementation proceedure needed?
17:43:36 <nirik> abadger1999: either.
17:43:52 <nirik> basically a list of thoughts on how we could implement this so we could choose one or decide none of them will work.
17:44:15 <abadger1999> <nod>
17:44:31 * mclasen may have missed some prior discussion on this
17:44:38 <mclasen> how does this relate to the koper ideas ?
17:44:44 <nirik> it could be very related.
17:44:45 <abadger1999> mclasen: Entirely separate.
17:44:49 <mclasen> hehe
17:44:52 <nirik> ha. ;)
17:45:20 <nirik> well, this is just a 'lets try and figure out how to get new versions into our users hands that wish them while still leaving the main stream stable'
17:45:25 <abadger1999> So to me: copr is unofficial, un-QA'd, etc.
17:45:38 <nirik> so, we could say "sorry, no features repo, you need to get them from copr's"
17:45:49 <abadger1999> Can contain things that haven't been reviewed for Fedora ; may conflict with other coprs/main fedora repo.
17:46:04 <mclasen> I guess coprs are a development tool, which this is meant to be an end user tool
17:46:15 <nirik> right.
17:46:32 <nirik> #info Folks needed to write up a ideas container and implementation details.
17:46:39 <abadger1999> A Features Repo would be like a rolling release layer for leaf node packages that tries to make some of the same promises as Fedora itself -- at least:
17:46:52 <abadger1999> Pakcages havepassed Fedora review and it won't conflict internally.
17:47:28 * abadger1999 agrees with mclasen's summary.
17:47:36 <nirik> abadger1999: yes, but details: different branches? how to handle security updates? conflicts with updates repo? what can be in it, everything?
17:47:47 <nirik> so, we need to look at details and see if we want to implement this or not.
17:48:01 <abadger1999> <nod>
17:48:14 <nirik> ok, any more thoughts on this? or shall we move on?
17:48:31 <gholms> "Use at your own risk?"
17:49:15 <nirik> #topic #517 Updates Metrics
17:49:16 <nirik> .fesco 517
17:49:16 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517
17:49:24 <nirik> No news here as well I don't think.
17:49:37 <nirik> we have the bodhi stats here, but need to decide what others we should try and gather.
17:49:47 <nirik> #info Folks needed to help gather stats.
17:49:58 <nirik> Anything on this? or shall we move on?
17:50:05 * mclasen has nothing
17:50:21 <nirik> #topic #518 Abrt
17:50:22 <nirik> .fesco 518
17:50:26 <nirik> ajax: any news here?
17:50:34 <zodbot> nirik: #518 (Abrt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/518
17:50:57 <nirik> ah, looks like they are hoping to send a roadmap soon.
17:51:39 <nirik> actions to take here?
17:52:20 <mclasen> discuss at fudcon ? do we know if abrt will be represented there ?>
17:52:36 <mmaslano> I heard jmoskov will go there...
17:53:07 <nirik> cool. sounds good.
17:53:11 <ajax> yeah, fudcon seems to be the plan
17:53:30 * mclasen will not be at fudcon, of course... :-(
17:53:42 <nirik> #info will hopefully talk with abrt folks at fudcon and look at roadmap
17:53:47 <nirik> mclasen: :(
17:53:58 <ajax> likewise, i'll be at LCA
17:54:02 <mjg59> Ditto
17:54:14 <nirik> ah yeah.
17:54:25 <nirik> ok, moving along...
17:54:30 <nirik> #topic #521 Reconsider RemoveSUID feature
17:54:30 <nirik> .fesco 521
17:54:31 <zodbot> nirik: #521 (Reconsider RemoveSUID feature) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/521
17:54:31 <pjones> ... which isn't canceled yet, even though the venue is under water.
17:54:39 <ajax> assuming brisbane hasn't fallen into the ocean by then, yeah
17:54:41 <nirik> pjones: hopefully it will be dried out by then.
17:54:54 <nirik> so, we have an upstream submitted kernel patch for tmpfs.
17:54:57 <notting> lca... on a boat?
17:55:18 <skvidal> notting: too soon
17:55:24 <mjg59> No feedback yet, but the patch looks straightforward enough
17:55:46 <nirik> would that possibly be something our kernel folks would carry? or would want to wait for upstream?
17:56:29 <nirik> and what do we want to do with this feature?
17:56:35 <mjg59> I think we'd probably want some feedback from upstream, but I'd expect us to carry it before upstream as long as reception looks promising
17:56:58 <mjg59> In the absence of any other observed breakage, I think this seems sufficient
17:57:23 <notting> mjg59: it does mean that if you want to use tmpfs in your build host, you have to be running fedora-latest. which isn't the best
17:58:20 <nirik> yeah, lots of builder stuff will be el5/6 or fedora-older
17:58:28 <ajax> yeah.  between that and still having not nearly enough capabilities to really tie anything down, i kind of want to drop this feature for a while.
17:59:13 <mjg59> notting: It's not ideal, no, but the alternative is to put the kernel support in F15 and then wait for *every* builder to be updated before we can ship the feature
17:59:31 <mjg59> And that sounds like a really unfortunate situation
17:59:44 <nirik> how painfull would reverting be? lots of package churn for things that have already been changed?
17:59:56 <ajax> it's unfortunate to the extent that the feature itself wins us anything.
18:00:09 <gholms> So not really?
18:00:15 <ajax> i've been pretty well convinced it doesn't win us much, if anything.
18:00:21 <mjg59> I think the feature wins us things. I don't think it necessarily wins us *big* things, but I don't see that as a reason to block it
18:00:37 <gholms> mjg59: Are the gains greater than the losses?
18:00:43 <mjg59> gholms: What are the losses?
18:00:59 <gholms> mjg59: Inability to build f15 packages on f14, f13, and el6.
18:01:05 <gholms> …with tmpfs, at least
18:01:25 <mjg59> gholms: I think we'd have no problem in backporting this to f13 and f14
18:01:38 <gholms> How about el6?
18:01:39 <ajax> if our builders weren't runing rhel, that'd be compelling.
18:01:49 <mjg59> el6 is a different story, and el5 is definitely a different story
18:02:04 <nirik> our builders don't need/use tmpfs.
18:02:18 * mclasen was about to ask that
18:02:19 <nirik> this is package reviewers and mdomsch's mass rebuilding.
18:02:31 <nirik> (at least that was my understanding of who was affected)
18:02:36 <tibbs> FYI, as one of the complainers, I'm happy to run rawhide or patched kernels.
18:02:46 <tibbs> And I recall that mdomsch was OK with that as well.
18:02:58 <tibbs> I did ask him specifically if that was a problem for him.
18:03:01 * gholms wonders if he can convince his employer...
18:03:13 <mjg59> Ok, so I don't see this feature as having demonstrable losses
18:03:35 <mjg59> Demonstrable gains? Well, we'll have to wait and see.
18:04:10 * nirik is fine with it staying, but like ajax I am not sure how much gain there is. Perhaps more down the road?
18:04:36 <ajax> the lack of demonstrable gains makes me inclined to revert the feature
18:04:57 <ajax> which might be post-rhel trauma talking, but, don't change shit just for fun. make it better.
18:04:57 <mjg59> ajax: I don't think we have any technical basis to do so
18:05:16 <ajax> sure we do.
18:05:42 * nirik is a slight +1 for keeping the feature for f15. Should we vote?
18:05:45 <ajax> in the absence of evidence we can't consider it an improvement.
18:05:58 <ajax> that's all the basis i need.
18:06:08 <mjg59> ajax: Which would argue in favour of not presenting it as a feature, not for reverting the changes
18:06:43 <ajax> if we do keep the feature we have to document it
18:06:45 <mjg59> I don't think we want to stop people from working on something they think will help if our only argument is "I'm not convinced this will be beneficial"
18:06:59 <ajax> otherwise admins aren going to assume that privilege means s[ug]id or not.
18:07:23 <mjg59> They've JFDI, and gone beyond the scope of the feature in order to support some edge use cases
18:07:38 <mjg59> I think that's behaviour we should reward, not revert
18:07:43 <ajax> the feature process is (currently) how we get those documented, so i don't think "not presenting it as a feature" is an option
18:08:14 <ajax> we can leave it in, and i don't really have a problem with that beyond that it's a change with no benefit right now.
18:08:24 <mclasen> we have plenty of those...
18:08:33 <ajax> if this were my show, that wouldn't happen.
18:08:43 <gholms> Then vote that way.
18:09:12 <mjg59> I agree that there are flaws with the way we present changes
18:09:18 <ajax> yeah, pretty much.  anyway, not going to change anyone's mind at this point i suspect.
18:09:35 <mjg59> But I don't think we should let those flaws prevent people from doing things
18:10:27 <ajax> right.  two issues: the feature itself, and Features.
18:10:46 <mjg59> We should have mechanisms for ensuring that changes are documented
18:10:51 <nirik> so, any further discussion? or should we vote here? or we want to gather more info?
18:11:09 <mjg59> nirik: I'm +1 conditional on that patch (or something like it) receiving positive upstream feedback
18:11:49 <ajax> within the feature framework we've got, i agree with mjg59
18:12:03 <nirik> yeah, +1 here with the patch...
18:12:11 <mmaslano> yes, +1 with patch
18:12:41 <notting> +1 with the patch, needs reverted w/o the patch.
18:13:03 <nirik> #agreed provided the patch gets positive feedback upstream/lands in fedora kernels, we would be ok with keeping the feature.
18:13:17 <nirik> #topic #539 Meeting with the Board regarding strategic goals
18:13:17 <nirik> .fesco 539
18:13:18 <zodbot> nirik: #539 (Meeting with the Board regarding strategic goals) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/539
18:13:32 <nirik> The Board would like to meet up with fesco on setting goals.
18:13:57 <nirik> They have proposed: meeting slot on 1/24 at 2PM eastern
18:14:13 <notting> wfm
18:14:14 <nirik> who can/cannot make that? or should we try and come up with another time? or ?
18:14:23 * mmaslano probably not
18:14:25 * mclasen will have an hour
18:14:30 <mjg59> No, can't make that week
18:15:29 <ajax> also can't make it
18:15:30 <nirik> should we try a whenisgood? or just live with that some of us can't make whatever time/day.
18:15:43 <mjg59> nirik: I think that's an especially bad week
18:15:50 <mjg59> And we should try to work something out for the following one
18:15:52 <SMParrish> I can make it
18:16:03 <ajax> i can't make the following one either
18:16:11 <notting> can they move it up to next week sometime?
18:16:14 <nirik> The following one is the end of fudcon. ;)
18:16:27 <nirik> 17th?
18:16:28 <ajax> however i trust fesco to represent fesco, so don't consider me a scheduling concern
18:16:47 <mmaslano> friday evening is not good time any week ;-)
18:17:24 <nirik> mmaslano: this would be monday...
18:17:43 <mjg59> I can do the 17th
18:18:12 <mclasen> 17th works here too
18:18:16 <mmaslano> nirik: thanks ;-)
18:18:36 <nirik> 17th would be ok with me too.
18:18:42 <mmaslano> ok
18:19:26 <SMParrish> I cant make the 17th
18:20:46 <nirik> so, what shall we do here? shall I ask the board if we can do the 17th? and if not just do the 24th?
18:21:11 <nirik> or we could invite them to our usual slot next week and devote some time in our meeting?
18:22:01 <mjg59> Any of these work for me
18:22:08 <notting> if we're taking our normal slot, i'd want to reserve more than just 'some time'
18:23:12 <nirik> yeah, I don't know how much other business we will have next week...
18:23:26 <nirik> ok, how about we take scheduling to the ticket?
18:23:29 <mjg59> Ok
18:23:38 <nirik> I'll ask the board and we can go from there as to who can/cannot make it?
18:24:12 <nirik> Any objections?
18:24:45 <mclasen> no, sounds good
18:24:50 <nirik> #info will work with the Board in the ticket to determine scheduling.
18:25:09 <nirik> Anyone have any general thoughts on the ideas? or should we just all save them for when talking with the Board?
18:25:50 <ajax> nothing from me.
18:26:06 <mmaslano> general ideas are quite good, I'd like to change examples...
18:26:26 <nirik> yeah, lots of area for discussion for sure.
18:26:33 <nirik> ok, shall we move on?
18:27:01 <mjg59> Sure
18:27:20 <nirik> #topic #540 F15Feature: Robotics Suite - https://fedoraproject.org/wiki/Features/RoboticsSuite
18:27:20 <nirik> .fesco 540
18:27:22 <zodbot> nirik: #540 (F15Feature: Robotics Suite - https://fedoraproject.org/wiki/Features/RoboticsSuite) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/540
18:27:57 <notting> didn't we do this once?
18:28:00 <mjg59> Seems fine
18:28:01 <nirik> These folks wanted to do a spin, but with spins kinda in flux, they would at least like a feature.
18:28:10 <notting> sure then. +1
18:28:11 <nirik> notting: I think there was discussion about the spin part.
18:28:33 <mmaslano> +1
18:28:43 <nirik> yeah, +1 from me. The 20% is a bit worrysome, but hopefully they will be able to get stuff done.
18:29:05 <mjg59> +1
18:29:50 <ajax> +1
18:29:52 <nirik> one more vote? ;)
18:29:55 <mclasen> +1
18:29:59 <SMParrish> +1
18:29:59 <nirik> #agreed Feature is approved.
18:30:07 <nirik> #topic #541 F15Feature: Tryton - http://fedoraproject.org/wiki/Features/Tryton
18:30:07 <nirik> .fesco 541
18:30:08 <zodbot> nirik: #541 (F15Feature: Tryton - http://fedoraproject.org/wiki/Features/Tryton) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/541
18:30:50 <ajax> sure, why not.  +1
18:31:00 <mmaslano> +1
18:31:02 <SMParrish> +1
18:31:05 <notting> +1
18:31:10 <mjg59> +1
18:31:15 * nirik isn't sure many people would run their business software on a fedora box, but might be good for developing it I suppose.
18:31:20 <nirik> so, sure, +1
18:31:25 <nirik> #agreed Feature is approved.
18:32:05 <nirik> the next ticket was filed just a bit after I sent out the agenda, but I followed up with it...
18:32:09 <nirik> #topic #542: Updates exception request: calibre for f13/f14
18:32:09 <nirik> .fesco 542
18:32:10 <zodbot> nirik: #542 (Updates exception request: calibre for f13/f14) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/542
18:32:18 * nirik will recuse himself from voting on this. ;)
18:33:23 <SMParrish> After requesting the same for KDE how can I say no :)  +1
18:33:24 <mclasen> sounds like it had sufficient testing, so +1 from me
18:33:29 <mmaslano> +1
18:33:38 <mjg59> +1
18:34:00 * nirik really wants the abrt reports to stop.... but I could just backport that fix. But all the new readers and bugfixes are worth the update.
18:34:36 <ajax> +1
18:34:43 <notting> seems reasonable. +1
18:34:45 <nirik> #agreed exception approved.
18:34:47 <nirik> Thanks.
18:35:02 <nirik> One final ticket... which may be time sensitive, so we should at least look at it now:
18:35:08 <nirik> #topic #543exception to untag ghc-7.0.1-3.fc15 from dist-f15
18:35:08 <nirik> .fesco 543
18:35:09 <zodbot> nirik: #543 (exception to untag ghc-7.0.1-3.fc15 from dist-f15) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/543
18:35:21 <nirik> latest ghc broke the ghc* world in rawhide.
18:36:13 <mjg59> The breakage basically means that nothing could have been built against it, right?
18:36:39 <notting> it was implied that a rebuild fixes the breakage
18:36:57 <mjg59> Wurgh. Has anyone done so?
18:37:06 <notting> don't know
18:37:23 <mjg59> If the desire is for it to have the old ABI then anything that's been rebuilt is going to have to be rebuilt again anyway
18:37:33 <mjg59> So we're possibly better off breaking it all now
18:37:51 <nirik> Its not clear to me that the cause of the breakage is known.
18:37:57 <nirik> juhp: you aren't awake are you?
18:38:04 <ajax> i'm a little displeased that this happened, since it implies the person who did the build didn't try a local build+install before rawhiding it
18:38:21 <notting> unless the local build didn't show the issue
18:38:34 <ajax> true.  though, weirder.
18:38:58 <nirik> so, I am not sure we have enough info here...
18:39:49 <mjg59> I'm not sure that untagging can make things worse than they currently are
18:39:54 <nirik> so, ask for more and vote in ticket/on irc later? or do folks want to vote now?
18:40:20 <nirik> can we figure out how many things rebuilt against the new one?
18:40:37 <mclasen> isn't the easiest way out to admit we messed up and bump epoch ?
18:40:45 <ajax> we should be able to, it's not different than figuring out what buildroots had a bad gcc.
18:41:15 <mmaslano> I agree with mclasen, it's usually solved by epoch
18:42:04 <ajax> there may also be a way out without epoching, if a new build can be produced with the right hashes.
18:42:05 <nirik> I think the issue is that the breakage is not known, so a fixed package cant be produced at this time.
18:42:17 <nirik> so, they want to remove the broken one for now until they can fix it.
18:42:18 * notting backspaces, points at what nirirk said
18:42:51 <ajax> if there's any possibility that someone installed the new (broken) ghc, i'd really rather not untag
18:44:09 <nirik> it's not clear to me that they could have, unless they didn't have any other ghc depending packages installed.
18:44:58 <SMParrish> I am leaning towards the untag.  Since this is rawhide it makes sense
18:45:54 <nirik> so, shall we vote here? or gather more info voteinticket?
18:46:58 <ajax> -1 to untagging
18:47:17 <mmaslano> -1 untag
18:47:23 <mclasen> -1 too
18:47:51 <nirik> I don't feel I have enough info currently to vote for untagging.
18:48:07 <mjg59> Ok, I think asking for more information is reasonable
18:48:10 <notting> -1, i guess. i'll ask some more questions in the ticket
18:48:33 <ajax> i could be convinced for untagging but right now i'm not.
18:48:55 <nirik> #agreed No untagging at this time.
18:49:01 <nirik> revisit in ticket if info warrents it?
18:49:05 <ajax> sure.
18:49:30 <nirik> #topic Open Floor
18:49:35 <nirik> ok, anything for open floor?
18:50:48 * nirik listens to crickets.
18:50:53 <nirik> ok, thanks for coming everyone!
18:50:58 <nirik> #endmeeting