=================================== #fedora-meeting: FESCO (2010-07-06) =================================== Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-07-06/fesco.2010-07-06-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:01) * cwickert and mclasen are unable to attend today and have added votes/comment to ticket items. (nirik, 19:30:41) * #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 (nirik, 19:33:17) * #412 Non-responsive maintainer (ixs); request fast-track orphaning of libsndfile (nirik, 19:35:46) * AGREED: nirik will try and contact ixs one last time, will reassign libsndfile if no response in a few days. (nirik, 19:41:42) * #409 Feature Request: GNUstep (nirik, 19:41:55) * AGREED: defer a week to ask questions in the ticket / wiki page (nirik, 19:51:33) * #410 F14Feature: http://fedoraproject.org/wiki/Features/D_Programming (nirik, 19:52:14) * AGREED: Feature is approved. (nirik, 19:55:18) * #413 F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming (nirik, 20:00:25) * AGREED: will defer a week to ask which compiler will be used and more info from feature owners. (nirik, 20:06:11) * #351 Create a policy for updates - status report on implementation (nirik, 20:06:19) * LINK: https://fedorahosted.org/fesco/ticket/351 (nirik, 20:06:19) * LINK: http://bochecha.fedorapeople.org/bodhi_karma_revamped (lmacken, 20:18:09) * AGREED: lmacken writes up what the exact logic currently is. Next week we visit that and see what changes we would like to make. (nirik, 20:19:11) * #382 Implementing Stable Release Vision (nirik, 20:20:42) * LINK: https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas (nirik, 20:50:38) * ACTION: notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs. (nirik, 20:56:51) * ACTION: SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide? (nirik, 20:57:03) * 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. (nirik, 20:57:14) * ACTION: kylem to work on Fedora 14: Have an updates-features optional repository. (nirik, 21:00:18) * 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. (nirik, 21:00:52) * Fedora orphanage/collective maint SIG (nirik, 21:03:09) * ACTION: will review proposal from the group (nirik, 21:07:32) * FES tickets roundup (nirik, 21:07:44) * Open floor (nirik, 21:13:41) Meeting ended at 21:16:41 UTC. Action Items ------------ * notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs. * SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide? * 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. * kylem to work on Fedora 14: Have an updates-features optional repository. * 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. * will review proposal from the group -- 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@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
