17:01:41 <geppetto> #startmeeting fpc
17:01:41 <zodbot> Meeting started Thu Dec 18 17:01:41 2014 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:41 <geppetto> #meetingname fpc
17:01:42 <zodbot> The meeting name has been set to 'fpc'
17:01:42 <geppetto> #topic Roll Call
17:02:15 <geppetto> geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ spot tibbs|w tomspur: FPC ping
17:02:29 <orionp> morning
17:02:36 * dwmw2_gone blinks. https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee says this meeting was an hour ago
17:03:08 <geppetto> dwmw2_gone: the fedora calendar has the correct time
17:03:15 <geppetto> dwmw2_gone: it changes with DST
17:03:22 <geppetto> #chair orionp
17:03:22 <zodbot> Current chairs: geppetto orionp
17:03:37 <tibbs|w> Howdy.
17:03:43 <geppetto> #chair tibbs|w
17:03:43 <zodbot> Current chairs: geppetto orionp tibbs|w
17:03:49 <geppetto> hey tibbs
17:04:04 <mbooth> Hi
17:04:06 <tibbs|w> Sorry, they pushed up a big office move from Monday to today so I'm in and out.
17:04:16 <geppetto> #chair mbooth
17:04:16 <zodbot> Current chairs: geppetto mbooth orionp tibbs|w
17:04:23 * Rathann here
17:04:27 <geppetto> #chair Rathann
17:04:28 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs|w
17:04:39 <dwmw2_gone> geppetto: https://apps.fedoraproject.org/calendar/packaging/#m1663 also has it as an hour ago. But OK :)
17:05:18 <geppetto> hmmm, ok thanks
17:05:27 <tibbs|w> I so dislike DST.
17:05:28 <geppetto> I thought tom said he'd fixed it
17:05:46 <tibbs|w> dwmw2_gone: But when you asked me, I swear I said 17:00Z.
17:06:29 <geppetto> dwmw2_gone: but the block is in the correct place … 17-18 UTC
17:06:51 <dwmw2_gone> If you did I think I miossed it; I looked it up. Anyway, we're here now (although babies are home and I should have finished work). No matter.
17:07:30 <geppetto> ok, we have enough to start
17:07:40 <geppetto> dwmw2_gone: Which ticket did you want to talk about … can do that first
17:07:45 <dwmw2_gone> thanks
17:07:52 <dwmw2_gone> https://fedorahosted.org/fpc/ticket/480
17:08:07 <geppetto> #topic #480 	Packaging guidelines for consistent PKCS#11 usage
17:08:11 <geppetto> https://fedorahosted.org/fpc/ticket/480
17:08:32 <dwmw2_gone> so I anticipate the question "why is this a *packaging* guideline?"
17:08:36 <tibbs|w> I support this generally.
17:08:54 <tibbs|w> Actually this is pretty much in line with things like the system security policy stuff.
17:08:58 <dwmw2_gone> to which the answer is that it often depends on *how* you build and configure the package. The choice of crypto library to build against, and the default config file you ship with
17:09:03 <tibbs|w> At least I think it is.
17:10:13 <dwmw2_gone> yes. This is the next step that we talked about after the coherent trust policy with p11-kit-trust, that landed in F19.
17:10:29 <tibbs|w> For me it comes down to details of exactly how package reviewers are supposed to know this stuff.
17:11:00 <geppetto> So we kind of have the power t say things like "you must build your app with XYZ option"
17:11:23 <geppetto> But we don't really have the power to say things like "you must write code to support XYZ"
17:11:29 <tibbs|w> Indeed.
17:11:31 <dwmw2_gone> tibbs|w: I can provide help with *testing*, and also I think you suggested looking in the documentation.
17:11:37 <dwmw2_gone> and if they get it wrong, I can file bugs :)
17:11:41 <Rathann> I'd appreciate some way of testing without VPN
17:11:41 <dwmw2_gone> geppetto: agreed.
17:11:50 <dwmw2_gone> I'm not saying "you must write code to..."
17:11:57 <tibbs|w> geppetto: It does have "should" all around in any case.
17:12:17 <dwmw2_gone> I'm doing that bit. Current summary at http://sourceforge.net/p/opensc/mailman/message/33164370/
17:12:43 <dwmw2_gone> I have wpa_supplicant working nicely, which was blocking some of the stuff they wanted to do to clean this up in NetworkManager.
17:12:44 <dwmw2_gone> etc.
17:13:07 <dwmw2_gone> this is just about "if it's available, please use it" :)
17:13:44 <geppetto> So in the client applications part, there are three things which are all SHOULD … but I don't see how those happen, would it be obvious to anybody packaging those apps. … to a reviewer?
17:14:02 <Rathann> dwmw2_gone: how do we check these "SHOULD"s ?
17:14:13 <dwmw2_gone> I would expect that the packager has some clue what the application does, and if it can use SSL client certificates or not.
17:14:25 <geppetto> The PKCS#11 providers part seems easier … a file needs to be added somewhere, if your package does something … explain what the file looks like, and how you tell if your package applies
17:15:07 <dwmw2_gone> Didn't I link to the p11-kit documentation on that? I can certainly add that. And anyone packaging a PKCS#11 provider library will know that they are doing so, so I'm not worried about "how you tell if your package applies" :)
17:15:44 <geppetto> dwmw2_gone: Ok … yeh :)
17:16:24 <geppetto> the client apps. bit seems the sticker one anyway … as I imagine a bunch of stuff uses SSL in some form, but packagers will have no clue about PKCS#11
17:17:02 <geppetto> For instance … I assume curl/urlgrabber/yum should be able to use those things
17:17:18 <dwmw2_gone> does yum use client certificates for authentication?
17:17:22 <geppetto> dwmw2_gone: yeh
17:17:23 <dwmw2_gone> curl yes; I need to fix that :)
17:17:33 <dwmw2_gone> It's on my list.
17:18:00 <geppetto> dwmw2_gone: sslclientcert in yum.conf man page
17:18:06 <dwmw2_gone> ok, I'll add it to my list :)
17:18:18 <geppetto> dwmw2_gone: probability that it lets you use a yubikey though … probably near 0% :)
17:18:21 * Rathann looks at OpenVPNs way of specifying the cert store... yuck
17:18:43 <dwmw2_gone> Rathann: :) My build accepts a standard PKCS#11 URI :)
17:18:57 <dwmw2_gone> my OpenVPN patches got acked; waiting for the pkcs11-helper library pull request to go in.
17:19:18 <dwmw2_gone> anyway, I don't think it's a sticking point if packagers sometimes miss this.
17:19:18 <Rathann> and that's something I'm very much in favour of
17:19:47 <dwmw2_gone> we can file bugs and get them to look at changing, if we need to
17:20:25 <dwmw2_gone> but the existence of the guideline will be a useful motivation factor in *getting* them to change, for example "please build with GnuTLS instead of OpenSSL".
17:20:39 * Rathann looks at the tracker bug
17:20:41 <dwmw2_gone> or "please apply this patch which is backported from the upstream HEAD where they just accepted my patches"
17:21:00 <tibbs|w> All I ask is that you consider that generally guidelines are about giving packagers and reviewers enough information to get it right initially.  Not just about having something you can point to when telling people they're doing it wrong.
17:21:14 <dwmw2_gone> understood.
17:21:26 <tibbs|w> That means providing at least general documentation about how to verify these things.
17:21:44 <dwmw2_gone> it might make sense to provide a wiki page or something, and refer to it from the guideline. With some "how to tell" and "how to test" instructions.
17:21:52 <geppetto> Yeh, again … I have no problem ACKing the desire for "All of these should just take a simple PKCS#11 URI and Just Work™."
17:22:00 <tibbs|w> geppetto: I agree.
17:22:22 <tibbs|w> dwmw2_gone: And, yes, I think there's a wiki hierarchy for that kind of thing already.
17:24:13 <dwmw2_gone> so...
17:24:25 <Rathann> dwmw2_gone: so the actual change to the Packaging Guidelines would be those four SHOULDs, correct?
17:24:25 <geppetto> #info General concensus that this is desirable
17:24:25 <geppetto> #action dwmw2 Add examples for common libraries/APIs, on the client applications.
17:24:26 <dwmw2_gone> assuming I put together some basic help for how to tell and how to test.
17:24:35 <dwmw2_gone> Rathann: yes.
17:24:47 <Rathann> and a link to a more detailed wiki page I guess
17:24:51 <dwmw2_gone> yeah
17:24:56 <Rathann> I'm +1 to that
17:25:23 <geppetto> dwmw2_gone: I would also merge rationale/expectations into backgroud at the top … basically a "this is what we want" section and then a "this is how to check that you have it"
17:25:55 <dwmw2_gone> yes. I added the background later, after tibbs' (I think) comment in the ticket
17:26:02 * geppetto nods
17:26:06 <dwmw2_gone> I'll clean that up
17:27:10 <geppetto> Ok, cool … anymore comments?
17:27:41 <geppetto> #topic #478 	Proposal: Package Guidelines: DevAssistant Assistant packages (DAP)
17:27:45 <geppetto> https://fedorahosted.org/fpc/ticket/478
17:28:08 <dwmw2_gone> thanks
17:28:10 * dwmw2_gone goes
17:28:54 <tibbs|w> I have to say, I still don't really know what devassistant does, but these guidelines seem clean to me.
17:29:19 <tibbs|w> However, there are some magic macros and I don't know what they do.
17:29:30 <tibbs|w> %repack_assistant, for example.
17:29:46 <Rathann> hm, shouldn't the macros be prefixed with underscore?
17:30:03 <Rathann> I mean the _path macros
17:30:09 <geppetto> yeh, %install_assist and %check_assist
17:30:31 <geppetto> Rathann: I thought we only did that for globals ones
17:30:55 <Rathann> hm
17:30:56 <geppetto> If you BR something to get new macros they could be non _ prefixed
17:31:00 <geppetto> but … not sure.
17:31:10 <Rathann> me neither :(
17:31:14 <geppetto> :)
17:31:24 <tibbs|w> Honestly I prefer macros without random underscores.
17:31:35 <tibbs|w> I mean, they're supposed to save typing.  What use is an underscore?
17:31:40 <Rathann> well, this is not an issue for me
17:31:43 <Rathann> just asking
17:31:47 <tibbs|w> Besides two extra keystrokes....
17:32:15 <tibbs|w> Now, the macros don't hide the section names within them, which is good.
17:32:22 <geppetto> yeh
17:32:24 <mbooth> It's a shame that "%install_assistant" doesn't generate a file list so you can "%files -f dap_files"
17:32:36 <mbooth> Personal preference though
17:32:49 <tibbs|w> mbooth: It's not a bad suggestion, really.
17:33:00 <tibbs|w> If this is so completely automated, then why not?
17:33:08 <orionp> agree
17:33:12 <tibbs|w> I guess tradej isn't here, though.
17:33:20 <mbooth> We do it in java land to reduce user-error
17:33:20 <geppetto> yeh, I guess he probably didn't know
17:33:30 <mbooth> I will add the suggestion to the ticket
17:33:52 <geppetto> Saying that, I think I'm happy to +1 this as is.
17:34:28 <orionp> license files?
17:34:53 <tibbs|w> And do we want to see the sekrit macros expanded in the guideline?
17:35:26 <orionp> they'll just get out of date, but....
17:35:49 <geppetto> tibbs|w: I'm not sure … I think we've let them stay secret in other policy, and people have changed them anyway even when they are expanded in policy
17:35:59 <tibbs|w> That's occasionally true.  It's something we've gone back and forth with before.
17:36:39 <tibbs|w> Note that the guideline does currently expand the pathname macros, which is fine.
17:36:59 <tibbs|w> Maybe a general explanation of what those do?
17:37:11 <tibbs|w> I'm just trying to avoid cargo cult specfile writing.
17:37:27 <Rathann> DAPs seem to be plain tar.gz files
17:38:27 <orionp> Looks like 0.10 isn't even in rawhide yet?
17:38:33 <orionp> or koji
17:38:38 <tibbs|w> You know, I think we should request a sample package which follows the guideline for most drafts.
17:39:04 <orionp> I've got a little issue...
17:39:24 <geppetto> orionp: Ahh, didn't notice that version requirement … that should be in the specfiles than too
17:39:30 <geppetto> *then too
17:39:43 <orionp> There are a number of dap-* packages already - for the OpenDAP server.
17:40:04 <tibbs|w> OOh.
17:40:09 <geppetto> ok, that's a biggish issue :)
17:40:15 <tibbs|w> yeah, that's ungood.
17:40:22 <orionp> well, 4 anyway
17:40:26 <tibbs|w> Do we just want "devassist-"?
17:40:59 <Rathann> devassistant-* to be consistent
17:41:02 <orionp> I would say devassistant-*
17:41:32 <Rathann> or talk to dap-* maintainers about renaming
17:41:45 <orionp> That would be me :)
17:41:48 <tibbs|w> Either is fine with me; I'd leave it to tradej but I think he should change it or provide a cogent argument against it.
17:41:52 <Rathann> oh
17:41:53 <Rathann> ok
17:41:58 <geppetto> yeh
17:42:19 <geppetto> I'm fine with any sane non-used name
17:42:31 <orionp> The exisiting dap-* names are not particularly appropriate
17:42:44 <tibbs|w> But I want to say again that this is a great draft.  If all submitted drafts were like this...
17:42:54 <orionp> +10
17:42:57 <geppetto> tibbs: yeh
17:44:41 <geppetto> #info Policy is awesome for a first draft, well done!
17:44:51 <Rathann> :D
17:45:12 <geppetto> #action Tradej Maybe create a filelist in %install_assistant and use %files -f?
17:45:34 <geppetto> #action Tradej Need the version requirement on devassistant 0.10 to be in the specfiles.
17:45:58 <geppetto> #action Tradej No LICENSE files in the specfiles.
17:46:15 <geppetto> #action Tradej Speak with orionp about the dap-* package name prefix.
17:46:28 <geppetto> what did I miss?
17:47:09 <geppetto> #action Tradej Create an example package for Fedora
17:47:20 <geppetto> Anymore comments?
17:47:23 <orionp> Looks good
17:47:44 <geppetto> #topic #479 	Remove F17 cruft from systemd macros
17:47:48 <geppetto> https://fedorahosted.org/fpc/ticket/479
17:48:39 <geppetto> Can anyone think of a reason not to?
17:49:21 <racor> RHEL?
17:49:34 <geppetto> el7 would be post Fedora 17 … and el6 didn't have systemd
17:49:36 <orionp> RHEL7 is F19+
17:49:41 <racor> OK
17:49:54 <geppetto> Ok, I'm +1
17:49:58 <orionp> +1
17:49:58 <racor> +1
17:50:03 <mbooth> +1
17:51:24 <geppetto> tibbs: ping?
17:51:57 <tibbs|w> +1
17:51:58 <geppetto> Rathann: ping?
17:52:01 <tibbs|w> Sorry, called out again.
17:52:21 <Rathann> +1
17:52:24 <geppetto> #action #479 	Remove F17 cruft from systemd macros (+1:6, 0:0, -1:0)
17:52:26 <tibbs|w> Though obviously I was +1 to my own suggestion.
17:52:32 <geppetto> #topic #483 	Temporary bundling exception request for ipsilon: jquery, bootstrap, patternfly
17:52:37 <geppetto> https://fedorahosted.org/fpc/ticket/483
17:53:17 <tibbs|w> I'm assuming these are all javascript?
17:53:42 <geppetto> "PatternFly is an open source web user interface framework promoting consistency and usability across IT applications through UX patterns and widgets"
17:53:44 <tibbs|w> Unfortunately no links or anything in the ticket.
17:53:48 <geppetto> … so I think so
17:54:05 <Rathann> it is
17:54:09 <Rathann> https://github.com/patternfly/patternfly
17:54:22 <Rathann> This reference implementation of PatternFly is based on Bootstrap v3. Think of PatternFly as a "skinned" version of Bootstrap with additional components and customizations.
17:54:22 <geppetto> "PatternFly layouts are constructed using the Bootstrap grid system to be responsive out of the box."
17:54:28 * geppetto nods
17:54:42 <tibbs|w> Tempted to delay just for not telling us that kind of essential stuff.
17:54:52 <geppetto> I guess "lol, JS packaging facepalm" … +1
17:55:23 <geppetto> tibbs: Don't we need to do a secret cabal meeting before we're mean like that :)
17:55:38 <Rathann> +1
17:56:06 <geppetto> #chair spot
17:56:06 <zodbot> Current chairs: Rathann geppetto mbooth orionp spot tibbs|w
17:56:07 <Rathann> how about we introduce a temporary blanket exception for all JS until the JS guidelines are fleshed out?
17:56:26 <mbooth> Who is working on js guidelines?
17:56:26 <geppetto> For web JS, I guess I could +1 that
17:56:58 <geppetto> I'm a little more worrid about JS that should be used locally
17:58:26 <geppetto> Proposal: Blanket exception for bundling all JavaScript for usage over the network (Eg. web UIs), until complete JavaScript policy is complete.
17:58:30 <geppetto> +1
17:58:44 <Rathann> hm...
17:59:02 * Rathann wonders what's missing https://fedoraproject.org/wiki/Packaging:Web_Assets https://fedoraproject.org/wiki/Packaging:JavaScript
17:59:18 <Rathann> looks like they are complete already...
17:59:41 <geppetto> did we vote them in, and have erased it from our memories?
18:00:33 <Rathann> web assets page was last updated by Toshio with a comment that draft was approved... in August 2013
18:00:49 <geppetto> so … why does jquery still have an exception?
18:01:01 <Rathann> same for JavaScript guideline
18:01:27 <mbooth> geppetto: Cosmic rays affecting memory? ;-)
18:01:51 <geppetto> "Temporary bundling exception for anything to bundle jquery until the systemwide jquery feature is ready"
18:01:56 <Rathann> ah
18:01:56 <geppetto> that's 408
18:02:06 <Rathann> jquery unbundling is targeted at F22
18:02:14 <Rathann> https://fedoraproject.org/wiki/Changes/jQuery
18:02:16 <Rathann> that's why
18:02:33 <tibbs|w> +1 for blanket javascript exception, though I would still want them to file tickets.
18:02:45 <tibbs|w> We can just ack in the tickets, but we need to keep the tickets for tracking.
18:03:25 <Rathann> so +1 from me as well
18:03:57 <geppetto> But we have the policy … so what's the end date ... forever ?
18:04:15 <Rathann> geppetto: for now it's F22 release date
18:04:20 <orionp> Yeah, I'm not sure why we're looking at a blanket exception
18:04:28 <geppetto> I'm now wondering if "Since these are not availabe as packages yet, there is no way to unbundle them. " just means "Nobody packaged them, yet … and it's easier for me to bundle than package them:
18:04:30 <orionp> jQuery, sure
18:04:44 <orionp> geppetto - agree
18:04:54 <orionp> Solution is - package them
18:05:02 <Rathann> true
18:05:15 <geppetto> yeh, seems good to me
18:05:32 <Rathann> how about s/blanket JS exception/blanket JS-depending on JQuery exception/ ?
18:05:44 <geppetto> Rathann: we have that in 408, right?
18:06:23 <Rathann> actually it only mentions bundling jquery itself
18:07:06 <geppetto> Proposal: Allow jQuery until F22, due to 408 blanket exception. But need reasons that bootstrap/patternfly can't just be packaged.
18:07:32 <Rathann> https://fedorahosted.org/fpc/ticket/413 should be closed, right?
18:08:00 <geppetto> it is closed
18:08:24 <Rathann> ah, right
18:09:01 <Rathann> so it looks like jQuery is "just" 6 dependencies away from being able to build on Fedora
18:09:11 <Rathann> according to the change status page
18:10:23 <tibbs|w> geppetto: +1 to your proposal
18:10:41 <tibbs|w> I think most folks don't realize we have general javascript guidelines.
18:10:51 <tibbs|w> Hell, I'm on FPC and somehow I didn't realize it.
18:11:35 <tibbs|w> Crickets....
18:11:46 <tibbs|w> Hope I didn't lag out.
18:11:52 <Rathann> no
18:12:23 <Rathann> I guess I'll have a chance to exercise using them while packaging some firefox addons
18:12:46 <Rathann> anyway, +1 to geppetto's proposal
18:12:55 <mbooth> Yeah, +1 from me too
18:13:29 <geppetto> ok … that's 4
18:13:43 <geppetto> well, obv. +1 from me
18:13:52 <geppetto> racor: orionp: vote?
18:13:56 <orionp> +1
18:14:00 <tibbs|w> It's obvious that bundling them wouldn't pass anyway, so they're going to need to justify regardless of how we vote.
18:14:11 <racor> +1
18:14:37 <geppetto> #action Allow jQuery bundling until F22, due to 408 blanket exception. But need reasons that bootstrap/patternfly can't just be packaged. (+1:6, 0:0, -1:0)
18:14:49 <geppetto> #topic #481 	static uids systemd-network, systemd-timesync, systemd-resolve
18:14:53 <geppetto> https://fedorahosted.org/fpc/ticket/481
18:15:06 <tibbs|w> Ugh.
18:15:11 <geppetto> yeh
18:15:33 <tibbs|w> I think is probably the only real good reason for static UIDs, and even then I think you could easily work around it.
18:15:35 <geppetto> Does anyone know wtf "host-independent initramfs images" are
18:16:01 <tibbs|w> I have no idea at all what that might be.
18:16:08 <Rathann> Please approve systemd-timesync, systemd.network, systemd-resolve users and groups. (Note: without the "d" at the end.)
18:16:08 <geppetto> tibbs: I disagree … NFS/shared storage seem like a much better usage and can't be worked around easily
18:16:20 <Rathann> I assume the . in systemd.network username is a typo?
18:16:35 <tibbs|w> Rathann: I don't know.
18:16:44 <geppetto> Rathann: I woudn't bet on that, given names can have dots in them
18:16:44 <tibbs|w> geppetto: The answer is... it depends.
18:16:47 <geppetto> it's just stupid
18:17:01 <geppetto> so … probably has a dot in it
18:17:07 <tibbs|w> When I see host-independent whatever...
18:17:25 <tibbs|w> I guess maybe they're trying to ship initramfs inages in the packages instead of generating them at kernel install time?
18:17:44 <geppetto> right … but … kernel modules etc.
18:17:49 <tibbs|w> But that doesn't really make sense to me.  Maybe it's some container thing instead.
18:18:02 <tibbs|w> The solution to kernel modules is to include all of them.
18:18:08 <geppetto> is there a big feature to make initramfs not be changed/generated on client systems
18:18:23 <geppetto> who is running with that etc.
18:18:26 <tibbs|w> I haven't heard of one.  If there was, they should have included a link in the ticket.
18:18:48 <tibbs|w> So, ask WTF "host independent whatever" is, and ask for clarification about the period versus dash thing?
18:19:02 <geppetto> Yeh
18:19:16 <tibbs|w> I doubt we need to vote on that.
18:19:53 <geppetto> #action Please explain what "host-independent initramfs images" means. Who is running with the feature, what is the timescale, what is it affecting, etc. etc.
18:20:56 <geppetto> #action If systemd.network is the correct username, please fix it to not have a dot in it.
18:21:51 <geppetto> Ok, that's all the new ones … I'm hungry, and it's near the holidays … does anyone else want to do a few more tickets?
18:21:59 <tibbs|w> I'm actually here.
18:22:27 <tibbs|w> If not, can we spend a few minutes about trac workflow and such?  Because I guess we have a disconnect.
18:22:52 <mbooth> Sure (to either :-)
18:23:02 <geppetto> #topic Open Floor
18:23:11 <orionp> I'm here for a few more mintue
18:23:11 <geppetto> Ok, yeh … I'm happy to either use 12 and 13 reports now
18:23:26 <geppetto> or to change 12 report to include meeting state too
18:23:38 <tibbs|w> I think the workflow is go through 12, move things to meeting if necessary for discussion.
18:23:54 <tibbs|w> That way any of us can just look at report 13 and know what need to be prepared to discuss.
18:24:22 <geppetto> yeh, the only problem with that is that people expect that if they open a ticket on Wednesday, we'll deal with it on Thursday … but if I only look at report 13, that is unlikely to be the case.
18:24:43 <tibbs|w> Maybe that wasn't enough time for us to prepare anyway.
18:25:10 <tibbs|w> Anyone is still welcome to bring it up; it could be trivial.
18:25:35 * geppetto shrug … yeh, I guess I can mostly find time to go through any new tickets on Wednesday and add meeting status to them.
18:25:36 <tibbs|w> But generally I think it would be better if we took care of as much as possible on our own and only dealt with things that _need_ a meeting in the meeting.
18:25:43 <tibbs|w> I can do some of that as well.
18:25:47 * geppetto nods
18:26:06 <tibbs|w> And a general apology for all of the trac spam.  I didn't realize just how much we haven't been dealing with.
18:26:33 <geppetto> no apology needed
18:26:34 * Rathann will try to look at old tickets during Christmas break
18:26:38 <tibbs|w> That announcement is going to be huge.  I will get to writeups this evening, hopefully.
18:26:57 <tibbs|w> geppetto: Will you have time to do an announcement or should I try and figure out how to do that?
18:27:14 <geppetto> This is my last day of work this year
18:27:17 <geppetto> so … no
18:27:40 <geppetto> unless you want to wait until next year for it
18:27:55 <tibbs|w> See, when I'm not working, I actually have time to do this stuff.
18:28:07 <tibbs|w> So, does the announcement mail go to devel or devel-announce, or both?
18:28:22 <geppetto> I think spot sent it to devel-announce
18:28:31 <tibbs|w> OK, I'll do that.
18:28:52 <tibbs|w> Think I should add an apology for the tardiness of some of the writeups?
18:29:01 <geppetto> no
18:29:08 <tibbs|w> I was vacillating.
18:29:16 * geppetto looks that word up
18:29:44 <tibbs|w> Changing my mind back and forth on the issue.
18:29:48 * geppetto nods
18:29:53 <geppetto> I'd say … def. no.
18:30:08 <geppetto> A few of the writeups happened anyway, just no announce
18:30:13 <tibbs|w> Yeah.
18:30:26 <tibbs|w> OK, I'll try to get to that today or tomorrow.
18:30:31 <geppetto> if all else fails … blame it on spot ;)
18:30:41 <tibbs|w> Easy enough.
18:30:46 <geppetto> :)
18:31:27 <geppetto> Ok … related to not being near a computer for a couple of weeks … I'm going to assume we aren't meeting again until next year
18:31:51 <geppetto> By which I mean the 8th
18:31:53 <tibbs|w> So, the 1st or the 8th.
18:31:59 <geppetto> jinx ;)
18:32:16 <Rathann> 8th
18:32:17 <tibbs|w> Yeah, the 8th.  I will make a note of that in the tickets we didn't get to today.
18:32:34 <tibbs|w> The holidays are just perfectly spread out this year.
18:32:51 * Rathann will fire off an e-mail about jQuery packaging status to TC and Jamie
18:33:22 <tibbs|w> geppetto: Will you update the tickets we dealt with today?
18:33:23 <racor> 8th, 1st and 6th are holidays around here ;)
18:33:35 <tibbs|w> What's on the 8th there?
18:33:58 <geppetto> tibbs: yeh
18:34:23 <geppetto> I do the minutes, and then paste in the bits for each ticket to each ticket
18:34:38 <racor> miscommunication, I wanted to say next meeting on 8th, 1st ... 6th are holiday, many people are on holidays ...
18:34:39 <tibbs|w> Cool.  Just wanted to make sure.
18:34:59 <geppetto> cool. I'll see you on the 8th then.
18:35:19 <tibbs|w> Happy holidays to everyone who celebrates them.
18:35:19 <geppetto> have a good Saturnalia :)
18:35:45 <tibbs|w> For me it's just a time to get more work done/.
18:36:25 <geppetto> All work and no play makes Jason a dull boy?;)
18:36:34 <mbooth> tibbs|w: Have a good work-slightly-less-hard-than-normal-fortnight then :-)
18:37:03 <geppetto> #endmeeting