18:00:48 #startmeeting FESCO (2011-11-28) 18:00:48 Meeting started Mon Nov 28 18:00:48 2011 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:59 #meetingname fesco 18:00:59 The meeting name has been set to 'fesco' 18:01:00 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 18:01:00 #topic init process 18:01:00 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 18:01:09 * nirik is here. 18:01:12 * sgallagh is here for one hour 18:01:13 * ajax waves 18:01:14 Hello all 18:01:15 hi 18:01:23 hello. 18:01:37 * cwickert is here 18:01:45 Hello 18:02:04 * notting is here 18:02:11 OK, let's start. 18:02:24 #topic #667 Request to fix CRITPATH update process 18:02:28 .fesco 667 18:02:32 t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 18:02:42 Anything new here? 18:02:48 so, the bodhi change is done now I think. 18:03:06 https://fedorahosted.org/bodhi/ticket/642#comment:4 18:03:07 Yep, I noticed that on one of my critpath updates. 18:03:30 There was a bit more feedback about proventesters... but not much discussion 18:03:35 #info The timeout for the critpath packages is now implemented. 18:04:16 So what about leaving the proventesters as is for now? Or is there a different proposal? 18:04:25 nirik: I hope you come back with some response from proventesters 18:04:37 There's still the proposal to remove the proventester karma requirement 18:04:58 mmaslano: well, adamw and several others responded on the list... 18:05:00 So far what I've seen is "In the future we could have a wonderful new update system" 18:05:04 but not much answer to them. ;) 18:05:21 But no suggestions for how to improve things right now 18:05:38 So we can either leave things as they are, or we can remove the proventester karma requirement for critpath 18:05:49 * nirik nods. 18:05:50 I saw the bodhi v2 karma system proposal from adamw - seems it could help somehow but it still relies on having proventesters. 18:06:29 * nirik would be ok waiting and seeing if the 2 week timeout addresses/helps folks before deciding on proventesters. 18:06:31 I haven't seen any real argument against dropping the proventester karma requirement 18:06:51 mjg59, +1 18:07:20 The numbers we have indicate that the requirement does almost nothing to prevent broken updates going through 18:07:28 yeah, it really seems to have been invented for the sake of inventing things. 18:07:39 OK, let's vote on the proposal 18:07:49 So it's a requirement that doesn't seem to aid our aims, and it's one that makes it harder to get packages in 18:08:18 which proposal? remove requirement on proventeter? 18:08:20 t8m: Could you please phrase the proposal carefully? 18:08:54 proposal: change updates requirements where they say 'proventester' to be 'any logged in user' 18:08:55 #proposal The critpath packages will now require just two regular +1 karma votes (regardless of the proventester status) to be pushed. 18:09:27 +1 18:09:29 +1 18:09:33 +1 18:09:34 +1 18:09:36 +1 18:09:46 * nirik is fine with trying that. +1 18:09:57 -1... want to see how the two week limit works out first 18:10:06 * nirik wonders if we shouldn't start asking proposals be diffs against the updates policy. 18:10:20 +1 of course 18:10:32 nirik: I'd be in favor of that. 18:10:49 nirik: ... but only if we put the policy somewhere that allowed for easy diffing. 18:10:56 http://fedoraproject.org/wiki/Updates_Policy 18:11:02 i.e. a git repo instead of a wiki. (maybe mechanically mirror it to the wiki or something) 18:11:16 the wiki allows easy changes, but not easy changes in a reviewable way like a diff. 18:11:17 Hmm... my proposal would actually strenghten the policy for pre-beta 18:11:19 yeah, it's a pain to deal with the wiki sure. 18:11:45 * nirik thinks t8m's proposal wasn't specific enough. 18:12:30 so let's vote again 18:12:33 nirik: ... go on? 18:13:08 well, there's different proventester requirements depending on where we are in the cycle. 18:13:26 changing all of them to 2 +1 votes actually makes pre beta more restrictive 18:13:54 currently that just requires one +1 from a proventester 18:14:07 #proposal The critpath packages will now require just one regular +1 karma vote in Pre-beta phase and two regular +1 karma votes in other phases to be pushed. 18:14:19 +1 18:14:34 +1 18:14:41 +1 18:14:42 +1 18:15:06 so, really the only point of critpath is that they require +2 karma after this? 18:15:12 Yes 18:15:17 At present 18:15:26 +1 18:15:59 +1 18:16:06 #agreed The critpath packages will now require just one regular +1 karma vote in Pre-beta phase and two regular +1 karma votes in other phases to be pushed. 18:16:13 -1, same reasnaing as above 18:16:17 reasoning, even 18:16:22 ok, we can try it out... +1 (but we should leave the proventester group around in case we need it for bodhi 2.0 or need to revive) 18:16:49 nirik, sure I think we might want it for the blocker -1s or so 18:17:44 Who is volunteering to open a ticket against bodhi to implement the change? 18:18:31 we also need to adjust the wiki page for this, and announce it and the 2 week timeout to packagers. 18:19:32 I can file the bodhi ticket. 18:19:58 #action nirik will file the bodhi ticket 18:20:27 I assume we can change the wiki and send the announce as soon as the change is implemented in bodhi. 18:21:03 sure. The existing 2 week timeout tho needs that done asap 18:21:57 nirik, who can edit the wiki page? I see it is locked for me. 18:22:16 anyone should be able to. make sure you are logged in. 18:22:54 ah looks like a glitch in the mediawiki, after reload I see the edit there 18:23:23 #action t8m will edit the wiki page to add the timeout and announce it 18:23:32 next topic 18:23:45 #topic #699 Proposal to remove the package "tzdata" from Critical Path 18:23:49 .fesco 699 18:23:50 t8m: #699 (Proposal to remove the package "tzdata" from Critical Path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/699 18:24:08 notting, anything new on the whitelisting? 18:24:17 tzdata updates almost merit a fastpath update, whereas critpath is a slowpath. 18:24:37 t8m: bodhi is now reading critpath from pkgdb 18:24:54 the script that creates a critpath has been modified to exclude tzdata 18:24:56 pjones, yep, we agreed on that last week, it was just a problem how to do the whitelisting 18:25:03 i just need to run it and push the results to pkgdb 18:25:09 ah, sorry. 18:25:14 haven't gotten a chance to read the log. 18:25:53 notting, OK, will you close the ticket when it is implemented? 18:26:20 sure 18:26:45 #action notting will implement this and close the ticket then 18:26:53 #topic #705 Reconsider when to shut off updates-testing by default 18:26:53 .fesco 705 18:26:57 t8m: #705 (Reconsider when to shut off updates-testing by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/705 18:28:22 I guess I'd like to get some input from rel-eng and qa here... 18:28:31 t8m: quick note - my mail wasn't a proposal so much as just an example to show why non-numeric karma is really important, and the use of proventesters in my example doesn't mean it's *necessary*. we could do good things with non-numeric karma without PTs. 18:28:55 adamw, OK 18:29:21 no-one should get too attached to the *details* in my mail, it's the big picture that matters. =) sorry, interruption ends 18:30:43 nirik, me too, It seems moving the point to beta could help a little the users who install beta but on the other hand it would make less testing of the packages in testing which might be undesirable 18:31:17 Could we perhaps make this a toggle button in pre-release install media? 18:31:18 i don't think qa really has much of a problem with the current system 18:31:42 the 'turnover point' issue is a bit annoying but is going to happen as long as there is a transition, it doesn't matter when it happens 18:32:31 maybe a compromise would be to switch it sometime during the beta phase - that is on the beta install media still have the updates testing enabled but change it sooner than just before the RCs? 18:32:55 sgallagh: you already can change it in the install media I think... 18:32:59 i'm not sure we have a good post-beta time other than rc 18:33:04 nirik: that affects what media get used *during install* 18:33:12 true. 18:33:13 nirik: but no matter what you pick, you get updates-testing enabled after install. 18:34:41 really, i'm not sure there's a problem here. i think the current system works fine and achieves what it's intended to. i'm not really convinced the thing garret identifies as a problem really *is* a problem. 18:34:41 notting, why not just have the package with yum repo configs updated in the middle of the beta phase? Does it have to be an exact point of time? 18:35:14 But if qa thinks the current situation is fine I have no problem with it. 18:35:31 adamw: Well, during the F16 cycle, there were several packages that shipped at release without full dependencies, because they were met only by updates-testing. 18:35:38 t8m: just that we don't have a schedule milestone it cleanly maps to other than 'arbitrary post-beta point' 18:35:55 sgallagh: well, we scan the media for issues like that and fix them: the media cannot ship with dependency issues 18:36:11 adamw: This was, fortunately, non-media packages. 18:36:34 sgallagh: for anything outside the media i just don't really see the problem: okay, in some kind of theoretical way, the 'frozen' repos should be consistent, sure, but in practice, as long as any issues are resolved by an update package, i can't see any practical consequence 18:36:37 * nirik is fine with just leaving it. 18:36:46 sgallagh: well, there's nothing 'fortunate' about it, we have procedures in place to ensure the media are okay. 18:36:57 #proposal Leave things as is for now. 18:37:00 (there's a script that tests it and any failures are filed as blockers) 18:37:04 adamw: ALlow me to rephrase. 18:37:27 There were some packages (not on the media) that required a specific version of a package that didn't exit updates-testing in time for release. 18:37:49 But I'm okay with leaving things as-is. Just wanted to cover everything 18:38:50 sgallagh: ideally anything in that situation should get a 0-day update, sure. i'm not convinced changing this would fix that problem, though; it's not as if the dependency issues are hidden, at present, there's a daily notification mail which identifies them all, isn't there? 18:39:17 adamw: You're probably right. 18:39:59 Do we want to vote on the 'Leave things as is'? Or should I just close the ticket as there is no proposal for change? 18:40:14 technically, there are three proposals in the ticket 18:41:24 yes, but there is noone here who is proposing them :) except the default of keeping things as is. 18:41:42 to make it clear: i haven't discussed this with the rest of the qa group, but my personal opinion is that the current situation is fine and i don't think that changing the point where we do the switchover to updates-testing disabled would address any particular real-world problems we have. 18:42:05 adamw: great, so we can leave it as is? 18:42:10 * mmaslano is fine with this proposal 18:42:26 so +1 to keeping things as-is 18:42:27 * pjones is +1 to leaving it as it is for now until there's a more clear need to change it. 18:42:29 +1 18:42:36 +1 18:42:37 sure, +1 18:42:39 +1 18:42:42 great 18:42:43 +1 18:42:51 +1 18:43:10 #agreed We will keep the updates-testing switchover point at the RC compose time. 18:43:37 #topic #706 Are updates guidelines descriptive or prescriptive? 18:43:46 .fesco 706 18:43:47 t8m: #706 (Are updates guidelines descriptive or prescriptive?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/706 18:44:34 I'm kind of confused by this. 18:44:40 "use your brain" is apparently not good enough. 18:45:16 It's pretty clear that the list isn't meant to be prescriptive 18:45:17 can we make it somehow that "use your brain" would be sufficient? 18:45:22 abadger1999: you around? 18:45:41 i think it should be made obvious that just because a specific case isn't listed, it doesn't mean it's kosher 18:45:43 But I don't think that's the point Toshio is trying to make 18:45:44 somebody learned a new word... 18:46:31 Could we simply add "If there is any ambiguity, ask FPC"? 18:46:31 notting, on the other hand exceptions are there and will be there 18:46:35 The discussion that led to this was whether a use case that isn't supported by the packager or upstream is intended to be considered when deciding whether to push an update 18:46:56 Which doesn't seem to have anything to do with whether the guidelines themselves are prescriptive or descriptive 18:46:59 sgallagh: or fesco really. 18:47:08 all within the context of the kernel which _already_ has exceptions in the update policy (iirc) 18:47:15 "If you think you need to ask, don't push it" 18:47:19 Sorry, misread "updates guidlines" as "packaging guidelines" 18:47:27 it seemed to me that it's clearly the case that kernel updates don't really strictly follow the distro policy, but it's still probably the way kernel updates should be done, all things considered. and the way the discussion was done seemed somewhat bizarre and just complicated things. 18:47:45 adamw: That's not what's under discussion 18:48:03 proposal: add a "If in doubt about a specific update or policy not enumerated here, please consult with FESCo before pushing that update" ? 18:48:08 mjg59: sorry, i didn't really explain what i meant well. skip it. 18:48:25 nirik, fine +1 18:48:49 adamw: You can break objections to kernel updates into two categories. One is that stuff that we don't care about gets broken. The other is stuff that we do care about gets broken. 18:48:55 nirik: hi 18:49:00 abadger1999: hey. 18:49:27 mjg59: yeah, i mostly followed the tangent the discussion went down, but it just seemed like a very odd side alley to get bogged down in. 18:49:30 So mjg59's statements on the list indicate that he thinks that the list is prescriptive. 18:49:32 The latter clearly contravenes the letter and the spirit of the update policy, but we don't get too angry because the kernel is effectively a special case 18:49:39 abadger1999: uh. No. 18:49:41 mjg59: But his comments here indicate that he thinks it's not :-) 18:49:49 adamw: ditto 18:50:04 mjg59: which is, you know, another reason I think the loanguage needs to be clarified. 18:50:09 abadger1999: I think that use cases that aren't supported by upstream or the packagers are entirely irrelevant 18:51:06 mjg59: I don't agree with that from the language -- I mean, there's libraries where upstream bumps soname willy-nilly but we tell packagers that they aren;t to do those upgrades in a released Fedora. 18:51:08 mjg59: btw, it seems non-controversial that the kernel should be considered a special case, but afaics, that isn't actually written down at present. at least, 'kernel' does not appear anywhere in https://fedoraproject.org/wiki/Updates_Policy . 18:52:01 abadger1999: Those libraries are presumably intended to be used by people. The kernel isn't inteneded to be used in this way. 18:52:32 abadger1999, but that is breaking supported use cases of applications that use the library if they will not be running due to missing dep 18:53:29 * cwickert needs to leave now 18:53:37 I do not see we can agree on anything more concrete than the nirik's proposal above. 18:53:53 well, there could be a more general thing here... 18:53:59 I really don't need to get into another discussion about whether the kernel specific case is allowed -- I think that other language in the policy fits with the kernel case just fine. 18:54:08 isn't nirik's proposal already in there? 18:54:18 But I do think that the updates policy is being misinterpretted right and left. 18:54:28 So I'd like to clarify the language. 18:54:33 but it's hard to word... 'cases where an upstream explicitly disclaims use cases, those use cases can be ignored for puposes of updates' ? 18:54:38 But to do that I need to understand what it's supposed to mean :-) 18:54:43 abadger1999: Any specific cases? 18:55:02 abadger1999: It means "Don't do anything that's likely to break supported use cases" 18:55:07 notting, hmm you're right 18:55:33 mjg59: That's not good enough -- what is supported? Who defines it? 18:56:02 upstream and the packager... but where is a good question. 18:56:05 The person who has the authority to define it 18:56:22 Why are you attempting to codify this? 18:56:39 Because I'm pretty sure you're not going to succeed 18:56:40 having fesco and/or the updates pages attempt to define what is supported for any/all packages seems wrong to me 18:57:09 Because one of the things that discourage people from contributing is the appearance that the rules don't apply evenly to all people. 18:57:41 If you use internal symbols in a library and it gets broken, you have no expectation of it being made right 18:58:03 But really I think you're looking for a bright line case that simply doesn't exist 18:58:06 abadger1999, I slightly agree with you on this but it seems only like appearance and not a real thing 18:58:31 abadger1999: ignoring the citation-needed on whether that's true, the rules _are_ uneven, so... 18:58:33 * sgallagh notes this would be less of an issue if we disallowed non-public functions from being exposed in libraries. 18:58:51 Mandated link-scripts, for example 18:59:13 sgallagh: Exposed how? Two tightly bound .so files from the same package may use each other's symbols 18:59:32 all I want is to write down the rules so that people can see that there isn't a special case for "RedHat-employees", "Fedora old timers", "other exclusive cabal". 18:59:44 mjg59: Ok, I didn't consider that angle 18:59:57 abadger1999: perhaps we just start adding them as we come to them? 19:00:00 sgallagh: that'd be nice, in a sense, but we don't require that packagers be enough of programmers to write that where it doesn't exist 19:00:00 if the assumption is that there *is* such a special case, attempting to write down that there isn't won't dissuade people 19:00:03 abadger1999: it's more about packages than people 19:00:13 abadger1999: Again, I think you're trying to define something that doesn't exist in the way you want it to 19:00:24 We are discussing this topic for more than 15 minutes, do we want to continue? 19:00:29 mjg59: why not. 19:00:40 what are you thinking needs to be defined? 19:00:47 And why do you think it doesn't exist? 19:00:58 abadger1999: There is no general rule that makes it clear whether a specific use case is supported or not 19:01:09 mjg59: why not? 19:01:17 abadger1999: because they're subjective by nature! 19:01:24 pjones: Right. So what? 19:01:28 Because it's not a strict technical decision 19:01:35 pjones: someone gets to judge what counts and what doesn't right? 19:01:39 So just codify that. 19:01:50 Say "maintainers get to choose what makes sense" 19:01:52 or 19:01:59 "FESCo must judge exceptions" 19:02:00 I suppose the decision should be up to maintainers. 19:02:25 So, so far I haven't seen anyone actually cite a specific example of a problem here 19:02:25 i thought 'fesco must judge exceptions' was already on there. if it's only implied, we can surely state so 19:02:30 abadger1999: that's exactly what we have done, and you're saying it's abused 19:02:36 (without citation, mind you) 19:02:58 notting: I read that in there -- so why did the kernel not come to fesco and ask to be able to do this? 19:03:00 #proposal In the absence of indication of actual problems caused by existing guidelines, leave as is 19:03:11 * abadger1999 notes that he thinks that would have been silly. 19:03:21 mjg59, +1 to your proposal 19:03:33 +1 19:03:44 So would much rather we take the sections that already exist on maintainers being able to make decisions and make those the default rather than the fesco exception being the default. 19:03:45 I think the better question would be: can our users find out a list of these and know whats 'supported' ? 19:03:47 mjg59: great proposal +1 19:03:59 mjg59: +1 19:04:06 abadger1999: i'm not seeing what they needed an exception for 19:04:06 * nirik is -1 I think we could clarify things more here. 19:04:15 mjg59: https://admin.fedoraproject.org/updates/python-fedora-0.3.25.1-1.fc14 19:04:19 There's one. 19:04:41 abadger1999: You're going to need to provide more context 19:04:49 "this update breaks virtualbox!" "we don't support out of tree modules" "oh? where does it say that? I didn't know" 19:04:53 changelog says... bugfixes. 19:05:00 people are confused about what is an update that is disallowed by the guidelines. 19:05:15 abadger1999: That update appears to have been filed by you 19:05:23 mjg59: That's why I know about it, yep. 19:05:27 abadger1999: What aspect of it do you think may have been inappropriate for F14? 19:05:35 As maintainer, I think it was appropriate. 19:05:53 abadger1999, so what is this example about? 19:06:00 But clearly, pother people think that it was inappropriate -- thuse their negative karma and explanations of why they think it was inappropriate in the update request. 19:06:04 the complaint from the users has been that "adding 20 new packages to my system" is a regression/material affect to their experience/something like that 19:06:12 yep. 19:06:22 Ah, this is the one that resulted in a pile of new packages being dragged in? 19:06:26 Yeah. 19:07:00 Do any of those dependent packages start anything by default? 19:07:15 mjg59: no. 19:07:23 (We might be on a tangent, though) 19:07:33 Then eh, it's something that has no impact on the users so I have no idea why you would feel it was inappropriate under the update policy 19:08:18 right. Yet there are quite a few people who do (two on the update request, I think it's three on the subsequent bugzilla, and another two I remember on the mailing list). 19:08:56 But I don't think it's the kind of thing that would be made better by clarification 19:09:01 So it's another example where I would like to look at the update policy and figure out how to reword it so that it's clearer here. 19:09:25 Unless you say "It's ok for packages to gain dependencies in updates" and then we're on the road to enumerating every single thing 19:09:38 perhaps if we tried to define 'user experence' ? 19:10:05 yep, can define user experience better; can define how much latitude the maintainer has. 19:10:21 ugh 19:10:23 that's going to be a very very very long document. 19:10:26 Remembering that it's not going to be perfect, there's still multiple ways to make things better. 19:10:33 abadger1999: sorry, but if you feel that new update is needed, then new packages were okay. I would believe maintainer in this case 19:10:37 ha, iso defines it as: ""a person's perceptions and responses that result from the use or anticipated use of a product, system or service" 19:11:00 abadger1999: imho long document makes developer experience worst 19:11:04 worse 19:11:41 mmaslano: Sure. But clearer language is not necessarily longer. 19:12:08 Proposal: ask abadger1999 to come back with recommended language changes. 19:12:10 * nirik isn't sure we will solve this here. Perhaps abadger1999 could try and come up with some proposed changes now? 19:12:19 So here's the thing -- I'm volunteering to try and draft a clearer policy. 19:12:22 abadger1999: could you come with diff? 19:12:27 excellent! 19:12:34 But I do need to know what is intended in the present policy to do that. 19:12:52 For instane, there is language revolving around maintainer perogative. 19:13:02 But there's also language about exceptions having to go through fesco. 19:13:26 I could strike one or the other or define that there's some sort of line between the two. 19:13:43 but I need to know what the intention of the current policy is to make that decision. 19:13:44 I would put the line at 'if you have doubts as a maintainer' ? 19:14:09 that's because everything should be considered by maintainer and only if he really does not know or after the update is in updates and testers are rejecting it only then it should be brought to fesco 19:14:34 (the second part of t8m's statement is already in the guidelines) 19:14:35 t8m: I like that just fine. Can I modify the document with that POV? 19:15:27 abadger1999, and isn't it like this already? but if it isn't please do and come with the diff to FESCo :) 19:15:47 And we are clear that the current policy is descriptive, not prescriptive, correct? 19:16:08 being a drafted document, it's conscriptive 19:16:20 heh :-) 19:16:21 the examples can't possibly be prescriptive. that doesn't make sense at all. 19:16:22 :) 19:16:31 pjones: That's what I thought. Thank you :-) 19:16:38 abadger1999: when you will be writing, please think about non US developers 19:16:46 we are discussing this topic for 30 mins 19:17:07 mmaslano: In terms of not using US idioms and such? Can do. 19:17:14 officially: 19:17:24 * abadger1999 has enough to work on a new draft 19:17:28 #proposal have abadger1999 come up with clearer wording for the policy 19:17:28 abadger1999: that would be first great thing ;-) 19:17:46 notting, I don't think we have to vote on this 19:17:55 ... ok 19:18:38 #action abadger1999 will come up with clearer wording for the policy 19:19:26 There are three features that were added to the ticket system recently. Do we want to vote on them today? 19:19:57 i'm fine to go through them now. others? 19:20:03 i would have to abstain from two of them, since they're my features. 19:20:05 * sgallagh has to leave now 19:20:36 fine to go thru them for me. 19:20:40 do we still have quorum? 19:20:47 I think so 19:20:59 Still here 19:21:12 * mmaslano is also here, so please quickly 19:21:19 ok, let's go through them 19:21:38 #topic #708 F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly 19:21:47 .fesco 708 19:21:48 t8m: #708 (F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/708 19:22:07 +1 here. 19:22:16 * ajax here to field questions 19:22:36 +1 19:22:37 +1 19:23:06 ajax: as i read this, this means 'dropping dri1 GL drivers', not 'drop all X drivers that do not have dri2 support' 19:23:08 ? 19:23:31 notting: correct. i couldn't possibly do the latter anyway (vesa etc) 19:23:41 i can clarify that on the feature page though 19:23:42 +1, then 19:23:50 +1 19:24:01 #agreed The feature is allowed 19:24:27 ajax, please put that statement on the feature page 19:24:52 #topic #709 F17 Feature: Software rendering for gnome-shell - https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering 19:24:58 .fesco 709 19:24:59 t8m: #709 (F17 Feature: Software rendering for gnome-shell - https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/709 19:25:04 +1 19:25:06 +1 19:25:23 +1 19:25:24 +1 19:25:28 +1 19:25:39 #agreed The feature is allowed 19:25:48 #topic #710 F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps 19:25:54 .fesco 710 19:25:55 t8m: #710 (F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/710 19:26:23 +1 19:26:25 +1 19:26:32 +1 19:26:51 sure, +1 19:27:05 +1 19:27:08 +1. summary could be reworded a bit, but, whatever 19:27:18 #agreed The feature is allowed 19:27:48 I suppose we do not have anything new on the Engineering services tickets? 19:27:54 nope. 19:28:03 #topic Next week chair 19:28:04 please see me if you wish to help out reviving things there. 19:28:35 Anybody volunteers to be next week chair? 19:29:52 can't do next week .can do two weeks from now 19:30:22 * mmaslano is not sure wheter it's the first meeting of new fesco or not 19:30:40 Oh yeah 19:30:42 oh, yeah, 2011-12-05 is the end of elections. 19:30:43 People should go and vote 19:30:44 I could do it if i'm still member ;-) 19:31:07 yeah, it would be the current fesco again next week... 19:31:11 then the next folks the week after. 19:31:20 i could do one last time i suppose 19:31:52 ajax: it's yours ;-) 19:32:14 #action ajax is the next week chair as it will be his last time in FESCo :) 19:32:24 suitable punishment ;) 19:32:24 (for now) 19:32:44 #topic Open Floor 19:33:09 I have one announcement/reminder: 19:33:36 #info REMINDER: Please change your password and upload a new ssh key if you have not already. Deadline is 2011-11-30! 19:33:39 http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html 19:34:32 * nirik has nothing else. 19:35:37 I will end the meeting if nobody speaks up in a minute. 19:36:12 * shaiton will start in 2 minutes then ^^ 19:36:48 #endmeeting