19:30:01 <nirik> #startmeeting FESCO (2010-07-06)
19:30:01 <zodbot> Meeting started Tue Jul  6 19:30:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:27 <kylem> g'afternoon.
19:30:40 <pjones> morning, sunshine.
19:30:41 <bioinfornatics> .fas bioinfornatics
19:30:41 <nirik> #info cwickert and mclasen are unable to attend today and have added votes/comment to ticket items.
19:30:41 <zodbot> bioinfornatics: bioinfornatics 'MERCIER Jonathan' <bioinfornatics@gmail.com>
19:30:49 <SMParrish> Afternoon all
19:31:02 <bioinfornatics> evening here :)
19:31:23 <ajax> come on party people
19:31:25 <mjg59> Afternon
19:32:32 <nirik> ok, lets go ahead and get started I guess.
19:33:03 <nirik> lets go ahead and do the updates items at the end, so we have more time...
19:33:17 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13
19:33:18 <nirik> .fesco 387
19:33:19 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387
19:33:22 <nirik> kylem: any news here?
19:33:58 <cjb> (hi)
19:34:01 <kylem> no, i got sidetracked and haven't poked the binutils people yet. i'll do that after the meeting.
19:34:21 <nirik> ok, then next week? or update the bug when you have news?
19:34:38 <kylem> will update after, yes.
19:35:36 <nirik> cool.
19:35:46 <nirik> #topic #412 Non-responsive maintainer (ixs); request fast-track orphaning of libsndfile
19:35:46 <nirik> .fesco 412
19:35:48 <zodbot> nirik: #412 (Non-responsive maintainer (ixs); request fast-track orphaning of libsndfile) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/412
19:36:21 <notting> at least we know where he is
19:37:15 <nirik> yeah, he was on irc and I talked with him the other day.
19:37:23 <nirik> he says he's just very busy.
19:37:26 <notting> wait
19:37:33 <notting> i'm confusing ixs with ignacio. don't mind me.
19:37:51 <nirik> I'd be inclined to try and catch him again in the next few days and see if he can add co-maintainers at least.
19:38:25 <notting> but if he's around enough to talk to on irc, i'd like to get his opinion
19:40:23 <nirik> proposed: I will try and contact him for the next few days, if no answer in a few days, we re-assign this package at least?
19:40:30 <notting> +1
19:40:31 <mjg59> +1
19:40:34 <SMParrish> +1
19:41:01 <kylem> +1
19:41:11 <nirik> cwickert was +1 to allowing reassign in the ticket.
19:41:35 <pjones> sure, why not.
19:41:36 <pjones> +1
19:41:42 <nirik> #agreed nirik will try and contact ixs one last time, will reassign libsndfile if no response in a few days.
19:41:55 <nirik> #topic #409 Feature Request: GNUstep
19:41:55 <nirik> .fesco 409
19:41:57 <zodbot> nirik: #409 (Feature Request: GNUstep) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/409
19:42:06 * nirik has to step away for a sec. brb
19:43:33 <gholms|work> [a cricket chirps in the distance]
19:43:41 <mjg59> The release notes need rewriting
19:44:26 <notting> but ideally the beat writer can fix that
19:45:44 <mjg59> Well, I think there's some factual inaccuracy there as well
19:45:51 <mjg59> It's not "The open source version of Nextstep"
19:45:59 <mjg59> It's "An open source reimplementation of Nextstep"
19:46:19 <mjg59> The former implies that there's some direct relationship between them
19:46:22 <pjones> yeah
19:47:13 <mjg59> But other than that, it's fine
19:47:35 <ajax> i mean, to the extent that gnustep is fine at all.
19:47:37 <notting> i'm mildly concerned about it being somewhat contrary to 'be on the leading edge of f/oss technology'
19:48:16 * nirik is +1 here
19:48:34 <pjones> notting: you think it might be the trailing edge?
19:48:36 <mjg59> Wait, hang on
19:48:44 <mjg59> gnustep-base has been around since F10
19:49:05 <mjg59> What's actually new here?
19:49:59 <nirik> there has been some part of gnustep in for a long time... but I thought this was to provide sessions, etc.
19:50:27 <mjg59> Doesn't look like it
19:50:38 <mjg59> Looks more like a development environment than a session
19:50:46 <nirik> ok, perhaps we defer a week and add comments to the ticket/wiki talk page/
19:50:47 <nirik> ?
19:50:58 <mjg59> I'm +1 to that
19:51:02 * mjg59 goes to comment
19:51:13 * notting agrees. +1
19:51:16 <pjones> yeah
19:51:16 <nirik> fine with me... next week is the deadline...
19:51:16 <pjones> +1
19:51:19 <SMParrish> +1
19:51:33 <nirik> #agreed defer a week to ask questions in the ticket / wiki page
19:51:34 <ajax> +1 defer
19:51:35 <mjg59> Also, the feature page is from the F13 cycle
19:51:41 <kylem> +1 from me.
19:51:48 <kylem> to deferring until next week
19:51:50 <mjg59> Not intrinsically an issue, but.
19:52:12 <nirik> ok, moving on.
19:52:14 <nirik> #topic #410 F14Feature: http://fedoraproject.org/wiki/Features/D_Programming
19:52:15 <nirik> .fesco 410
19:52:16 <zodbot> nirik: #410 (Feature: D programming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/410
19:52:48 <ajax> i'm all about deprogramming.
19:53:24 <pjones> I'm +1 on this in the sense of "oh, why the hell not?"
19:53:41 <nirik> bioinfornatics is the feature owner if anyone has questions.
19:54:16 <kylem> +1 on this feature, seems like not a big deal.
19:54:19 <pjones> which is at least a clever username.
19:54:21 <ajax> +1
19:54:29 <nirik> I'm +1 here.
19:54:32 <mjg59> +1
19:54:34 <SMParrish> I'm good with it +1
19:54:52 <ajax> i don't think D is a "moderm" language though
19:55:09 <pjones> trailing edge again, eh?
19:55:18 <nirik> #agreed Feature is approved.
19:55:37 <notting> +1. not thrilled about the tango namespace collision, but, eh.
19:55:47 <nirik> any other questions here? will move on if not...
19:55:52 <tibbs> BTW, does anyone see it odd that D include files go in /usr/include?
19:56:14 <ajax> if they're not C source, yes, that's weird and probably broken.
19:56:15 <pjones> tibbs: odd but not necessarily intrinsically any weirder than any 2 C libraries going there?
19:56:28 <kylem> c++ header files go in /usr/include too, and they can't be used by a c compiler...
19:56:37 <bioinfornatics> /usr/include/d
19:56:40 <pjones> it seems like an unfortunate choice, but not necessarily wrong.
19:56:54 <ajax> if they're under d/ i'm fine with it
19:56:59 <mjg59> The FHS says that C headers must go in /usr/include, but doesn't say that *only* C headers must go there
19:57:02 <tibbs> I think it's a bad choice but not voting.
19:57:34 <nirik> where would be better?
19:57:43 <nirik> bioinfornatics: are they platform independent?
19:57:44 <pjones> /usr/exclude, obviously.
19:58:03 <tibbs> If C didn't get a big exception due to history, where would they go?
19:58:04 <pjones> /usr/share/d/include/ might be nicer, but whatever.
19:58:10 <gholms|work> Don't C++ headers go in /usr/include/c++?
19:58:25 <ajax> gholms|work: no, they pretty much go right into /usr/include
19:58:26 <tibbs> IRC eats anything with a leading slash, dammit.
19:58:38 <ajax> which is sort of a special case since C++ claims to be a C superset
19:58:40 <pjones> gholms|work: at least some of them do, but not all.
19:58:43 <ajax> and D doesn't really
19:59:16 <bioinfornatics> no platform dependent
19:59:17 <nirik> anyhow, that seems like we are getting off track. Please comment on that in the review bug?
19:59:23 <tibbs> It's been approved.
19:59:33 <ajax> oh gross.
19:59:34 <pjones> anyway, I don't really see that we need to start a crusade against that here and now.  If they don't break other headers, it doesn't make much difference.
19:59:37 <tibbs> The reviewer didn't seem to look or care.
19:59:37 <ajax> yeah, review ticket.
20:00:14 <nirik> tibbs: ;( I guess file a bug against the package then?
20:00:22 <nirik> on to the next programming language?
20:00:25 <nirik> #topic #413 F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming
20:00:26 <nirik> .fesco 413
20:00:27 <zodbot> nirik: #413 (F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/413
20:00:43 <pjones> go fish
20:01:50 <ajax> this doesn't seem to have decided which compiler they're going to ship.
20:02:00 <ajax> seems like a big thing to not know
20:02:00 <nirik> yeah, says 'or' there
20:02:26 <notting> and the gcc version isn't upstream yet?
20:03:00 <pjones> well, we can give them 7 more days and see how far they get...
20:03:03 <SMParrish> I would like to see a decision on the compiler b4 we approve it
20:03:29 <kylem> SMParrish, i agree.
20:03:32 * nirik nods.
20:03:43 <notting> i agree. so, defer?
20:03:44 <kylem> i suspect the gcc maintainers will not be keen on patching in a new frontend. :)
20:03:46 <mjg59> Yeah, let's defer to next week
20:03:48 <nirik> +1 to defer and ask for more specifics.
20:04:01 <nirik> can someone update the ticket with questions about which compiler?
20:04:04 <kylem> so i suspect it's the other one, or F-15.
20:04:33 <SMParrish> nirik: I can update the ticket
20:04:41 <nirik> SMParrish: thanks.
20:04:46 <kylem> SMParrish, thanks!
20:04:48 <notting> oops
20:04:50 <notting> i just did
20:05:00 <SMParrish> notting: lol np
20:05:09 <pjones> +1 for letting them spend another week and then seeing how far they may or may not get.
20:05:43 <nirik> ok, moving on then...
20:06:11 <nirik> #agreed will defer a week to ask which compiler will be used and more info from feature owners.
20:06:19 <nirik> #topic #351 Create a policy for updates - status report on implementation
20:06:19 <nirik> https://fedorahosted.org/fesco/ticket/351
20:06:35 <kylem> i've got to nip off for ~15. sorry. :/
20:07:02 <kylem> brb.
20:07:08 <nirik> ok, so we have several parts landed now in production... just lacking autoqa and a 1 week in testing requirement (afaik)
20:07:21 <nirik> there have been several questions coming up on how the karma does or should work.
20:07:53 <nirik> should all positive karma be required?
20:08:07 <SMParrish> It also appears this blindsided some people as well based on what I read on the mailing list
20:08:12 <nirik> adamw: that was a question from you I think.
20:08:39 <nirik> SMParrish: yeah, I was hoping to send an announcement on it, but it landed and lmacken sent out the announcement. ;)
20:09:05 <nirik> jlaska: any news on a possible timeline for autoqa?
20:10:08 <nirik> I guess what I would love to see is a breakdown of what the bodhi code says for karma, summarized on a wiki page or faq entry.
20:11:08 <nirik> so, do we want to look at answering what negative karma means? or get an idea on how it's handled now first?
20:11:43 <adamw> nirik: thanks for the ping
20:12:17 <adamw> and yes, i think it would useful both a) to know exactly what it does right now and b) have an active idea about what it *ought* to do
20:12:25 <nirik> I guess I can say for sure that +2 is required for critpath currently... so -1, +1, +1 == 1 and doesn't push.
20:12:29 <pjones> nirik: hard "no negative karma" restrictions seem ill advised -- you've seen what people file in bugzilla sometimes, imagine what they'll do with a *lower* barrier to entry.
20:12:45 * nirik nods. Think of the kernel. ;(
20:13:00 <notting> however, we might want to weigh -1 from proventester higher
20:13:01 <jlaska> nirik: Hi there ... unfortunately concrete dates yet.  I have a revised autoqa package dependency map being reviewed and wwoods has revamped the autoqa TRAC roadmap to have a focus on the package update acceptance plan.  Please keep me on the list for next week, wwoods and I will catch up later this week to nail down some dates.
20:13:01 <adamw> i would focus on negative karma from proventesters
20:13:16 <pjones> that might be better.
20:13:17 <adamw> i'm not sure we want to accept updates with +2, -1 from three proventesters. especially if the -1 comes after the +2.
20:13:20 <SMParrish> IMO no negative is not feasible, but would like to see someone else test what triggered the negative and comment
20:13:28 <lmacken> nirik: I'll write some stuff up in the wiki about how the current system works
20:13:41 <nirik> lmacken: that would be most welcome.
20:13:54 <nirik> adamw: what if it came before?
20:14:03 <nirik> and the cause was fixed as confirmed by the last 2?
20:14:14 <adamw> nirik: we're back at 'karma sucks', aren't we =)
20:14:22 <nirik> yes indeed.
20:14:41 * adamw certainly doesn't have all the answers
20:14:44 <nirik> I think we should try and make it as uncomplicated as possible... it's already too confusing.
20:15:15 <adamw> perhaps we could say that *automatic* pushes should be disallowed for packages with negative karma from a proventester?
20:15:44 <adamw> at least it'd then require a manual submission for the update to go out, so the maintainer would've had to have seen the negative feedback and have a reason (one would hope) for disregarding it. dunno.
20:16:01 <nirik> or 'any -1 turns off karma automotism (or however you speel that)'
20:16:13 <lmacken> adamw: I think that's a reasonable idea
20:16:14 <kylem> back, sorry.
20:16:14 <SMParrish> adamw: I like that idea
20:16:30 <nirik> or yeah, proventester... sure.
20:16:54 <kylem> we need metakarma. :P
20:17:07 <adamw> kylem: well, proventesters is essentially intended to provide that
20:17:12 <nirik> proposal: lmacken writes up what the exact logic currently is. Next week we visit that and see what changes we would like to make?
20:17:27 <pjones> sounds good.
20:17:30 <adamw> kylem: but it's not just a case of making sure testers are 'good' (both competent and not evil); testers inevitably have different experiences
20:17:31 <pjones> +1 to nirik's proposal.
20:17:42 <notting> +1 to nirik
20:17:47 <adamw> a bug might just not appear for one tester but does appear for another, given the circumstances.
20:17:49 <adamw> +1 to nirik too
20:17:54 <SMParrish> +1 as well
20:17:56 <adamw> (though i don't get to vote :>)
20:18:08 <mjg59> +1
20:18:09 <tyll> imho there should be first a proposal about what you would like to have
20:18:09 <lmacken> http://bochecha.fedorapeople.org/bodhi_karma_revamped
20:18:22 <lmacken> plus many other ideas people have had... I'll try and consolidate them
20:19:01 <nirik> #agreed lmacken writes up what the exact logic currently is. Next week we visit that and see what changes we would like to make?
20:19:08 <nirik> #undo
20:19:08 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x11123a90>
20:19:11 <nirik> #agreed lmacken writes up what the exact logic currently is. Next week we visit that and see what changes we would like to make.
20:19:18 <nirik> tyll: agreed.
20:19:31 * bochecha notes he hasn't had any time lately to work on what lmacken linked above
20:19:38 <nirik> jlaska: thanks for the news.
20:19:54 <nirik> ok, any further questions/issues/etc on this issue? or shall we move on?
20:20:39 <nirik> ok, moving on to the related topic:
20:20:42 <nirik> #topic #382 Implementing Stable Release Vision
20:20:43 <nirik> .fesco 382
20:20:44 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
20:21:06 <nirik> dafrito reworked our wiki page some: https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas
20:21:17 <nirik> orig at https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
20:21:44 <nirik> we agreed last week that we would look at ideas here and see about assigning them out to be worked on.
20:23:00 <nirik> we still don't have all that many ideas.
20:23:46 <mjg59> I think we do need to work out what the exception process is going to look like
20:23:50 <nirik> How about this as a proposal: we form a updates working group thats a subset of fesco. This subgroup doesn't decide anything, but works on proposals and timelines for implementing things and comes back to the main fesco with that.
20:23:59 <pjones> mjg59: that'd be a good start, yeah
20:24:06 <kylem> nirik, that sounds reasonable.
20:24:25 <nirik> or parsel out each item to a fesco member to work on.
20:24:44 <pjones> the WG idea isn't a terrible one either.
20:25:01 * nirik knows we are all busy, but we should try and get this moving forward...
20:25:21 <notting> either of those sounds fine. but we should pick one
20:26:59 <notting> if we're ok with the ideas as-is, i'd prefer the second
20:27:36 <nirik> I am ok with all the ideas except the updates-features repo
20:28:56 <SMParrish> nirik: what dont you like about that one?
20:30:22 <nirik> increased confusion, possible interaction issues with stable repo, seems like an afterthought instead of part of a revamp of updates
20:30:31 <nirik> increased complexity for maintainers.
20:31:22 <SMParrish> if we dont segregate these types pf updates how then does it differ from today?
20:31:59 <nirik> what is meant by "updates that could affect the stability of the release"
20:32:21 <notting> well, the proposed difference from today is 'not having those updates', not segregating them
20:32:25 <nirik> if it's everything, how is that different than rawhide?
20:32:47 <nirik> right, they should go to rawhide/possibly branched, not stable releases.
20:32:51 <SMParrish> nirik: I didn't really mean updates that are unstable or will crash the system but updates that dont fit into the bug/secuirty only updates repo
20:33:50 <SMParrish> and its different because its not forced on people.  only those who want it get it
20:33:58 <nirik> yeah, there's the fuzzy line. ;( I think we should have some rules of thumb for maintainers (as part of another item there I think).
20:34:33 <nirik> ie, does it break abi? does it affect only itself, or other packages depend on it, does it need to be done for a security or serious bug fix?
20:34:50 <tyll> At least in the discussions on the mailinglist such a repo would contain the updates like they exist now, e.g. everything that fixes bugs and might contain new features but is supposed to not require mmanual intervention to get it running
20:34:56 <nirik> that gets back to "Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues"
20:35:31 <SMParrish> here it is july and KDE is about to release 4.5  its not reasonable to make people wait until november to get it
20:35:33 <nirik> perhaps we should ask the board to elaborate on that.
20:36:22 <SMParrish> atleast this way those who want it for F13 can get it.  F12 would not get it.
20:36:31 <notting> isn't that what kde-redhat served?
20:37:10 <SMParrish> notting: that is not an official fedora repo and for that reason alot of people wait for it to hit the official repos
20:37:38 <notting> but i think this is a secondary item, really
20:37:57 <SMParrish> maybe but it needs to be addressed at some point
20:38:00 <notting> if we're tasked with 'implementing a stable release vision', why would one of the initial items be 'create a way to continue the non-stable release'
20:38:31 <notting> i can see doing it, but i wouldn't make it priority over some of the other items
20:39:10 <nirik> there should be an exception process... there's going to be cases where it might make sense from a tradeoff point of view to get the newer one.
20:39:21 <nirik> for upstreams that have release cycles that don't at all match fedora's
20:39:38 <pjones> there definitely should be an exception process, but it needs to be for things that are truly exceptional, not for developers who just don't like the system.
20:39:58 <mjg59> Well, there's two issues
20:40:02 <notting> ferexample, i suspect we'll end up with mofoco exceptions. wheee.
20:40:10 <tyll> this would be less confusing if the current update repo stay the same and a new repo for the stable updates only is created
20:40:12 <mjg59> Right, one's the Mozilla case
20:40:24 <mjg59> The other is for stuff like amavis
20:40:38 <notting> tyll: if the goal is to implement the stable release for all, then that seems backwards
20:40:44 <nirik> games as well somewhat often.
20:40:58 <nirik> but there's all kinds of different schedules of upstreams out there...
20:41:15 <mjg59> Yeah. There's "We need an update because upstream have stopped providing security", and there's "We need an update because this software is inherently short lived"
20:41:31 <nirik> for example, calibre which I maintain releases every week. It's all minor bug fixes mixed with new features, mixed with changes.
20:41:32 <mjg59> I think the former should be case by case, while the latter should be global
20:42:24 <tyll> notting: to get the stable release for all, it is just enough to use a new fedora-release that only enables the stable updates repo
20:42:52 <notting> so all those upgrading who wanted this have to do extra work? that seems wrong
20:43:47 <nirik> well, if folks really want another repo for more unstable changes I guess I am not 100% against it, but I think it needs rel-eng buyin, needs a clear plan of what goes into it and what shouldn't, how it's enabled/disabled, etc.
20:43:51 <tyll> another issue for the features repo are updates for packages that do not have bugfix/security fix only releases, so that bugfixes will also introduce new features. Without the features repo all bugs might just stay unfixed, but with the release repo users can at least get bugfixes if they do not fear the new features
20:45:08 <mjg59> Or packagers can backport
20:45:22 <notting> stepping back for a second
20:45:32 <nirik> it's hard to make all software one release method fits all. ;)
20:45:49 <notting> why don't we start with the specific action items, and see if we have volunteers for them?
20:46:08 <nirik> ok.
20:46:17 <nirik> Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.
20:46:28 <nirik> anyone interested in working on that?
20:46:46 <nirik> (this is under "High quality updates" section)
20:47:02 * notting would love it if someone from QA volunteered for this task. hee.
20:47:10 * gholms|work notes that nearly 30 min have elapsed for this topic
20:47:17 <nirik> gholms|work: oh yeah, sorry.
20:47:21 <nirik> votes to keep going here?
20:47:23 <nirik> +1 from me.
20:47:31 <tyll> mjg59: at least currently packagers are not required to backport and I believe many packagers are not that fit or interested in doing this
20:47:33 * gholms|work shrugs  (It's your meeting.)  :)
20:47:33 <notting> +1, keep going.
20:47:58 <SMParrish> +1
20:48:04 <kylem> +1.
20:48:17 <nirik> one more?
20:48:36 <mjg59> +1
20:48:48 <nirik> ok, so any takers for that section?
20:48:54 <kylem> although, i suspect we're coming to the time where there's risk of boston people missing their bus home if the meeting goes on another hour. :)
20:49:50 <nirik> yeah, I guess I could file tickets for each section and we could look at people taking the ones they can work on?
20:50:02 <ajax> that works
20:50:04 <nirik> or should we assign here.
20:50:15 * nirik fears if I file, no one will do anything until next week. ;)
20:50:27 <nirik> are there any sections that people _DO_ want to work on?
20:50:38 <nirik> https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas
20:50:41 * SMParrish promises to work on something 8-)
20:50:55 <notting> i'll take the 'document this stance' action item
20:51:09 <notting> and i'll write up a stab at a proposal for exception process
20:52:59 <nirik> I'll take the High-quality updates section.
20:54:06 <nirik> do we want tickets on these? or just track them in the main update vision ticket?
20:54:09 <SMParrish> I'll take the graduated approach
20:54:29 <nirik> cool.
20:54:36 <nirik> Thats 3 taken... any others?
20:55:16 * nirik listens to the crickets
20:55:38 <nirik> we could assign them all to cwickert and mclasen for being absent. ;)
20:56:21 <kylem> heh.
20:56:51 <nirik> #action notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs.
20:57:03 <nirik> #action SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide?
20:57:14 <nirik> #action nirik to work on Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.
20:57:48 <nirik> this one smells like a possible autoqa test: Fedora 14: Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny?
20:59:17 <nirik> well, I guess we can work on those 3 next week and try and get people interested in the rest then?
20:59:32 <kylem> i'll look at the update-features section. (although, i suspect there's more dragons there than it is worth...)
20:59:55 * nirik would like someone to work on the exception process, as that would tell us more about if updates-features is worth doing.
21:00:00 <nirik> kylem: thanks.
21:00:18 <nirik> #action kylem to work on Fedora 14: Have an updates-features optional repository.
21:00:32 <mjg59> I'm happy to look at the exception process
21:00:40 <nirik> mjg59: excellent.
21:00:52 <nirik> #action mjg59 to work on Fedora 14: Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc.
21:01:04 <pjones> I'd be willing to help, but probably won't get any chance to do so before the 13th.
21:01:32 <nirik> ok, how about we see how far we get with all these next week and revisit whats left?
21:02:25 * nirik will move on then... unless anyone objects.
21:02:27 <kylem> sounds good.
21:02:38 <SMParrish> agreed
21:03:09 <nirik> #topic Fedora orphanage/collective maint SIG
21:03:24 <nirik> tyll wanted me to bring up this idea that recently floated on the devel list.
21:04:22 <nirik> I think the devil here is in the details, so personally I would welcome a written up proposal from the group.
21:05:21 <pjones> yeah, I'd like to see a real proposal for this
21:05:26 <pjones> it might be an interesting idea
21:05:43 <notting> in general: do we have info from abadger1999 as to how much work groups in pkgdb/FAS are?
21:05:56 <nirik> not sure.
21:06:14 <nirik> we can inquire.
21:06:26 <abadger1999> notting: The db could handle it with the existing schema but the server and webui would need to be changed.
21:06:45 <nirik> so, any objections to asking for a proposal to review, and moving on?
21:06:50 <abadger1999> notting: The sync to bugzilla might also need some thought.
21:06:56 <SMParrish> no objections
21:07:01 <abadger1999> The sync to cvs should work out of the box, I believe.
21:07:16 <abadger1999> sync to koji... I'm not sure if that would work at all.
21:07:20 <nirik> tyll: please do gather up a proposal for us. ;) Thanks.
21:07:25 <notting> abadger1999: just wondering as it's been fairly often requested in relation to this.
21:07:30 <abadger1999> <nod>
21:07:32 <nirik> #action will review proposal from the group
21:07:44 <nirik> #topic FES tickets roundup
21:07:47 <nirik> mmcgrath: any news?
21:07:50 <abadger1999> I'd welcome someone to do the work but it's fairly large so I haven't devoted time to doing it myself.
21:08:14 <mmcgrath> nirik: some of our key guys have been busy the last two weeks.
21:08:39 <mmcgrath> I did get a recent NVR F12->F13 list in place - https://fedorahosted.org/fedora-engineering-services/ticket/29
21:08:52 <mmcgrath> I've also been going back through some rawhide broken deps one by one.
21:09:05 <mmcgrath> Keeping people has been a tricky task (as we sort of new it would be0
21:09:31 <nirik> have the tasks been too long? we were hoping that many could be short
21:09:46 <mmcgrath> I don't think so, we've had lots of turnover in Infrastructure as well.
21:10:07 <mmcgrath> I think it's just the reality of the world we're in at the moment.
21:10:22 <mmcgrath> I'm hoping to collect a few whales though, guys that come around and stick around and do lots of work.
21:10:38 <mmcgrath> a couple of those is way better then lots of transient people that aren't around more than every couple of weeks.
21:10:54 <nirik> yeah, ok.
21:10:57 <pjones> yeah.
21:11:01 <mmcgrath> So that's where we're at.
21:11:08 <nirik> as always, file tickets for items you think of that we can do to improve fedora.
21:11:11 <mmcgrath> nirik: is there any specific tickets we should be giving higher or lower priority to?
21:11:12 <nirik> thanks mmcgrath
21:11:35 * nirik looks at https://fedorahosted.org/fedora-engineering-services/report/6
21:12:13 <nirik> ticket 24 would be nice to get something on, but I know it's a hard problem.
21:12:41 <nirik> ticket 30 would be nice to help out rel-eng.
21:13:13 <mmcgrath> <nod>
21:13:20 <mmcgrath> I'll take a look and see if we can't get people on them.
21:13:22 <mmcgrath> that's all I've got
21:13:39 <nirik> thanks again.
21:13:41 <nirik> #topic Open floor
21:13:45 <nirik> finally we get to open floor.
21:13:52 <nirik> any items anyone has for that?
21:15:13 * nirik will close the meeting in a minute if nothing comes along.
21:16:38 <nirik> Thanks for coming everyone.
21:16:41 <nirik> #endmeeting