18:00:48 <t8m> #startmeeting FESCO (2011-11-28)
18:00:48 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:59 <t8m> #meetingname fesco
18:00:59 <zodbot> The meeting name has been set to 'fesco'
18:01:00 <t8m> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
18:01:00 <t8m> #topic init process
18:01:00 <zodbot> 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 <t8m> Hello all
18:01:15 <mmaslano> hi
18:01:23 <pjones> hello.
18:01:37 * cwickert is here
18:01:45 <mjg59> Hello
18:02:04 * notting is here
18:02:11 <t8m> OK, let's start.
18:02:24 <t8m> #topic #667 Request to fix CRITPATH update process
18:02:28 <t8m> .fesco 667
18:02:32 <zodbot> t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
18:02:42 <t8m> Anything new here?
18:02:48 <nirik> so, the bodhi change is done now I think.
18:03:06 <nirik> https://fedorahosted.org/bodhi/ticket/642#comment:4
18:03:07 <t8m> Yep, I noticed that on one of my critpath updates.
18:03:30 <nirik> There was a bit more feedback about proventesters... but not much discussion
18:03:35 <t8m> #info The timeout for the critpath packages is now implemented.
18:04:16 <t8m> So what about leaving the proventesters as is for now? Or is there a different proposal?
18:04:25 <mmaslano> nirik: I hope you come back with some response from proventesters
18:04:37 <mjg59> There's still the proposal to remove the proventester karma requirement
18:04:58 <nirik> mmaslano: well, adamw and several others responded on the list...
18:05:00 <mjg59> So far what I've seen is "In the future we could have a wonderful new update system"
18:05:04 <nirik> but not much answer to them. ;)
18:05:21 <mjg59> But no suggestions for how to improve things right now
18:05:38 <mjg59> 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 <t8m> 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 <mjg59> I haven't seen any real argument against dropping the proventester karma requirement
18:06:51 <t8m> mjg59, +1
18:07:20 <mjg59> The numbers we have indicate that the requirement does almost nothing to prevent broken updates going through
18:07:28 <pjones> yeah, it really seems to have been invented for the sake of inventing things.
18:07:39 <t8m> OK, let's vote on the proposal
18:07:49 <mjg59> 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 <mmaslano> which proposal? remove requirement on proventeter?
18:08:20 <sgallagh> t8m: Could you please phrase the proposal carefully?
18:08:54 <nirik> proposal: change updates requirements where they say 'proventester' to be 'any logged in user'
18:08:55 <t8m> #proposal The critpath packages will now require just two regular +1 karma votes (regardless of the proventester status) to be pushed.
18:09:27 <sgallagh> +1
18:09:29 <mjg59> +1
18:09:33 <mmaslano> +1
18:09:34 <ajax> +1
18:09:36 <t8m> +1
18:09:46 * nirik is fine with trying that. +1
18:09:57 <notting> -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 <pjones> +1 of course
18:10:32 <pjones> nirik: I'd be in favor of that.
18:10:49 <pjones> nirik: ... but only if we put the policy somewhere that allowed for easy diffing.
18:10:56 <nirik> http://fedoraproject.org/wiki/Updates_Policy
18:11:02 <pjones> i.e. a git repo instead of a wiki.  (maybe mechanically mirror it to the wiki or something)
18:11:16 <pjones> the wiki allows easy changes, but not easy changes in a reviewable way like a diff.
18:11:17 <t8m> Hmm... my proposal would actually strenghten the policy for pre-beta
18:11:19 <nirik> 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 <t8m> so let's vote again
18:12:33 <pjones> nirik: ... go on?
18:13:08 <nirik> well, there's different proventester requirements depending on where we are in the cycle.
18:13:26 <nirik> changing all of them to 2 +1 votes actually makes pre beta more restrictive
18:13:54 <nirik> currently that just requires one +1 from a proventester
18:14:07 <t8m> #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 <t8m> +1
18:14:34 <mjg59> +1
18:14:41 <cwickert> +1
18:14:42 <sgallagh> +1
18:15:06 <nirik> so, really the only point of critpath is that they require +2 karma after this?
18:15:12 <mjg59> Yes
18:15:17 <mjg59> At present
18:15:26 <mmaslano> +1
18:15:59 <pjones> +1
18:16:06 <t8m> #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 <notting> -1, same reasnaing as above
18:16:17 <notting> reasoning, even
18:16:22 <nirik> 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 <t8m> nirik, sure I think we might want it for the blocker -1s or so
18:17:44 <t8m> Who is volunteering to open a ticket against bodhi to implement the change?
18:18:31 <nirik> we also need to adjust the wiki page for this, and announce it and the 2 week timeout to packagers.
18:19:32 <nirik> I can file the bodhi ticket.
18:19:58 <t8m> #action nirik will file the bodhi ticket
18:20:27 <t8m> I assume we can change the wiki and send the announce as soon as the change is implemented in bodhi.
18:21:03 <nirik> sure. The existing 2 week timeout tho needs that done asap
18:21:57 <t8m> nirik, who can edit the wiki page? I see it is locked for me.
18:22:16 <nirik> anyone should be able to. make sure you are logged in.
18:22:54 <t8m> ah looks like a glitch in the mediawiki, after reload I see the edit there
18:23:23 <t8m> #action t8m will edit the wiki page to add the timeout and announce it
18:23:32 <t8m> next topic
18:23:45 <t8m> #topic #699 Proposal to remove the package "tzdata" from Critical Path
18:23:49 <t8m> .fesco 699
18:23:50 <zodbot> t8m: #699 (Proposal to remove the package "tzdata" from Critical Path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/699
18:24:08 <t8m> notting, anything new on the whitelisting?
18:24:17 <pjones> tzdata updates almost merit a fastpath update, whereas critpath is a slowpath.
18:24:37 <notting> t8m: bodhi is now reading critpath from pkgdb
18:24:54 <notting> the script that creates a critpath has been modified to exclude tzdata
18:24:56 <t8m> pjones, yep, we agreed on that last week, it was just a problem how to do the whitelisting
18:25:03 <notting> i just need to run it and push the results to pkgdb
18:25:09 <pjones> ah, sorry.
18:25:14 <pjones> haven't gotten a chance to read the log.
18:25:53 <t8m> notting, OK, will you close the ticket when it is implemented?
18:26:20 <notting> sure
18:26:45 <t8m> #action notting will implement this and close the ticket then
18:26:53 <t8m> #topic #705 Reconsider when to shut off updates-testing by default
18:26:53 <t8m> .fesco 705
18:26:57 <zodbot> t8m: #705 (Reconsider when to shut off updates-testing by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/705
18:28:22 <nirik> I guess I'd like to get some input from rel-eng and qa here...
18:28:31 <adamw> 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 <t8m> adamw, OK
18:29:21 <adamw> 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 <t8m> 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 <sgallagh> Could we perhaps make this a toggle button in pre-release install media?
18:31:18 <adamw> i don't think qa really has much of a problem with the current system
18:31:42 <adamw> 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 <t8m> 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 <nirik> sgallagh: you already can change it in the install media I think...
18:32:59 <notting> i'm not sure we have a good post-beta time other than rc
18:33:04 <adamw> nirik: that affects what media get used *during install*
18:33:12 <nirik> true.
18:33:13 <adamw> nirik: but no matter what you pick, you get updates-testing enabled after install.
18:34:41 <adamw> 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 <t8m> 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 <t8m> But if qa thinks the current situation is fine I have no problem with it.
18:35:31 <sgallagh> 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 <notting> t8m: just that we don't have a schedule milestone it cleanly maps to other than 'arbitrary post-beta point'
18:35:55 <adamw> sgallagh: well, we scan the media for issues like that and fix them: the media cannot ship with dependency issues
18:36:11 <sgallagh> adamw: This was, fortunately, non-media packages.
18:36:34 <adamw> 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 <adamw> sgallagh: well, there's nothing 'fortunate' about it, we have procedures in place to ensure the media are okay.
18:36:57 <t8m> #proposal Leave things as is for now.
18:37:00 <adamw> (there's a script that tests it and any failures are filed as blockers)
18:37:04 <sgallagh> adamw: ALlow me to rephrase.
18:37:27 <sgallagh> 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 <sgallagh> But I'm okay with leaving things as-is. Just wanted to cover everything
18:38:50 <adamw> 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 <sgallagh> adamw: You're probably right.
18:39:59 <t8m> 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 <notting> technically, there are three proposals in the ticket
18:41:24 <t8m> yes, but there is noone here who is proposing them :) except the default of keeping things as is.
18:41:42 <adamw> 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 <mmaslano> adamw: great, so we can leave it as is?
18:42:10 * mmaslano is fine with this proposal
18:42:26 <t8m> 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 <cwickert> +1
18:42:36 <notting> +1
18:42:37 <nirik> sure, +1
18:42:39 <mjg59> +1
18:42:42 <t8m> great
18:42:43 <mmaslano> +1
18:42:51 <sgallagh> +1
18:43:10 <t8m> #agreed We will keep the updates-testing switchover point at the RC compose time.
18:43:37 <t8m> #topic #706 Are updates guidelines descriptive or prescriptive?
18:43:46 <t8m> .fesco 706
18:43:47 <zodbot> t8m: #706 (Are updates guidelines descriptive or prescriptive?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/706
18:44:34 <mjg59> I'm kind of confused by this.
18:44:40 <ajax> "use your brain" is apparently not good enough.
18:45:16 <mjg59> It's pretty clear that the list isn't meant to be prescriptive
18:45:17 <t8m> can we make it somehow that "use your brain" would be sufficient?
18:45:22 <nirik> abadger1999: you around?
18:45:41 <notting> 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 <mjg59> But I don't think that's the point Toshio is trying to make
18:45:44 <pjones> somebody learned a new word...
18:46:31 <sgallagh> Could we simply add "If there is any ambiguity, ask FPC"?
18:46:31 <t8m> notting, on the other hand exceptions are there and will be there
18:46:35 <mjg59> 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 <mjg59> Which doesn't seem to have anything to do with whether the guidelines themselves are prescriptive or descriptive
18:46:59 <nirik> sgallagh: or fesco really.
18:47:08 <ajax> all within the context of the kernel which _already_ has exceptions in the update policy (iirc)
18:47:15 <mjg59> "If you think you need to ask, don't push it"
18:47:19 <sgallagh> Sorry, misread "updates guidlines" as "packaging guidelines"
18:47:27 <adamw> 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 <mjg59> adamw: That's not what's under discussion
18:48:03 <nirik> 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 <adamw> mjg59: sorry, i didn't really explain what i meant well. skip it.
18:48:25 <t8m> nirik, fine +1
18:48:49 <mjg59> 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 <abadger1999> nirik: hi
18:49:00 <nirik> abadger1999: hey.
18:49:27 <adamw> 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 <abadger1999> So mjg59's statements on the list indicate that he thinks that the list is prescriptive.
18:49:32 <mjg59> 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 <mjg59> abadger1999: uh. No.
18:49:41 <abadger1999> mjg59: But his comments here indicate that he thinks it's not :-)
18:49:49 <nirik> adamw: ditto
18:50:04 <abadger1999> mjg59: which is, you know, another reason I think the loanguage needs to be clarified.
18:50:09 <mjg59> abadger1999: I think that use cases that aren't supported by upstream or the packagers are entirely irrelevant
18:51:06 <abadger1999> 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 <adamw> 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 <mjg59> 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 <t8m> 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 <t8m> I do not see we can agree on anything more concrete than the nirik's proposal above.
18:53:53 <nirik> well, there could be a more general thing here...
18:53:59 <abadger1999> 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 <notting> isn't nirik's proposal already in there?
18:54:18 <abadger1999> But I do think that the updates policy is being misinterpretted right and left.
18:54:28 <abadger1999> So I'd like to clarify the language.
18:54:33 <nirik> 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 <abadger1999> But to do that I need to understand what it's supposed to mean :-)
18:54:43 <mjg59> abadger1999: Any specific cases?
18:55:02 <mjg59> abadger1999: It means "Don't do anything that's likely to break supported use cases"
18:55:07 <t8m> notting, hmm you're right
18:55:33 <abadger1999> mjg59: That's not good enough -- what is supported?  Who defines it?
18:56:02 <nirik> upstream and the packager... but where is a good question.
18:56:05 <mjg59> The person who has the authority to define it
18:56:22 <mjg59> Why are you attempting to codify this?
18:56:39 <mjg59> Because I'm pretty sure you're not going to succeed
18:56:40 <notting> having fesco and/or the updates pages attempt to define what is supported for any/all packages seems wrong to me
18:57:09 <abadger1999> 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 <mjg59> If you use internal symbols in a library and it gets broken, you have no expectation of it being made right
18:58:03 <mjg59> But really I think you're looking for a bright line case that simply doesn't exist
18:58:06 <t8m> abadger1999, I slightly agree with you on this but it seems only like appearance and not a real thing
18:58:31 <ajax> 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 <sgallagh> Mandated link-scripts, for example
18:59:13 <mjg59> sgallagh: Exposed how? Two tightly bound .so files from the same package may use each other's symbols
18:59:32 <abadger1999> 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 <sgallagh> mjg59: Ok, I didn't consider that angle
18:59:57 <nirik> abadger1999: perhaps we just start adding them as we come to them?
19:00:00 <ajax> 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 <notting> 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 <mmaslano> abadger1999: it's more about packages than people
19:00:13 <mjg59> abadger1999: Again, I think you're trying to define something that doesn't exist in the way you want it to
19:00:24 <t8m> We are discussing this topic for more than 15 minutes, do we want to continue?
19:00:29 <abadger1999> mjg59: why not.
19:00:40 <abadger1999> what are you thinking needs to be defined?
19:00:47 <abadger1999> And why do you think it doesn't exist?
19:00:58 <mjg59> abadger1999: There is no general rule that makes it clear whether a specific use case is supported or not
19:01:09 <abadger1999> mjg59: why not?
19:01:17 <pjones> abadger1999: because they're subjective by nature!
19:01:24 <abadger1999> pjones: Right.  So what?
19:01:28 <mjg59> Because it's not a strict technical decision
19:01:35 <abadger1999> pjones: someone gets to judge what counts and what doesn't right?
19:01:39 <abadger1999> So just codify that.
19:01:50 <abadger1999> Say "maintainers get to choose what makes sense"
19:01:52 <abadger1999> or
19:01:59 <abadger1999> "FESCo must judge exceptions"
19:02:00 <nirik> I suppose the decision should be up to maintainers.
19:02:25 <mjg59> So, so far I haven't seen anyone actually cite a specific example of a problem here
19:02:25 <notting> i thought 'fesco must judge exceptions' was already on there. if it's only implied, we can surely state so
19:02:30 <pjones> abadger1999: that's exactly what we have done, and you're saying it's abused
19:02:36 <pjones> (without citation, mind you)
19:02:58 <abadger1999> 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 <mjg59> #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 <t8m> mjg59, +1 to your proposal
19:03:33 <sgallagh> +1
19:03:44 <abadger1999> 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 <nirik> I think the better question would be: can our users find out a list of these and know whats 'supported' ?
19:03:47 <mmaslano> mjg59: great proposal +1
19:03:59 <pjones> mjg59: +1
19:04:06 <notting> 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 <abadger1999> mjg59: https://admin.fedoraproject.org/updates/python-fedora-0.3.25.1-1.fc14
19:04:19 <abadger1999> There's one.
19:04:41 <mjg59> abadger1999: You're going to need to provide more context
19:04:49 <nirik> "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 <pjones> changelog says... bugfixes.
19:05:00 <abadger1999> people are confused about what is an update that is disallowed by the guidelines.
19:05:15 <mjg59> abadger1999: That update appears to have been filed by you
19:05:23 <abadger1999> mjg59: That's why I know about it, yep.
19:05:27 <mjg59> abadger1999: What aspect of it do you think may have been inappropriate for F14?
19:05:35 <abadger1999> As maintainer, I think it was appropriate.
19:05:53 <t8m> abadger1999, so what is this example about?
19:06:00 <abadger1999> 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 <notting> 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 <abadger1999> yep.
19:06:22 <mjg59> Ah, this is the one that resulted in a pile of new packages being dragged in?
19:06:26 <abadger1999> Yeah.
19:07:00 <mjg59> Do any of those dependent packages start anything by default?
19:07:15 <abadger1999> mjg59: no.
19:07:23 <abadger1999> (We might be on a tangent, though)
19:07:33 <mjg59> 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 <abadger1999> 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 <mjg59> But I don't think it's the kind of thing that would be made better by clarification
19:09:01 <abadger1999> 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 <mjg59> 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 <nirik> perhaps if we tried to define 'user experence' ?
19:10:05 <abadger1999> yep, can define user experience better; can define how much latitude the maintainer has.
19:10:21 <t8m> ugh
19:10:23 <ajax> that's going to be a very very very long document.
19:10:26 <abadger1999> Remembering that it's not going to be perfect, there's still multiple ways to make things better.
19:10:33 <mmaslano> 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 <nirik> 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 <mmaslano> abadger1999: imho long document makes developer experience worst
19:11:04 <mmaslano> worse
19:11:41 <abadger1999> mmaslano: Sure.  But clearer language is not necessarily longer.
19:12:08 <pjones> 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 <abadger1999> So here's the thing -- I'm volunteering to try and draft a clearer policy.
19:12:22 <mmaslano> abadger1999: could you come with diff?
19:12:27 <pjones> excellent!
19:12:34 <abadger1999> But I do need to know what is intended in the present policy to do that.
19:12:52 <abadger1999> For instane, there is language revolving around maintainer perogative.
19:13:02 <abadger1999> But there's also language about exceptions having to go through fesco.
19:13:26 <abadger1999> I could strike one or the other  or define that there's some sort of line between the two.
19:13:43 <abadger1999> but I need to know what the intention of the current policy is to make that decision.
19:13:44 <nirik> I would put the line at 'if you have doubts as a maintainer' ?
19:14:09 <t8m> 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 <notting> (the second part of t8m's statement is already in the guidelines)
19:14:35 <abadger1999> t8m: I like that just fine.  Can I modify the document with that POV?
19:15:27 <t8m> 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 <abadger1999> And we are  clear that the current policy is descriptive, not prescriptive, correct?
19:16:08 <notting> being a drafted document, it's conscriptive
19:16:20 <abadger1999> heh :-)
19:16:21 <pjones> the examples can't possibly be prescriptive.  that doesn't make sense at all.
19:16:22 <t8m> :)
19:16:31 <abadger1999> pjones: That's what I thought.  Thank you :-)
19:16:38 <mmaslano> abadger1999: when you will be writing, please think about non US developers
19:16:46 <t8m> we are discussing this topic for 30 mins
19:17:07 <abadger1999> mmaslano: In terms of not using US idioms and such?  Can do.
19:17:14 <notting> officially:
19:17:24 * abadger1999 has enough to work on a new draft
19:17:28 <notting> #proposal have abadger1999 come up with clearer wording for the policy
19:17:28 <mmaslano> abadger1999: that would be first great thing ;-)
19:17:46 <t8m> notting, I don't think we have to vote on this
19:17:55 <notting> ... ok
19:18:38 <t8m> #action abadger1999 will come up with clearer wording for the policy
19:19:26 <t8m> There are three features that were added to the ticket system recently. Do we want to vote on them today?
19:19:57 <notting> i'm fine to go through them now. others?
19:20:03 <ajax> 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 <nirik> fine to go thru them for me.
19:20:40 <nirik> do we still have quorum?
19:20:47 <t8m> I think so
19:20:59 <mjg59> Still here
19:21:12 * mmaslano is also here, so please quickly
19:21:19 <t8m> ok, let's go through them
19:21:38 <t8m> #topic #708 F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly
19:21:47 <t8m> .fesco 708
19:21:48 <zodbot> t8m: #708 (F17 Feature: DRI2 Drivers only - http://fedoraproject.org/wiki/Features/DRI2DriversOnly) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/708
19:22:07 <nirik> +1 here.
19:22:16 * ajax here to field questions
19:22:36 <mjg59> +1
19:22:37 <t8m> +1
19:23:06 <notting> 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 <notting> ?
19:23:31 <ajax> notting: correct.  i couldn't possibly do the latter anyway (vesa etc)
19:23:41 <ajax> i can clarify that on the feature page though
19:23:42 <notting> +1, then
19:23:50 <mmaslano> +1
19:24:01 <t8m> #agreed The feature is allowed
19:24:27 <t8m> ajax, please put that statement on the feature page
19:24:52 <t8m> #topic #709 F17 Feature: Software rendering for gnome-shell - https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
19:24:58 <t8m> .fesco 709
19:24:59 <zodbot> 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 <mjg59> +1
19:25:06 <t8m> +1
19:25:23 <nirik> +1
19:25:24 <notting> +1
19:25:28 <cwickert> +1
19:25:39 <t8m> #agreed The feature is allowed
19:25:48 <t8m> #topic #710 F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps
19:25:54 <t8m> .fesco 710
19:25:55 <zodbot> t8m: #710 (F17 Feature: Inscript2 Keymaps - https://fedoraproject.org/wiki/Features/Inscript2_Keymaps) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/710
19:26:23 <ajax> +1
19:26:25 <t8m> +1
19:26:32 <mjg59> +1
19:26:51 <nirik> sure, +1
19:27:05 <mmaslano> +1
19:27:08 <notting> +1. summary could be reworded a bit, but, whatever
19:27:18 <t8m> #agreed The feature is allowed
19:27:48 <t8m> I suppose we do not have anything new on the Engineering services tickets?
19:27:54 <nirik> nope.
19:28:03 <t8m> #topic Next week chair
19:28:04 <nirik> please see me if you wish to help out reviving things there.
19:28:35 <t8m> Anybody volunteers to be next week chair?
19:29:52 <notting> 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 <mjg59> Oh yeah
19:30:42 <nirik> oh, yeah, 2011-12-05 is the end of elections.
19:30:43 <mjg59> People should go and vote
19:30:44 <mmaslano> I could do it if i'm still member ;-)
19:31:07 <nirik> yeah, it would be the current fesco again next week...
19:31:11 <nirik> then the next folks the week after.
19:31:20 <ajax> i could do one last time i suppose
19:31:52 <mmaslano> ajax: it's yours ;-)
19:32:14 <t8m> #action ajax is the next week chair as it will be his last time in FESCo :)
19:32:24 <ajax> suitable punishment ;)
19:32:24 <t8m> (for now)
19:32:44 <t8m> #topic Open Floor
19:33:09 <nirik> I have one announcement/reminder:
19:33:36 <nirik> #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 <nirik> http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html
19:34:32 * nirik has nothing else.
19:35:37 <t8m> 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 <t8m> #endmeeting