18:01:16 <sgallagh> #startmeeting FESCO (2012-12-12)
18:01:16 <zodbot> Meeting started Mon Dec 12 18:01:16 2011 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:16 <sgallagh> #meetingname fesco
18:01:17 <sgallagh> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:01:17 <sgallagh> #topic init process
18:01:17 <zodbot> The meeting name has been set to 'fesco'
18:01:17 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:01:29 * nirik waves
18:01:33 * mmaslano here
18:01:38 <t8m> hello all
18:01:41 * limburgher yo.
18:02:10 <mitr> Hello
18:03:01 <sgallagh> notting said he wasn't going to be able to make it
18:03:12 <sgallagh> Anyone heard from mjg59 or pjones?
18:03:30 <sgallagh> Well, we have quorum, so let's get started anyway.
18:03:38 <nirik> sgallagh: they are also not going to make it.
18:03:43 <sgallagh> ok
18:03:52 <sgallagh> #topic Welcome new FESCo members
18:04:08 <sgallagh> Welcome aboard to mitr and limburgher!
18:04:23 * limburgher curtsies
18:04:29 <mitr> thanks
18:04:32 <limburgher> Thank you!
18:04:44 <nirik> welcome
18:04:48 <sgallagh> So, as with any new FESCo, we need to agree on a meeting time.
18:04:58 * nirik nods.
18:05:03 <sgallagh> Does the current timeslot work for everyone still, or shall we reschedule it?
18:05:17 <limburgher> It's fine for me.
18:05:30 <nirik> this is ok with me, although being on monday means we often don't get to announce an agenda a day in advance...
18:05:50 <sgallagh> nirik: True, but lately we've been adding agenda items mere hours before the meeting anyway.
18:06:08 <sgallagh> Or, in the case of today, *during*
18:06:15 <nirik> yeah, which can be bad... since we don't have as much time to read up and think about things. ;(
18:06:27 <nirik> anyhow, happy to leave it here, or adjust.
18:06:41 <limburgher> :)
18:06:52 <sgallagh> Can anyone NOT make it if we continue in this time slot?
18:06:56 <sgallagh> mitr: ?
18:07:29 <mitr> sgallagh: I'm fine (18:00 UTC - wiki says 17:00, I'm fine with both)
18:07:30 <t8m> why not make another round of whenisgood
18:07:58 <t8m> mitr, hmm we moved to 18:00 UTC on DST change and forgot to change the wiki
18:08:01 <sgallagh> t8m: Well, if this time works for everyone, it's already blocked out for most of us already :)
18:08:36 <t8m> sgallagh, yeah, on the other hand we might find a better time - f.e. notting was really on tight schedule on mondays
18:08:56 <sgallagh> #proposal Set up a whenisgood and revisit next week
18:09:03 <t8m> sgallagh, +1
18:09:27 <mitr> +1, can't hurt
18:09:28 <mmaslano> +1 on sgallagh proposal
18:09:33 <limburgher> +1, I'm flexible.  Mostly.
18:09:35 <sgallagh> +1 might as well
18:09:37 <nirik> sure. Might do a ticket so everyone knows what the whenisgood is and can note when they have completed it.
18:09:50 <t8m> yeah
18:10:04 <sgallagh> #agreed Set up a whenisgood and revisit next week
18:10:13 <sgallagh> Who wants to set it up? (I'll do it if no one else wants to)
18:11:06 <limburgher> I can.
18:11:27 <nirik> cool.
18:11:33 <sgallagh> #action limburgher will set up the whenisgood and create a FESCo ticket
18:12:04 <sgallagh> Ok, moving on
18:12:11 <sgallagh> Follow-ups:
18:12:15 <sgallagh> #topic #712 need update kBuild on F15
18:12:16 <sgallagh> .fesco 712
18:12:17 <zodbot> sgallagh: #712 (need update kBuild on F15) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/712
18:12:35 <nirik> no reply from maintainer I fear. ;(
18:13:18 <mitr> There is a comaintainer (laxathom) - I have tried to ping him today, but I wasn't successful either.
18:13:32 <t8m> no reply -> update allowed :D
18:13:54 <sgallagh> t8m: I think we should follow the non-responsive maintainer policy here
18:13:58 <nirik> yeah, proposal: get a provenpackager to do the update.
18:14:05 <nirik> we could do that too.
18:14:06 <limburgher> lkundrak is usually more responsive that this, but he's been great with PPs helping out.
18:14:17 <mitr> FWIW, last meeting's minutes say:
18:14:19 <mitr> AGREED: attempt to follow up with lkundrak on the ticket; if no response by next week have a provenpackager do it  (ajax, 18:18:38)
18:14:19 <t8m> sgallagh, I do not think it is strictly necessary for the update
18:14:31 <limburgher> t8m: <nods>
18:14:38 <mitr> nirik: btw, which "a provenpackager"?
18:14:39 <limburgher> Do we have a PP lined up to do the update?
18:14:40 <sgallagh> mitr: Works for me.
18:14:51 <nirik> I can do it if no one else wants to.
18:15:10 <limburgher> I could as well.  Flip?
18:15:32 <nirik> go ahead and do it. ;) thats fine with me
18:15:50 <sgallagh> Just to be cautious: what's the word on backwards-compatibility for kBuild?
18:15:53 <nirik> mitr: anyone who is in the provenpackager group and can commit to almost any package.
18:16:21 <mitr> nirik: Sure, I just didn't want to end up with "ticket closed, nobody to help".
18:16:29 <nirik> yeah, agreed.
18:16:58 <limburgher> So we're just backporting what's in f16 to f15, if I read correctly?
18:17:00 <sgallagh> #action limburgher to update kBuild with his provenpackager powers
18:17:50 <sgallagh> limburgher: I believe so, yes
18:18:00 <nirik> limburgher: yeah.
18:18:12 <limburgher> sgallagh, nirik: Gotcha.
18:18:33 <sgallagh> Ok, moving on
18:18:40 <sgallagh> #topic #470 Look at buildid repo request from jkratoch
18:18:40 <sgallagh> .fesco 470
18:18:41 <zodbot> sgallagh: #470 (Look at buildid repo request from jkratoch) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/470
18:19:51 <nirik> Darkserver has been proposed... off hand it seems like it won't be too hard to setup.
18:19:53 <sgallagh> Ok, so as I understand it, the Darkserver folks have requested resources from INfra?
18:20:01 <nirik> I'm not sure what fesco action we can have here. :)
18:20:12 <nirik> yes.
18:20:29 <sgallagh> I agree, this sounds like an Infra issue.
18:20:30 <t8m> I thought just that we could issue some statement whether we see the darkserver as a useful thing.
18:21:09 <nirik> I think the best thing people could do to get this moving along is contribute to it. Ideally we want a pool of people who understand and can manage a resource before just blindly deploying it.
18:21:22 * mitr would somewhat prefer integration of darkserver with the RPM mirror built by retrace-server, but that's up to infra really
18:21:30 * sgallagh whistles innocently something that sounds like ReviewBoard.
18:21:42 <limburgher> It looks like little impact except to those who
18:21:46 <limburgher> 'd be using it.
18:21:53 <limburgher> Stupid \n\r
18:22:01 <sgallagh> limburgher: And of course load on the Infra systems
18:22:03 <limburgher> If I'm reading correctly.
18:22:06 <sgallagh> And disk space
18:22:08 <mitr> nirik: darkboard is really small - a few hundred lines of code.
18:22:13 <limburgher> sgallagh:  oh, well, that. :)
18:22:14 <nirik> sure.
18:22:27 <limburgher> mitr: But the data might be another matter.
18:22:30 <nirik> yeah, another instance, another thing to keep secure, another thing to watch for and fix problems on, etc. ;)
18:22:45 <nirik> There's always a cost to deploying a service, but this one seems pretty self contained.
18:22:53 <nirik> and small on resources
18:22:58 <mmaslano> anyway, this is for infrastructure people
18:23:17 <limburgher> Devil's advocate for the example.  If you have a crash, wouldn't you typically restart with the updated version, and if it crashes, trouble shoot that?
18:23:19 <nirik> there's also talk of a koji plugin.
18:23:21 <sgallagh> proposal: Throw this over the wall to Infra. FESCo takes no action.
18:23:36 <mitr> sgallagh: +1
18:23:37 <nirik> limburgher: yeah, often...
18:23:41 <nirik> sure, +1
18:23:42 <t8m> sgallagh, no problem with that +1
18:23:50 <limburgher> +1
18:23:55 <mitr> limburgher: I have no idea how to reproduce 90% of the abrt crashes
18:23:57 <limburgher> nirik: I mean, not always, but. . .
18:24:02 <sgallagh> limburgher: Many organizations won't ever update without a multi-month testing environment
18:24:04 <limburgher> mitr:  Ditto.
18:24:11 <mmaslano> +1
18:24:16 <limburgher> sgallagh:  Often that's wise.
18:24:25 <sgallagh> #agreed Throw this over the wall to Infra. FESCo takes no action.
18:24:41 <sgallagh> limburgher: Not disagreeing. Just saying that you can't always restart with the updated version in reality
18:24:54 <sgallagh> Sometimes they need to report a bug and be told "It's fixed in the latest release"
18:24:55 <nirik> sgallagh: fedora using orgs?
18:25:04 <sgallagh> nirik: I know of a few
18:25:08 <nirik> k
18:25:10 <limburgher> sgallagh:  Agreed.  Just less often.
18:25:33 <sgallagh> Ok, on to new business?
18:26:01 <sgallagh> rbergeron put together some Features for us to review just before the meeting, so let's hit those before we get to the provenpackager question
18:26:13 <t8m> OK
18:26:32 <sgallagh> #topic #714 Feature request F17 D2 programming
18:26:34 <sgallagh> .714
18:26:42 <sgallagh> .fesco 714
18:26:43 <zodbot> sgallagh: #714 (Feature request F17 D2 programming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/714
18:27:10 <nirik> sure, +1
18:27:25 <t8m> +1 with the usual disclaimer about the feature process
18:27:48 <limburgher> +1
18:27:48 <mmaslano> looks good +1
18:28:08 <sgallagh> +1 as well
18:28:14 <mitr> +1 if this is entirely new
18:28:40 <sgallagh> mitr: As I understand it, the D compiler existed, but none of the rest of the development tools
18:29:00 <nirik> yeah, this is an enchancement for D developers... ie, good press mostly.
18:29:11 * sgallagh counts +6
18:29:25 <sgallagh> #agreed D2 Programming accepted as a Feature for Fedora 17
18:29:35 <sgallagh> #topic #716 Thin Provisioning - https://fedoraproject.org/wiki/Features/ThinProvisioning
18:29:35 <sgallagh> .fesco 716
18:29:36 <zodbot> sgallagh: #716 (F17 Feature: Thin Provisioning - https://fedoraproject.org/wiki/Features/ThinProvisioning) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/716
18:29:56 <snitm> I can field thinp questions
18:31:12 <sgallagh> I don't have any questions. Looks straightforward to me. +1
18:31:30 <mitr> +1
18:31:35 <mmaslano> +1
18:31:39 <t8m> +1
18:31:56 <limburgher> +1 Looks like a very good thing.
18:32:02 <nirik> snitm: is there any plans to add libvirt or other support? or thats down the road?
18:32:05 <nirik> +1 in any case.
18:32:45 <snitm> nirik: we're working to make sure we have the pieces in place so that virt can easily consume it
18:32:54 <nirik> yeah. makes sense.
18:33:07 * sgallagh counts +6
18:33:21 <sgallagh> #agreed Thin Provisioning is accepted as a Feature for Fedora 17
18:33:30 <sgallagh> #topic #717 Password Quality Checking - https://fedoraproject.org/wiki/Features/PasswordQualityChecking
18:33:30 <sgallagh> .fesco 717
18:33:31 <zodbot> sgallagh: #717 (F17 Feature: Password Quality Checking - https://fedoraproject.org/wiki/Features/PasswordQualityChecking) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/717
18:33:40 <t8m> This is my feature so I'll abstain.
18:33:50 <t8m> Any questions?
18:34:23 <limburgher> t8m: It's more for enabling consistency, than anything?
18:34:31 <sgallagh> t8m: This is applicable only to local users, correct?
18:34:34 <nirik> interesting. Is there a list of the rules/things that are checked?
18:34:44 <t8m> limburgher, consistency and a little bit of new features
18:35:06 <limburgher> t8m: Right.
18:35:11 <mitr> t8m: pam_{cracklib,passwdqc} willl continue to be shipped, right?
18:35:35 * nirik wonders if we couldn't use this also in fas
18:35:37 <t8m> nirik, not really comprehensively - but by looking at the configuration file manpage or the pam_pwquality manpage you can find it out
18:35:51 * sgallagh wonders how this will play with centrally-managed password changes that have their own quality constraints.
18:35:56 <t8m> nirik, sure no problem with using it for other things than system accounts
18:36:11 <t8m> sgallagh, definitely not worse than pam_cracklib
18:36:24 <sgallagh> t8m: Setting the bar pretty low there ;-)
18:36:34 <limburgher> sgallagh: One would hope the stricter of the two would win.
18:36:34 <t8m> mitr, pam_cracklib is basically obsoleted by it but it will be shipped
18:36:43 <nirik> cool, so +1 here. I'd like to see a nice page of checks if possible... but the idea is fine.
18:36:57 <sgallagh> limburgher: Right, but it becomes confusing to the users, especially if they end up being mutually unsolvable
18:37:27 <t8m> sgallagh, being mutually unsolvable is not too probable combination of rules
18:37:30 <sgallagh> i.e. The server sets a minimum length of 12 characters, but pam_pwpolicy sets a max of 10
18:37:48 <limburgher> sgallagh:  Good point.
18:38:02 <t8m> sgallagh, it is pam_pwquality but there is no rule for max password length - so this is not a real scenario
18:38:07 <sgallagh> ok
18:38:17 <limburgher> Good.  :)
18:38:21 <sgallagh> t8m: I'm +1 for the feature. I just want to keep the edge-cases in mind :)
18:38:24 <mmaslano> +1
18:38:42 <t8m> sgallagh, I do not know if current servers have max lenght policy rules often
18:38:42 <sgallagh> Edges tend to be sharp
18:38:44 <limburgher> +1
18:38:58 <sgallagh> t8m: I know of some that do, because legacy apps connect to them with limited space
18:39:34 <t8m> sgallagh, the default will be almost identical to what pam_cracklib enforces now
18:39:45 <sgallagh> ok
18:39:57 <t8m> sgallagh, so this is just a matter of consistent setup by sysadmin if he wants to change the rules
18:40:16 <sgallagh> As I said, I'm +1
18:40:23 <sgallagh> I only count +4 so far, though
18:40:29 * mitr is +1, but perhaps should be counted as "abstain" because he is a little involved in the project.
18:40:38 <nirik> t8m: oh, is it possible to easily change rules for local policies? ;)
18:41:02 <sgallagh> mitr: Well, if two people abstain, we lack quorum for this question :)
18:41:15 <t8m> mitr, please don't abstain :D
18:41:20 <mitr> nirik, sgallagh: https://fedorahosted.org/libpwquality/browser/src/pwquality.conf
18:41:25 <limburgher> I'm in Chicago, I could vote a second time. . .
18:41:35 <nirik> thanks.
18:41:49 <t8m> mitr, and I do not think that your involvement is that deep to disallow your vote :D
18:41:58 <sgallagh> I don't see any problem with a FESCo member voting for their own proposal
18:42:07 <sgallagh> Abuse is half the fun of having power :)
18:42:08 <mitr> Whatever, I just want to be transparent.
18:42:38 <t8m> so I count +5 with mitr
18:42:39 <limburgher> Do what must be done </Palpatine>
18:42:43 <sgallagh> #agreed New password quality mechanism is approved as a Feature for Fedora 17
18:43:02 <sgallagh> #topic #715 Provenpackager education/status/brainstorming
18:43:02 <sgallagh> .fesco 715
18:43:04 <zodbot> sgallagh: #715 (Provenpackager education/status/brainstorming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/715
18:43:19 <sgallagh> So this got angry quickly.
18:43:38 <nirik> so, I filed this ticket not to blame anyone, I just thought we could do better here and see if we could come up with ideas to improve communication.
18:44:22 <nirik> so, not sure if we want to try and educate pp's more, note more rules about when/if you should commit something, or just do nothing.
18:44:29 <sgallagh> I'm not sure we can define rules for common courtesy
18:44:46 <mmaslano> nirik: yes, provenpackager should ask before push, but in many SIG groups people use provenpackager as possibility to maintain all related languages
18:45:02 <limburgher> I think a lot of the fear is over the unorthodox commit and what that might signal.
18:45:25 <limburgher> And that it was yum.
18:45:25 <nirik> I think initially it was that...
18:45:26 <sgallagh> Yeah, it implies that someone was granted provenpackager without a sufficient understanding of packing
18:45:29 <sgallagh> *packaging
18:45:41 <limburgher> sgallagh: There is that possibility.
18:45:49 <nirik> FWIW, a number of provenpackagers were grandfathered in from long ago...
18:45:57 <mitr> Let's separate the two, 1) provenpackager with insufficient understanding, and 2) ways to handle such provenpackagers.
18:46:00 <nirik> they may not be as up on the current setup as they used to be
18:46:00 * limburgher was
18:46:27 <mitr> On 2), I'm inclined to add no rules, and deal with the problems in FESCo (something like 2 warnings -> revocation).
18:46:34 <mitr> I don't know about 1).
18:46:34 <t8m> Perhaps there should be a way how to 'expire the provenpackager status'?
18:46:40 <sgallagh> mitr: +1 to 2)
18:47:10 <sgallagh> t8m: I think mitr's "three strikes" approach is better
18:47:22 <limburgher> t8m: Can we revoke that status, and say "reapply later after demonstrating your readiness"?
18:47:26 <sgallagh> (Of course, in the case of malicious intent, one strike)
18:47:31 <mitr> right
18:47:34 <nirik> I don't know that there's any kind of systematic problem... this might be rare (at least I haven't noticed too many more recently)
18:47:42 <mitr> t8m: That would just flood the sponsors list.
18:47:58 <sgallagh> To be fair, I made a similar gaffe not too long ago, but worked it out with the maintainer.
18:48:11 <sgallagh> (Mass-rebuild situation that goofed with openchange)
18:48:17 <mmaslano> I guess usually maintainer revert it
18:48:24 <t8m> I mean there would have to be a way how to find out if someone used their provenpackager rights 'recently'
18:48:41 <limburgher> Should be have stricter PP rules for cripath?
18:48:43 <t8m> so if he did not use it for f.e. more than a year -> expire automatically
18:49:02 <sgallagh> Actually, it would be interesting to get stats on which packages are updated by a pp
18:49:20 * abadger1999 more interested in just seeing better communication.
18:49:22 <mmaslano> t8m: that could lead to pushes in the last minute ;-)
18:49:24 <limburgher> It would.
18:49:27 * nirik is with abadger1999.
18:49:33 <mitr> I'm in general in favor of having many PPs, using this infrequently, but not being afraid to.
18:49:34 * limburgher is also.
18:49:46 <sgallagh> Yeah, communication is the real problem
18:49:54 <abadger1999> if a provenpackager is willing to learn, no need to expire them/ban them from critpath packages/etc
18:50:02 <t8m> abadger1999, nirik, sure, better communication is always better :D
18:50:03 <limburgher> abadger1999: <nods>
18:50:33 <sgallagh> I suggest we leave it up to the package maintainers to either work it out or ask FESCo to step in on a case-by-case basis.
18:50:47 <mmaslano> I agree with sgallagh
18:50:48 <limburgher> There are many cases where a PP or comaintainer does a lot of work on a package they don't own.  if the owner is communicated with, they're usually OK with it.  I know I am. :)
18:50:52 <nirik> especially for projects with large numbers of bugs, I think it could be difficult to ask maintainers to always answer in bug repots.
18:50:54 <t8m> the expiration is just good thing from the 'security POV'
18:51:18 <t8m> I do not think it would be real improvement for this concrete case anyway
18:51:24 <nirik> t8m: I guess that would also imply expiring sponsors as well (since all sponsors are pp)
18:51:39 <mitr> t8m: I don't think PPs "turn bad" with age that way.
18:51:57 <limburgher> Was the offending pp in this case only recently a pp?
18:52:20 <mitr> http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/107577 suggests 2009/03
18:52:21 <t8m> limburgher, no I think he became PP in 2009
18:52:24 <nirik> I wouldn't mind adding a bit to the page about modifying packages as a pp to ask they try alternative channels of communication...
18:53:12 <nirik> but not sure thats going to catch everyone, or that people read it. ;)
18:53:14 <limburgher> t8m:  Then I'm confused about how he managed to upload the patch into lookaside.  I mean, I know *how*, but not how he thought that was normal practice.
18:53:27 <t8m> nirik, I'd mention also that it is expected in case of high-profile packages with active maintainers
18:53:29 <mitr> i'm not quite sure what the right thing is when a responsive maintainer just doesn't care about a low-priority bug
18:53:39 <limburgher> t8m:  Mistakes happen, obviously, but it just seemed odd to me.
18:54:18 <nirik> mitr: I think many would just say 'go ahead and do it if you care about the bug'... but of course there could be reasons not to.
18:54:18 <t8m> limburgher, I'd suppose he does not know either git or fedpkg really thoroughly
18:55:27 <limburgher> t8m:  Right.  Which is odd, given it's not like that migration was recent.  So I understand how one could get the impression that it could be malicious.  lookaside upload emails have a hash, git commits have a diff.
18:55:30 * sgallagh sticks with his proposal
18:55:33 <nirik> so, I could work on some proposed wording changes to the modify package page... what other concrete actions would people like to take in this case.
18:55:37 <limburgher> t8m: not saying it was, mind you.
18:56:24 <mmaslano> nirik: I would take some action case by case if maintainer is complaining
18:56:32 <t8m> limburgher, well basically if you use the fedpkg this incorrect way for your own packages you probably won't notice that it is wrong way
18:56:40 <limburgher> I think that's wise.  It's a soft enough situation that more rules might be hard to usefully codify, but simply saying "flag FESCO if you have a problem" might be best.
18:57:10 <limburgher> t8m:  Right, nor would anyone else, necessarily.  Like if you fedpkg import a srpm every time. <shudder>
18:58:20 <nirik> proposal: nirik to write up some proposed wording changes, revisit next week?
18:58:27 <t8m> sgallagh, what was your proposal again?
18:58:39 <sgallagh> I suggest we leave it up to the package maintainers to either work it out or ask FESCo to step in on a case-by-case basis.
18:58:55 <t8m> nirik, +1 to your self inflicted action :D
18:59:07 <mitr> sgallagh: that is in general, or in this specific situation?
18:59:12 <nirik> sgallagh: ok, so close and ask maintainers to re-open if they want further action?
18:59:20 <sgallagh> general
18:59:54 <nirik> sgallagh: sure, I'm +1 to that, but I think adding some wording might help prevent issues down the road.
19:00:26 <sgallagh> nirik: Well, the provenpackager nomination process should be doing that
19:00:44 <mitr> The current nomination process (3 explicit +1s) really seems like a strong enough barrier
19:00:45 <sgallagh> I'm willing to believe this was an isolated incident and that we're giving it too much thought, honestly.
19:01:13 <nirik> ok.
19:01:15 <limburgher> Entirely possible, but I'd rather burn a few brain cycles than let something nefarious go.
19:01:38 <mmaslano> I'm ok with rephrasing rules on wiki, but that doesn't force provenpackagers to read it (again)
19:01:46 <limburgher> mmaslano: :)
19:02:05 <nirik> mmaslano: true. we could also mail them when we make the change. ;)
19:02:12 <nirik> there's a handy alias with all of them on it.
19:02:38 <mmaslano> most of them are using their powers for good and they would be  bothered with something useless for moste of them
19:02:40 <sgallagh> Well, maintainers get an email whenever something changes.
19:03:01 <sgallagh> I doubt a nefarious change would go unnoticed very long
19:03:37 <nirik> well, I'm more trying to prevent cases of friction between pp's and maintainers.
19:04:00 <mitr> Looking at the timeline, bug filed 11-02, patch attached 11-18, maintainer pinged 11-30, PP commit 12-09.  I think using the PP privileges in this case was reasonably justified.
19:04:04 <limburgher> nirik: Right.
19:04:18 <nirik> but if everyone else thinks we should just drop it, ok.
19:04:23 <mitr> ... which means we only need
19:04:25 <mitr> proposal: ondrejj advised to make sure he understands the processes before using his privileges in the future.
19:05:06 <sgallagh> mitr: +1
19:05:17 <mmaslano> yes, +1
19:05:31 <nirik> ok, so someone needs to speak with them and confirm that?
19:05:33 <nirik> sure, +1
19:05:46 <sgallagh> mitr: Are you volunteering?
19:05:53 <t8m> mitr, +1
19:05:53 <limburgher> +1
19:06:39 <sgallagh> #agreed ondrejj advised to make sure he understands the processes before using his privileges in the future
19:06:46 <mitr> sgallagh: to tell him the above? sure.
19:07:03 <sgallagh> #action mitr to advise ondrejj on process
19:07:04 <nirik> so, I'll hold off on doc changes? or do folks still think thats ok to do?
19:07:25 <limburgher> nirik: Drafting or changing?
19:07:42 <sgallagh> nirik: Send a draft of the changes to the list
19:07:49 <nirik> was going to draft, but if we don't think changes are needed, I can just not bother. ;)
19:08:07 <sgallagh> I'm not opposed to it, but I don't think it's really needed
19:08:15 <limburgher> May as well wait.
19:08:28 <nirik> ok, will hold off.
19:08:32 <nirik> next topic?
19:08:43 <sgallagh> #topic Engineering Service Tickets
19:08:47 <sgallagh> Anything?
19:09:02 <nirik> nope, feel free to contact me if you want to get things moving along there.
19:09:07 <nirik> or I might try over the holidays perhaps.
19:09:34 <sgallagh> Ok
19:09:37 <sgallagh> #topic Open Floor
19:09:47 <sgallagh> Any topics for the Open Floor?
19:09:52 <nirik> I have 2 items.
19:09:59 <sgallagh> Fire at will
19:10:23 <nirik> 1. Holidays are coming up... are we meeting on the 19th, the 26th, or the 2nd?
19:10:42 <sgallagh> I'll be around for the 19th
19:10:44 * nirik notes the 26th and 2nd are mandatory shutdown/holidays for RH.
19:10:54 <sgallagh> I will likely not be available the following two days
19:11:01 <limburgher> I won't be around for 26th.
19:11:05 <mmaslano> 2nd is not mandatory, at least I believe
19:11:17 <sgallagh> We might consider rescheduling the 2nd though
19:11:23 <nirik> mmaslano: yeah, it is, they just had it on the 2012 calendar. ;)
19:11:36 <sgallagh> Also we should note that the meeting time may shift when the whenisgood is complete
19:11:37 <mmaslano> nirik: you are kidding
19:11:49 <nirik> at least from my reading it is. ;)
19:11:54 <mmaslano> ok, I can take 19th
19:12:04 <nirik> true... so I guess lets decide at the 19th meeting.
19:12:10 <sgallagh> mmaslano: We weren't deciding on chair yet, but thank you for volunteering :)
19:12:25 <mitr> I'll be here for 19th, 26th probably not.
19:12:39 <nirik> also, notting said he could do next week.
19:12:41 <t8m> sgallagh, notting wrote in the e-mail that he'll take the next chair
19:12:49 <sgallagh> ah, I missed that
19:12:52 <mmaslano> sgallagh: ha
19:12:52 * limburgher will workout how to work whenisgood shortly. :)
19:13:08 <nirik> ok, second item:
19:13:34 <nirik> Just a reminder: Mailing list server is migrating later today at 22:00 UTC. So if you notice posts not happening then, it's because we are moving things. ;)
19:13:47 <nirik> and on wed we will be migrating fedorahosted.org.
19:13:53 <nirik> Just FYI.
19:14:10 <nirik> thats all I had.
19:14:13 <sgallagh> nirik: How badly do you expect this to fall apart?
19:14:20 <sgallagh> (no migration is ever perfect)
19:14:45 <nirik> I'm hoping it to go pretty smoothly. ;) we have done a fair bit of testing and tweaking.
19:15:03 <nirik> the collab move is to rhel6, but the mailman version is pretty close to the same.
19:15:18 <sgallagh> ok, just curious
19:15:34 <nirik> hope for the best, plan for the worst. ;)
19:15:36 <sgallagh> The posts that don't happen while migrating; are those being captured and stored for later delivery?
19:15:48 <nirik> yep. They will queue and deliver when the new server is ready for them
19:15:55 <sgallagh> nirik: As the Russians say "Pray to God, but row for shore"
19:16:10 <nirik> ha
19:16:22 <limburgher> Cool.
19:16:52 <mitr> I'm new here, so...
19:17:11 <mitr> 1/2 There are ~20 tickets on the fesco tracker without the "meeting" keyword.  Do we just leave them there?
19:17:13 <sgallagh> mitr: Oh right, we forgot the hazing ;-)
19:17:39 <limburgher> <covers head>
19:17:41 <nirik> it would be good to go thru them at some point and resolve them for sure.
19:17:54 <mitr> 2/2 Is there a way to get mail notification on the tickets?
19:18:09 <mmaslano> mitr: you should be added into fesco list
19:18:13 <mmaslano> mitr: all changes go there
19:18:23 <nirik> mitr: oh yeah. I need to change the mailing list for membership changes.
19:18:27 * nirik does so.
19:18:51 <sgallagh> #action nirik to update the FESCo mailing list for membership changes
19:18:59 <mitr> nirik: thanks!
19:19:44 <sgallagh> Anything else for open floor?
19:20:29 <limburgher> Nothing here.
19:21:01 * nirik has nothing.
19:21:07 <sgallagh> Ok, I'll close the meeting in one minute if no one has anything else
19:22:08 <sgallagh> #endmeeting