17:30:03 <nirik> #startmeeting FESCO (2010-12-08)
17:30:03 <zodbot> Meeting started Wed Dec  8 17:30:03 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:03 <nirik> #meetingname fesco
17:30:03 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:03 <nirik> #topic init process
17:30:03 <zodbot> The meeting name has been set to 'fesco'
17:30:03 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:28 <nirik> who all is here for fesco meeting?
17:30:32 * cwickert is here
17:30:33 <mjg59> !
17:30:34 <nirik> #info kylem unable to attend.
17:30:41 * mmaslano here
17:30:41 * SMParrish here
17:30:56 * notting is here
17:33:00 <nirik> ok, lets go ahead and dive in.
17:33:14 <nirik> #topic Updates policy / Vision implementation status
17:33:14 <nirik> .fesco 351
17:33:14 <nirik> .fesco 382
17:33:15 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
17:33:18 <nirik> * Adjustments to updates policy: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container
17:33:19 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
17:33:27 <nirik> here's our weekly updates topic. ;)
17:33:39 <nirik> I've added more ideas from the test list.
17:33:59 <cwickert> blame me for not working on it, I'm just too busy
17:34:11 <SMParrish> same here
17:34:42 <nirik> So, what remains on the 2 tickets above? could we close those and open a new one for improving the process?
17:35:06 <cwickert> where is the *current* status?
17:35:27 <cwickert> I have lost the overview because we just have too many tickets and wiki pages
17:35:33 <nirik> https://fedoraproject.org/wiki/Updates_Policy
17:35:55 <cwickert> yh, you mean the policy itself, not the implematation?
17:35:58 <nirik> yeah. I am suggesting we close the 2 above... and open a new one for adjusting the existing updates policy.
17:36:20 <mjg59> Sounds good
17:36:39 * SMParrish agrees
17:36:44 <nirik> well, https://fedoraproject.org/wiki/Updates_Policy should have the current policy and what is implemented, right?
17:36:51 <nirik> if not, we should adjust it.
17:37:04 <cwickert> right
17:37:31 * mclasen things smaller, focused tickets would be good, seeing the 'updates policy' standing topic every week is becoming a bit of a drag...
17:38:09 <nirik> yeah, thats why I tried to collect all ideas from the thread in  https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container
17:38:12 * cwickert tends to agree but is afraid we loose the bug picture then
17:38:41 * nirik notes there's lots of ideas there I don't like, but I wanted to collect them all so we could see them outside the gigantic threads. ;)
17:39:24 <nirik> we don't have some things from the stable release vision still however...
17:39:28 <nirik> metrics
17:39:59 <cwickert> back to the board then?
17:40:01 <nirik> "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements."
17:40:24 <nirik> well, how about I propose in the ticket we close it and the board can tell us if they see more than must be done.
17:40:34 <mjg59> nirik: Sure
17:41:03 <notting> the other one that wasn't done was updates-features (or whatever it was called)
17:41:04 <nirik> any objections?
17:41:09 <cwickert> but what to do about the metrics. this really is an interesting topic
17:41:33 <nirik> yeah, we have some from bodhi, I think we were hoping to improve on those.
17:41:46 <nirik> perhaps I could invite lmacken next week to show us what it has currently?
17:41:51 <mmaslano> are they displayed somewhere?
17:42:04 <mmaslano> or it's only number of updates now?
17:42:05 <nirik> they run currently when he runs them I think.
17:42:13 <nirik> he's posted them in the past.
17:42:42 <nirik> http://www.mail-archive.com/epel-devel-list@redhat.com/msg03432.html
17:42:46 <nirik> was one from a while back
17:43:02 * mclasen is +1 on closing the big ticket
17:43:28 <cwickert> just a moment... it was the board that demanded metrics, right? I think we should give them a list of metrics we like to see and then tell then they need to nag the people to provide us these numbers
17:44:05 <mmaslano> not sure how these metrics say whether updates or better or not ;-)
17:44:45 <nirik> well, they wanted measurements as part of their vision statement. I can ask them to clarify/see if the bodhi stats are what they wanted.
17:44:50 <cwickert> mmaslano, that's why we would need numbers from before and after the policy change
17:45:05 <mmaslano> cwickert: sure
17:45:39 <cwickert> nirik, it is not what the board wants but what "project members" want I think
17:46:03 <nirik> well, the board vision was asking for project members to be able to see, yes...
17:46:05 <cwickert> I think the numbers are nice but not enough to tell is the policy was actually successfull
17:46:21 <nirik> yeah, so we would need to figure out what numbers would be.
17:46:26 <nirik> (if any)
17:46:32 <cwickert> I'd like to see the average days in testing or the number of stuck security updates
17:47:25 <nirik> proposal: close 351, close 382 and ask the board to re-open if they need further items for it to be considered done, open new ticket for stats/metrics and new ticket for improving/changing updates process?
17:47:46 <notting> and maybe one rfe for updates-features
17:47:47 <mjg59> +1
17:48:07 <mmaslano> +1
17:48:08 <cwickert> +1
17:48:16 <SMParrish> +1
17:48:20 <nirik> ok. Would any folks like to own any of the 2/3 new tickets? ;)
17:48:33 <mclasen> +1
17:48:44 <cwickert> I'd like to take the updates-features ticket
17:48:51 <nirik> cwickert: ok, cool.
17:49:00 <cwickert> although I'm not even sure we need to address this with a repo
17:49:21 <nirik> I can take the improving/changing updates process... I can try and cull some out of the ideas container each week to discuss?
17:49:32 <notting> cwickert: what would be the other way to do it?
17:49:40 <nirik> anyone want to take the lead on stats/metrics?
17:50:10 <cwickert> notting, for example on a yum level with an improved version of yum-plugins-security?
17:50:50 <nirik> well, I will do the above after the meeting and we can go from there...
17:51:02 <notting> given the interdependencies, and the question of then packaging multiple versions of security updates in the same repo, i don't think just categorization is practial
17:51:07 <notting> or practical, even
17:51:40 <cwickert> notting, multiple versions of security updates?
17:51:53 <nirik> something between repos.fedoraproject.org and a full updates repo might work... but hard to say...
17:52:38 <notting> you have version 2.5 in base. you release 3.4 as enhancement. and then there's a security fix that needs addressed in 3.5. what do you do?
17:53:33 <nirik> yeah, it gets complex fast.
17:53:36 <cwickert> notting, publish both in the same repo, the plugin should be ablt to do the right thing
17:53:48 <cwickert> but I agree it is a valid concern
17:54:11 <nirik> ok, shall we move on?
17:54:21 <cwickert> +1
17:54:28 <nirik> #topic Meeting time
17:54:29 <nirik> * Will 17:30UTC work moving forward?
17:54:38 <nirik> is this time going to work for folks?
17:54:51 * mmaslano is content with this time
17:55:00 <SMParrish> works for me
17:55:01 <cwickert> mjg59, can you share the results link?
17:55:02 <mjg59> Works for me
17:55:06 <mjg59> cwickert: Oh, sure
17:55:16 <mjg59> http://whenisgood.net/99a9zq/results/p585aa
17:55:21 <notting> nirik: good enough
17:55:28 <cwickert> works for me, but if I were to work in the office, I would be on the train now
17:55:44 <cwickert> hope I never have to go to the office on wednesdays
17:55:49 <nirik> :)
17:55:52 <nirik> mclasen: ?
17:55:56 <mclasen> I only have 30-45 minutes in this slot
17:56:13 <mclasen> but if it works for everybody else, it is probably best to stay with this time
17:56:26 <mclasen> and I'll timeslice with my other meeting as best as I can
17:56:28 <mjg59> I think this is about the latest in the day we can do, since otherwise we pretty much exclude mmaslano
17:56:55 <nirik> ok.
17:57:04 <nirik> #agreed will stick with this time at least for now.
17:57:05 <mjg59> And other days look worse than Wednesday in thatrespect
17:57:20 <cwickert> mmaslano, you are in my timezone, right? you have no time in the afternoon in general?
17:57:41 <mmaslano> cwickert: UTC+1
17:57:51 <cwickert> same here :)
17:58:01 <notting> i could potentially move an hour earlier if need be. but no earlier than 11:30
17:58:24 <cwickert> how about 30 minutes earlier?
17:58:34 * nirik could move earlier if everyone else wanted... but I'm often busy with dayjob first thing in the morning.
17:58:52 <nirik> #undo
17:58:52 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xe822d10>
17:59:00 <mjg59> cwickert: lunch at RH is 12-1:30, so starting at 12 isa problem
17:59:15 <mjg59> There's something wrong with my space bar
17:59:16 <cwickert> i see
17:59:43 <mjg59> cwickert: And there's not really any alternative food source in easy walking distance due to the westford office being in the middle of nowhere
18:00:03 <cwickert> ok, then lets stick with the current slot
18:00:14 <nirik> ok.
18:00:15 <mclasen> mjg59: free banana in the kitchen ?
18:00:21 <nirik> #agreed will stick with this time at least for now.
18:00:27 <nirik> moving on then...
18:00:33 <nirik> #topic #505 FPC guidelines for review
18:00:34 <nirik> https://fedorahosted.org/fesco/ticket/505
18:00:42 <nirik> 2 FPC guidelines for us to review.
18:00:50 <nirik> first: https://fedorahosted.org/fpc/ticket/38
18:01:56 <mjg59> I've no objections
18:02:02 <nirik> The dessenting vote seems to be due to kernel changelogs not having versions.
18:02:24 <nirik> but they do get populated when someone does a real build I think.
18:02:38 <nirik> I guess not always.
18:02:44 * mclasen has no opinion in this, it seems hardly worth legislating
18:02:54 * notting agrees with mclasen
18:02:57 <mjg59> Well, it's not too much of a problem to get the kernel to conform
18:03:55 <nirik> so, sure +1, revisit if it causes too much kernel maintainer pain.
18:04:12 <cwickert> sorry, but I don't understand the original FPC: "If E-V-R is left unchanged..." - how that?
18:04:26 <mclasen> if you commit a fix without building, I guess
18:04:37 * mclasen does that sometimes
18:04:44 * cwickert too
18:04:44 <mmaslano> it's common, when you have more maintainers of one package...
18:04:53 <nirik> yeah, but changelogs are per build...
18:05:03 <nirik> so build them up and have one for that build with all the changes.
18:05:14 <cwickert> right
18:05:37 <nirik> so, any objections to this? votes?
18:05:40 <mclasen> there's some tension there between changelog-per-commit and changelog-per-build, I guess
18:05:50 <SMParrish> no objections here
18:05:52 <mclasen> no objections
18:05:53 <cwickert> mmaslano, how could you have the same E-V-R? doesnt the buildsys refuse to build this?
18:06:31 <mmaslano> cwickert: in this case you don't build, just commit and leave it unbuild for new patches from others
18:07:06 <nirik> anyhow, next?
18:07:18 <nirik> Explain why rpmlint warns about executable files in %doc - https://fedorahosted.org/fpc/ticket/36
18:07:32 <cwickert> +1
18:07:52 <nirik> +1 here. no executable docs seems reasonable to me.
18:08:13 <SMParrish> +1
18:08:19 <notting> +1
18:08:19 <mjg59> +1
18:08:31 <ajax> sorry i'm late
18:08:42 <nirik> no worries.
18:08:56 <mmaslano> +1
18:08:56 <nirik> #agreed FESCo has no problem with these two FPC guidelines.
18:09:13 <nirik> #topic #508 improve the general standard of packagers/maintainers in the distribution.
18:09:13 <nirik> https://fedorahosted.org/fesco/ticket/508
18:09:18 <notting> hoo boy.
18:09:20 <cwickert> ok, now that I understood the changelog thing I'm also +1 to it
18:09:26 <nirik> notting: yeah. ;)
18:09:49 <cwickert> closed worksforme?
18:09:50 <mjg59> I don't understand the rationale behind this proposal
18:09:50 <nirik> So, there are some ideas here I think we could improve our maintainers responsibilitys page with.
18:10:02 * cwickert nether
18:10:07 <nirik> but some of the requirements are impossible or don't make sense.
18:10:22 <nirik> well, the ticket submitter is active in QA.
18:10:26 <mjg59> Is the concern that having too many packages diverts attention from important ones, or that having low quality packages is worse than having no packages?
18:10:40 <nirik> They would like maintainers to do better so the overall quality was better...
18:10:51 <nirik> mjg59: I think the latter.
18:11:03 <mjg59> nirik: Yeah, I don't think that obviously follows
18:11:25 <mjg59> So I disagree with the proposal as-is on that basis
18:11:44 <mjg59> Which isn't to say that there aren't aspects that wouldbebeneficial
18:12:32 <nirik> yeah, mandating seems a fail to me... there's no way we can require proof of upstream communication.
18:12:40 <cwickert> should we vote on the individual suggestions?
18:12:41 * mclasen_ is in another meeting now, sorry if I'm unresponsive...
18:12:44 <notting> the proposal appears to be a reaction to perceived bureacracy by ... adding more?
18:12:49 <mjg59> I think the best we can do is ensure that some of this ends up in a best practices document
18:13:02 <cwickert> notting, *good* question
18:13:17 <cwickert> +1 mjg59
18:13:37 <mjg59> And encourage people to read that as part of the packaging process
18:14:00 <nirik> yeah, I think as 'suggested' / 'best practice' the suggestions make sense.
18:14:06 <cwickert> some things could go into the package mainteiner responsibilities, but more as a SHOULD then a MUST
18:14:12 <mjg59> I'd love to see all our maintainers be capable of handling all bugs themselves (and then getting those upstream), but I think that's an unrealistic expectation
18:14:43 <notting> mjg59: to play devil's advocate, then... if it's just a 'should', what are the chances that it will actually help?
18:14:46 <mjg59> And mandating this as part of the package submission process would pretty much disqualify most of our maintainers
18:15:10 <mjg59> notting: Little. I think we need to accept that our maintainers are mostly packagers rather than developers.
18:15:20 <mjg59> Changing that sounds entirely outside fesco's remit.
18:16:06 <nirik> also, the suggestion of looking at red hat qa processes may be worth persuing, but I think a lot of the process is just going to not apply with us.
18:16:20 * Viking-Ice points out atleast try to get them to provides us with debug info on their components.
18:16:30 <nirik> hey Viking-Ice. :)
18:16:54 <notting> re: test cases, obvs we're gated on QA having a place to place them. but that's in progress.
18:16:56 <nirik> Viking-Ice: I think asking for testing info is a great idea...
18:17:33 <cwickert> notting, has QA considered testopia?
18:17:42 <nirik> cwickert: I thought it wasn't free?
18:17:45 <Viking-Ice> if they cant provide us with the information on how to debug their own package we surely wont get any testing idea from them
18:17:54 <Southern_Gentlem> cwickert,  they did then found out it wasnt free
18:18:14 <notting> cwickert: they have looked into many TCMSes, but i don't recall which ones
18:18:19 <Viking-Ice> s/idea/info/
18:18:22 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=450013
18:18:33 <cwickert> Southern_Gentlem, I thought it was MPL like bugzilla
18:19:00 <nirik> Viking-Ice: sure, and we can work to improve over time. Forcing them to provide info or you will remove their package seems like way way too much bark and not enough wag.
18:20:02 <Viking-Ice> ok so how about this requiring this for any new package introduced to the release from F15 and onwards and we try to gather this information for existing packagings?
18:20:18 <nirik> as a suggestion/note, I think it's a great idea.
18:20:28 <Viking-Ice> part of the review process
18:20:38 <cwickert> Viking-Ice, only test cases or all suggestions?
18:21:12 <Viking-Ice> those I mentioned as required
18:21:25 <nirik> well, it's not something that directly has anything to do with the package, but perhaps FPC would consider adding Should: entries for it? or Suggests: ?
18:21:49 <Viking-Ice> I would think the best way to collect this is when package gets added to the distro
18:21:50 <nirik> Or we could note it on the join page/new package process/SCM requests.
18:22:11 <cwickert> Viking-Ice, I'd say no because I connot fulfill them all. e.g. I cannot have a bugzilla account for a package that does not have any bug tracker :)
18:22:30 <Viking-Ice> than you would just point that out in the review request
18:22:33 <nirik> Viking-Ice: or perhaps qa could flag new packages as they are added, and approach maintainers then with a suggestion list?
18:22:48 <cwickert> there are packages that don't have a tracker and I have no idea how to contact upstream, but they just work
18:23:16 <notting> i think having some sort of 'how to test' as part of new package submission would be useful to collect
18:23:18 <nirik> there are also packages where upstream doesn't care/is hostile, so being in contact with them doesn't matter.
18:23:57 <Viking-Ice> ok so what about them provide how to debug and minimal information a report and test cases before package gets accepted?
18:24:06 <cwickert> sure test cases would be nice if there are people to actually run them.
18:24:46 <notting> cwickert: ? even if there aren't people now, it's much easier to have them for people to show up and pick off, rather than have people show up and not have anything to work from
18:24:48 <nirik> Viking-Ice: as a "Please help us, read $foo and provide us test cases at $bar with process $baz" I think it's great.
18:24:50 <mmaslano> the process of review is long anyway
18:25:15 <nirik> Viking-Ice: as a "you MUST do these things before your package is allowed in" I think it's not.
18:25:43 <Viking-Ice> why not if I may ask
18:26:07 <cwickert> Viking-Ice, what kind of debugging would you expect?
18:26:18 <mjg59> Because most of our maintainers would have no idea how to write such a list?
18:26:24 <nirik> well, for example, recently libreoffice was added to rawhide. If we required a comphrehensive test plan in place before it could be added, it would be F29 before we saw it.
18:26:35 <Viking-Ice> it's like stealing a candy from a baby trying to get how to debug info out the maintainers
18:26:51 <dtardon> Viking-Ice, rtfm?
18:27:03 <mjg59> We've had 15 minutes of this
18:27:09 <mjg59> Do we want to continue?
18:27:18 <cwickert> +1 to continue
18:27:20 * nirik is ok to go a bit more.
18:27:24 <mjg59> Ok
18:27:28 <nirik> I'd like to propose something tho:
18:28:03 <Viking-Ice> nirik: we need the information from that they would otherwise request reporters to provide them with these are what we usually call how to debug component
18:28:09 <nirik> proposal: ping FPC about adding should/suggestions for these in review, suggest changes to the join wiki page noting them and revisit next week.
18:28:54 <nirik> Viking-Ice: do you have an example?
18:29:24 <cwickert> Viking-Ice, I think most QA people have more test cases in mind than package owners, e.g. for a standard desktop app I never would test if "Help -> About" works
18:29:25 <Viking-Ice> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems
18:29:35 <notting> proposal #2: ping FPC about making an official review template
18:30:00 <Viking-Ice> nirik: this is what I wrote when dracut was being introduced
18:31:28 <nirik> Viking-Ice: how do you do that for a library?
18:31:54 <nirik> notting: it's been suggested a bunch.
18:32:27 <mmaslano> Viking-Ice: sorry but that can't be done for all packages. It should be voluntary
18:32:35 <nirik> any other proposals? votes on the existing ones?
18:33:11 <cwickert> lets make all points suggestions rather than preconditions and then vote on them individually
18:33:48 <nirik> cwickert: suggestions for what?
18:34:13 <cwickert> SHOULD items in a review rather than MUST
18:34:14 * nirik suspects FPC would reject adding them anywhere to guidelines.
18:35:12 <notting> well
18:35:15 <notting> stepping back
18:35:21 <notting> if none of them are must
18:35:37 <notting> does anyone object to them going on the package maintainer responsibilities as best practices?
18:35:47 <cwickert> +1
18:35:52 <mjg59> Sounds good to me
18:36:17 <nirik> I'm fine with all of them except the 'familiar with the programming lang' one.
18:36:54 <cwickert> so am I, I cannot learn vala because I own a single vala package that is a dep of others
18:37:11 <Viking-Ice> by all mean scrap it it was stretching it a bit to far..
18:37:11 <SMParrish> that one needs to go
18:37:20 <notting> nirik: i think it's fine as a best practice to be familiar with what you're packaging
18:37:52 <cwickert> as a recommendation it is ok
18:38:02 <nirik> well, to the point of getting it packaged and working, but should I have to go take a R class to package an R package?
18:38:20 <notting> cwickert: that's the point of best practices
18:38:21 <nirik> I suppose as a suggestion it might be ok if phrased right.
18:38:46 <cwickert> nirik, in a perfect wotld (tm) you should know R already ;)
18:38:52 <nirik> :)
18:39:18 <fenrus02> R is just like S ... but slightly newer.
18:39:18 <nirik> ok, so, would someone care to look at diff to the package maintainer responsibilities wiki page with these changes?
18:39:28 <notting> i'll look at it
18:39:51 <nirik> #action notting will look at folding these into the maintainers best practices.
18:40:03 <nirik> ok, do we wish to ask FPC on the other items?
18:40:27 <nirik> I guess I can ping them...
18:41:09 <nirik> sound ok => nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines?
18:41:54 <nirik> any objections? if not I will move on...
18:41:57 <cwickert> please do nirik
18:42:00 <nirik> thanks for the ticket and discussion Viking-Ice
18:42:07 <cwickert> ping FPC I mean
18:42:11 <nirik> #agreed nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines?
18:42:22 <Viking-Ice> nirik: thanks for considering this
18:42:40 <nirik> ok, we have a pile of features now.
18:42:48 <nirik> #topic #509 F15Feature: F15Boost146 - http://fedoraproject.org/wiki/Features/F15Boost146
18:42:48 <nirik> https://fedorahosted.org/fesco/ticket/509
18:42:54 <cwickert> +1
18:43:15 <nirik> +1 from me. I do think we should look at some kind of 'featurelet' or something for newer versions... but until we revamp the feature process this is fine.
18:44:00 <nirik> other votes?
18:44:02 <mjg59> +1
18:44:11 <SMParrish> +1
18:44:15 <mmaslano> +1
18:44:30 <notting> sure, +1. would be nice to not have a 'we're breaking this ABI' feature every release, but... meh.
18:44:34 <ajax> +1
18:44:38 <nirik> #agreed Feature is approved.
18:44:40 <ajax> notting: boost tbh
18:44:44 <nirik> #topic #510 F15Feature: FourkBSectorBooting - http://fedoraproject.org/wiki/Features/FourkBSectorBooting
18:44:44 <nirik> https://fedorahosted.org/fesco/ticket/510
18:44:56 <nirik> +1 here. I almost bought one of these drives the other day. ;)
18:45:02 <ajax> +1 shiny
18:45:04 <mmaslano> +1
18:45:15 <SMParrish> +1
18:45:25 <notting> +1. booting is good.
18:45:27 <cwickert> +1
18:45:47 <mjg59> +1
18:45:50 <nirik> #agreed Feature is approved.
18:45:55 <nirik> #topic #511 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3
18:45:55 <nirik> https://fedorahosted.org/fesco/ticket/511
18:45:59 <mjg59> +1
18:46:04 <nirik> oh wait... didn't we already do this one?
18:46:09 <ajax> pretty sure we did
18:46:14 <nirik> or perhaps last cycle?
18:46:26 <cwickert> I think we did it 2 weeks ago
18:46:55 <cwickert> or was it 3? I'm sure it was not last cycle
18:47:11 <nirik> yeah. Sorry.
18:47:21 <nirik> #agreed feature was already approved. ;)
18:47:27 <nirik> #topic #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice
18:47:27 <nirik> https://fedorahosted.org/fesco/ticket/512
18:47:38 <nirik> +1 here. Folks are already asking about it in #fedora.
18:47:52 <ajax> and on devel@
18:47:56 <cwickert> +1
18:48:04 * rbergeron gives a big d'oh to the gnome feature. Sorry guys :)
18:48:08 <SMParrish> +1
18:48:10 <notting> +1. although this appears pretty much already done
18:48:11 <ajax> you would think people would know to check 'koji latest-pkg dist-f15 libreoffice'
18:48:15 <ajax> +1
18:48:19 <mmaslano> +1
18:48:47 <mjg59> +1
18:48:55 * cwickert needs to leave now, please count me as +1 to maven3 and sugar 0.92
18:49:00 <nirik> ok.
18:49:05 <nirik> #agreed Feature is approved.
18:49:11 <nirik> #topic #513 F15Feature: Maven3 - http://fedoraproject.org/wiki/Features/Maven3
18:49:12 <nirik> https://fedorahosted.org/fesco/ticket/513
18:49:15 <nirik> +1 here as well
18:49:18 <cwickert> +1
18:49:20 <notting> i have to leave now too... i have votes in the tickets.
18:49:22 <notting> sorry.
18:49:29 <mmaslano> +1
18:49:37 <ajax> +1
18:50:12 <nirik> #agreed Feature is approved.
18:50:18 <nirik> #topic #514 F15Feature: Sugar 0.92 - http://fedoraproject.org/wiki/Features/Sugar_0.92
18:50:18 <nirik> https://fedorahosted.org/fesco/ticket/514
18:50:29 <nirik> +1 here too, notting and cwickert are also +1
18:50:35 <SMParrish> +1
18:50:40 <mmaslano> +1
18:50:49 <mjg59> +1
18:51:15 <ajax> +1
18:51:20 <nirik> #agreed Feature is approved.
18:51:25 <nirik> #topic Open Floor
18:51:35 <nirik> ok, anyone have anything at all for open floor?
18:52:59 * nirik will close out in a minute or two if nothing comes up.
18:53:17 <ajax> i've heard a modest amount of complaints that abrt is doing more harm than good
18:53:53 <ajax> along multiple axes, but in particular it's simply too much data for apps like firefox and evo for maintainers to respond to
18:54:22 <ajax> i don't have any particular suggestions for this (well, i do, but i'll be politic), but it's something i'd like to see discussed from the distro planning POV
18:54:44 <nirik> yeah, came up on the list recently again as well.
18:55:11 <vinzv> hi
18:56:15 <ajax> is this something people want to talk about here next week, or should it be more of a fedora-devel issue
18:56:38 <nirik> I did note that totem and rhythumbox (I can't spell that to save my life) have the vast majority of bastens bugs.
18:57:23 <nirik> I wonder if we could get abrt to have a maintainer opt out thing that would be easy to change by maintainers?
18:57:35 <nirik> right now it's blacklist is in the package itself.
18:58:18 <nirik> or if we could have them file in another place. ;(
18:59:18 <nirik> ajax: I think we should try and come up with some possible actions and discuss next week?
18:59:46 <ajax> yeah.  i'll look over the list and see if i can extract some RFE kind of material.
19:00:32 <nirik> ok, thanks. You want me to file a ticket and assign to you so we don't forget it next week?
19:00:37 <ajax> please
19:00:38 * mmaslano must leave now.
19:00:53 <ajax> there was something else that was bothering me that i wanted to bring up, but it must not have been important enough, else i'd remember.
19:01:28 <nirik> ok.
19:01:36 <nirik> Thanks for coming everyone!
19:01:40 <nirik> #endmeeting