17:01:38 <geppetto> #startmeeting fpc
17:01:38 <zodbot> Meeting started Thu Jan 22 17:01:38 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:38 <geppetto> #meetingname fpc
17:01:38 <zodbot> The meeting name has been set to 'fpc'
17:01:38 <geppetto> #topic Roll Call
17:01:46 * Rathann here
17:01:53 <geppetto> #chair Rathann
17:01:53 <zodbot> Current chairs: Rathann geppetto
17:01:58 <geppetto> #chair tomspur
17:01:58 <zodbot> Current chairs: Rathann geppetto tomspur
17:02:03 <geppetto> #chair tibbs|w
17:02:03 <zodbot> Current chairs: Rathann geppetto tibbs|w tomspur
17:02:50 <tibbs|w> Folks, I have a roof leak in my office.
17:02:55 <tibbs|w> Repair guys are here.
17:03:33 <geppetto> ok
17:03:36 * mbooth is here
17:03:41 <geppetto> #chair mbooth
17:03:41 <zodbot> Current chairs: Rathann geppetto mbooth tibbs|w tomspur
17:04:02 <orionp> here
17:04:06 <geppetto> #chair orionp
17:04:06 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs|w tomspur
17:06:49 <tibbs|w> Back.
17:06:57 <geppetto> ok, cool
17:07:07 <tibbs|w> They told me to throw a trash bag over my monitors and hope it stops raining soon.
17:07:32 <tibbs|w> The perils of being on the topmost floor of my building, I guess.
17:07:36 <geppetto> #topic #493 	Bundling exception: python-execnet bundles python-apipkg
17:07:37 <tibbs|w> But the view is nice....
17:07:41 <geppetto> https://fedorahosted.org/fpc/ticket/493
17:07:55 <geppetto> tibbs|w: if the water hits the computers … can have a nice day off too ;)
17:08:04 <tibbs|w> And new monitors, too.
17:08:11 <tibbs|w> Even though I just got these on Monday.
17:10:14 <tibbs|w> So, at least they provided pretty much everything we ask for.
17:10:32 <geppetto> yeh
17:10:52 <geppetto> the last upstream comment seems like a good thing to push for too, so that's nice
17:11:10 <tibbs|w> Which one was that?
17:11:29 <tomspur> It should be easy to unbundle, as it is an exact copy IIUC
17:11:46 <tibbs|w> That I agree with, but then there's the question of syncing them.
17:12:06 <orionp> just like every other dependency in Fedora....
17:12:09 <geppetto> tibbs|w: https://bitbucket.org/hpk42/execnet/issue/13
17:12:11 <tibbs|w> The fact that they are packaged separately already implies that there's no real unbundling to do.
17:12:28 <geppetto> The bundled file is "only" 167 lines
17:12:32 <geppetto> https://bitbucket.org/hpk42/execnet/src/cf3d5866c62153afd9e587b175f8f37501599a2b/execnet/apipkg.py?at=default
17:12:47 <orionp> # repoquery --whatrequires python-apipkg
17:12:49 <orionp> python-mwlib-0:0.15.11-4.fc22.x86_64
17:12:55 <geppetto> so … I'm not 100% against allowing it … but I don't see any pressing need to do so, either
17:13:10 <tibbs|w> Is this really worth it?  Temporary exception and check up after a while?
17:14:00 <tomspur> I can help with the unbundling, as it should be just a few lines in the spec file...
17:14:09 <geppetto> yeh, it looks like it should be unbundled … and we shouldn't discourage them from trying to do so upstream, as they are … but I'm probably fine with just shipping it as is for a bit.
17:14:41 <geppetto> tomspur: If you want to, I'm happy to +1 "let tomspur fix it" ;)
17:15:47 <tomspur> ok, I'll try so
17:16:17 <orionp> can someone explain " execnet bootstraps itself across host boundaries -- a feature which would break if a dependency were introduced"
17:16:27 <tibbs|w> In any case, I'll +1 a temporary exception that we can revisit later.  Once I work out a process for us revisiting those later.
17:16:55 <tibbs|w> orionp: Maybe it actually copies python code to a remote machine and executes it there?
17:17:12 <mbooth> In which case, why can't it copy one more file?
17:17:24 <geppetto> orionp: I assume it does something like rsh/ssh
17:17:40 <tomspur> Unbundling like proposed in the ticket would probably break that feature...
17:17:57 <tibbs|w> But if it knows what it needs to copy, it can just copy the file from the other package....
17:18:06 <geppetto> orionp: So he wants to be able to ship the entire module from localhost, to the remote host and have it work.
17:18:50 <geppetto> tomspur: I don't see why … it would just run the _mod version on the remote host.
17:19:18 <mbooth> Fixing that feature to work unbundles doesn't sounds like an intractable problem...
17:19:38 <mbooth> s/unbundles/unbundled/
17:19:39 <tibbs|w> I agree, but I think we'd have to provide them with more proof of concept.
17:20:17 <tomspur> geppetto: ipython does bundling in _foo.py files. The foo.py file tries to import _foo first and the system wide version as a fall back. The _foo.py is deleted on buildtime, so we don't have the full library around for copying around at runtime
17:21:25 <tomspur> I'll have a deeper look and propose a patch for next week. We can then revisit if it is acceptable?
17:21:47 <tibbs|w> Sure.  My +1 (for temp exemption) stands either way.
17:22:15 <mbooth> tomspur: I'd vote for that
17:22:34 <geppetto> tomspur: Ahh, I assumed the import try/except was run everytime
17:23:18 <Rathann> I wonder if replacing the bundled copy with a link to the system apipkg.py file would be enough
17:23:24 <geppetto> #action tomspur Will have a deeper look and propose a patch for next week.
17:24:09 <geppetto> #topic #474  Allocating a soft static uid and gid 389 for dirsrv
17:24:10 <tomspur> Rathann: If execnet copies the file accross boundaries and not just the link, that would keep that feature.
17:24:16 <geppetto> https://fedorahosted.org/fpc/ticket/474
17:24:47 <tibbs|w> There's recent traffic on that ticket.
17:25:18 <tibbs|w> I don't really understands what the "image static UIDs" thing actually buys us, though.
17:25:42 <geppetto> It'd just be a seperate list of static UIDs that containers are using
17:26:01 <geppetto> So they don't affect everything else, and only apply to the containers/images that we (Fedora) ship
17:26:59 <geppetto> This gets us the advantages of having soft static UIDs for apps. in containers, and thus. people can move data between our containers easily
17:27:21 <geppetto> But doesn't affect real installs, and can be dropped when a better solution comes along
17:27:32 <tibbs|w> Hmm.
17:27:40 <geppetto> Also doesn't affect anyone else that wants to create a whole mess of different containers
17:27:55 <tibbs|w> I guess I just see that as being just a de-facto distro-wide UID list.
17:28:16 <tibbs|w> Or, hmm, does this _only_ apply to content within the containers?
17:28:32 <tibbs|w> There's no reason for the UID inside the container to match anything that might be installed on the host?
17:29:03 <geppetto> Well I want to make it as unofficial as possible, so that a real solution is proposed upstream … and so everyone who wants to put nethack into a container doesn't start asking for static UIDs from us
17:29:36 <geppetto> tibbs: AIUI a lot of containers bind mount storage from outside the container into it
17:30:49 <geppetto> tibbs: So they don't need the UID to match what's on the host … they need the UID to match what'll be allocated to the next image for that app (Eg. yum upgrade == new image)
17:31:05 <geppetto> matching the host is somewhat of a bonus though, I guess
17:32:05 <tibbs|w> This is a mess.  This basically implies that every single allocated UID from every package needs to be static somehow.
17:32:20 <tibbs|w> But, sure, let someone make a list that we don't particularly care about.
17:32:32 <tibbs|w> As long as it doesn't leak into the packaging, I'm fine.
17:32:59 <tibbs|w> Oops.
17:33:13 <geppetto> yeh, that was basically my thought :)
17:34:33 <orionp> This seems then that this just isn't FPC terrritory - atomic/whoever needs to own it and develop tooling?
17:35:02 <geppetto> Yeh, so we should bow out of the image UIDs thing … seems fine to me
17:35:14 <tibbs|w> +1 to that.
17:36:51 <geppetto> #action Managing the temporary image/container UIDs list is mostly out of scope for FPC, as it's going to be specific for atomic/cloud/whatever … and we don't want to give the impression this is the same as soft static UIDs.
17:37:27 <geppetto> Somewhat related
17:37:30 <geppetto> #topic #481 	static uids systemd-network, systemd-timesync, systemd-resolve
17:37:35 <geppetto> https://fedorahosted.org/fpc/ticket/481
17:37:53 <geppetto> I guess atm. this is mostly, does everyone agree here too?
17:38:11 <geppetto> OP wants to come back to it in a few weeks
17:38:44 <tibbs|w> If they don't want us to do anything, let's not do anything.
17:38:51 <orionp> +1 :)
17:39:00 <geppetto> #topic #478 	Proposal: Package Guidelines: DevAssistant Assistant packages (DAP)
17:39:01 <geppetto> https://fedorahosted.org/fpc/ticket/478
17:39:04 <orionp> but it seems different - initramfs...
17:39:05 <geppetto> tibbs|w: :)
17:39:27 <geppetto> orionp: they spoke to you about this?
17:40:14 <orionp> no - I suppose I should ping them
17:40:30 <orionp> although they changed the name
17:40:44 <orionp> ad dap- prefix: Solved by renaming packages to devassistant-dap-%{shortname}.
17:40:54 <orionp> which was my concern
17:41:57 * mbooth sneaks back in
17:42:14 <geppetto> #chair mbooth
17:42:14 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs|w tomspur
17:42:36 <mbooth> Sorry I had to move to another building
17:42:37 <geppetto> Yeh, although they didn't speak to orionp they did a bunch of stuff
17:42:51 <geppetto> Anything else they need to do, or are we happy with it as is now?
17:43:36 <orionp> Works for me
17:44:15 <tibbs|w> The example spec is beautiful, by the way.
17:45:00 <tibbs|w> +1 very many times.  Even though I still have no idea what devassistant actually is.
17:45:41 <Rathann> tibbs|w: the changelog is not exactly in the prescribed format ;)
17:45:43 <tibbs|w> (And yeah, I'm at the homepage now).
17:45:52 <tibbs|w> Damn it.
17:46:06 <Rathann> also Summary is not very descriptive
17:46:31 <Rathann> and neither is the description
17:46:40 <Rathann> what's a "Reveal.js presentation"?
17:46:56 <Rathann> but yeah, technically it's very clean
17:47:38 <tomspur> Aah, the page was updated an hour ago. I was confused, because it looked totally different this morning
17:48:13 <tibbs|w> Seems as descriptive as you can fit in a summary.  I guess since I don't know what this is supposed to do I assume it means something to those who do.
17:48:33 <tomspur> That change was by tibbs|w just now, somehow I looked at a different page this morning....
17:48:49 <Rathann> tibbs|w: oh sorry I was looking at the package linked in the ticket
17:48:53 <Rathann> not the sample spec
17:49:16 <Rathann> the sample spec is just great
17:49:24 <geppetto> :)
17:50:27 <tibbs|w> So I fixed the changelog entry.  Anything else?
17:50:31 <mbooth> My only niggle from last we looked at it is fixed I am happy too
17:51:38 <tibbs|w> If I were writing this I probably wouldn't so many short sections, and instead just make one list, but it's certainly fine as it is.
17:53:21 <tibbs|w> Anyone else up for voting?
17:53:36 <geppetto> Yeh, I'm happy to +1
17:53:50 <orionp> +1
17:53:56 <Rathann> +1
17:53:58 <mbooth> +1
17:54:16 <tomspur> +1
17:54:29 <tibbs|w> +1
17:56:47 <tibbs|w> That's everyone here, I think.
17:58:03 <geppetto> #action  Package Guidelines: DevAssistant Assistant packages (DAP) (+1:6, 0:0, -1:0)
17:58:28 <geppetto> #topic #475  Suggested Changes for Python Guidelines for F22
17:58:34 <geppetto> https://fedorahosted.org/fpc/ticket/475
18:01:07 <geppetto> the diff looks fine to me
18:01:50 <Rathann> compat package binary naming looks quite bad
18:02:04 <Rathann> though I guess not much can be done about it
18:02:25 <Rathann> /usr/bin/coverage-v1.2-3.4
18:02:33 <Rathann> ... is just ... ugly
18:02:50 <geppetto> yeh, and it makes me think it's a release number
18:02:59 <geppetto> but I'm not sure what to do about either problem
18:03:48 <tomspur> Maybe add a similar paragraph for the case, where only one package owns one slot?
18:04:05 <tomspur> /usr/bin/coverage-v1.2 looks quite reasonable
18:05:10 <Rathann> that'll be there
18:05:19 <geppetto> yeh
18:05:45 <Rathann> but you must provide a link called /usr/bin/coverage-v1.2-2.x as well
18:05:51 <geppetto> they'll ship coverage-v1.2 and coverage-v1.2-3 and covrage-v1.2-3.4
18:06:12 <Rathann> it says the unversioned executable must be the python2 version
18:06:17 <geppetto> and while the second don't look terrible next to the first … they kind of do on their own
18:06:48 <tomspur> Rathann: only if you ship for python2 and python3. If you only ship for python3 you can leave it out, isn't it?
18:06:59 <Rathann> ah, correct
18:07:16 <geppetto> and that doesn't change in F22 when py3 is the default?
18:07:18 <tomspur> see comment #6 in the ticket
18:07:56 <geppetto> yeh, soon everything will be py3 as default, AIUI
18:08:07 <tomspur> I don't see what could change then
18:09:30 <tomspur> What if you ship a python2 and python3 executable and want to remove one?
18:11:29 <geppetto> I'm not sure what you mean?
18:11:35 <tomspur> Is it fine to remove the coverage-3 and coverage-3.4 again, as all python2 ones are gone?
18:11:52 <geppetto> no
18:12:00 <geppetto> at least I don't see how it can be
18:12:30 <geppetto> but it's fine to remove all of coverage-2 and coverage-2.7, if you stop shipping a py2 version
18:13:06 <tibbs|w> I dream of a world where python packaging is actually simple.
18:13:20 <tomspur> If you only ship executables for python3, you don't need to to the -3 and -3.4 appendings in the first place. But once you have shipped a python2 and python3 executable, you'd have the appended symlinks forever, I guess
18:14:15 <geppetto> tomspur: is that true?
18:14:38 <geppetto> """+
18:14:39 <geppetto> ** both python 2 and python 3 variants must provide symlinks with a '-X' and '-X.Y' suffix (Python runtime Major version, resp. Python runtime Major.Minor version), unless upstream already provides appropriately versioned executables without the dash"""
18:14:45 <tomspur> geppetto: The first part: yes. I asked about the second part...
18:15:05 <geppetto> That says, to me, that all python apps. have to have versioned execs
18:15:25 <tomspur> That's only true " if executables are to be shipped for both python 2 and python 3 "
18:15:49 <Rathann> I have to go AFK
18:15:50 <geppetto> Hmm, ok
18:16:02 <Rathann> construction crew arrived
18:16:16 <tomspur> Otherwise: "f only one executable is to be shipped, then it owns its own slot" -> /usr/bin/coverage just uses python3 and that's it
18:16:16 <geppetto> Rathann: You want to vote before?
18:16:23 * geppetto nods
18:20:57 <geppetto> So does anyone want to do any changes, or request any info. or changes?
18:21:25 <mbooth> tomspur: Hmm, I see what you're saying, why not only symlinks for python2 version?
18:22:01 <mbooth> Why does there need to be three two python3 symlinks as well?
18:22:21 <geppetto> I assume for F21
18:22:21 <tomspur> mbooth: This one is more consistent (and it is much work to provide both binary files anyway, so there is not much overhead)
18:22:27 <geppetto> so you can run the py3 version
18:22:53 <geppetto> consistently, that is
18:23:16 <tomspur> I'm +1 as it is. I just wanted to make sure, that you can remove all -* if you only provide one binary (with the current default python version - whatever that is)
18:24:00 <tibbs|w> I can +1 this, but python is getting so bad.
18:24:07 <mbooth> geppetto: Hmm, it wasn't clear to me that the python3 symlinks were for f21
18:24:55 <geppetto> well, py2 is the default for f21
18:25:14 <geppetto> so if you want the same code to run the py3 version on both f21 and f22, you need to call the -3 variant
18:25:25 <mbooth> Sure, I have rawhide blindness :-)
18:26:04 <mbooth> I guess I can vote on this
18:28:08 <tibbs|w> Am I lagging or is it just really quiet in here?
18:28:33 * tomspur is waiting for other +1s :)
18:28:52 <tibbs|w> Are we at 2 right now?
18:29:06 <mbooth> +1 then, for the record :-)
18:29:47 <geppetto> +1
18:30:02 <geppetto> I think we are at 4-5
18:30:06 <geppetto> so can still pass it
18:30:23 <tibbs|w> Hmm?
18:30:27 <geppetto> that's 4
18:30:36 <geppetto> orionp: vote?
18:30:41 <orionp> +1
18:30:46 <geppetto> There we go :)
18:31:21 <geppetto> #action Suggested Changes for Python Guidelines for F22, versioned binaries (+1:5, 0:0, -1:0)
18:32:23 <geppetto> #topic #338 	%doc and %_pkgdocdir duplicate files and cause conflicts
18:32:28 <geppetto> https://fedorahosted.org/fpc/ticket/338
18:33:24 <geppetto> tibbs: Can you remember why you moved this to meeting?
18:33:34 <tibbs|w> Hmmm.
18:33:47 <tibbs|w> I'm not sure we ever talked about it.
18:33:55 <tibbs|w> It was just sitting there as "new".
18:34:09 <geppetto> toshio said we did
18:34:18 <geppetto> and voted +1:4, -1:1
18:34:30 <geppetto> but then nobody else voted
18:34:32 <tibbs|w> Hmm, then I guess it's dead?
18:34:49 <geppetto> 5 was pretty close to all members 17 months ago :)
18:34:54 <tibbs|w> I can close it.  I just didn't want to leave it sitting there.
18:35:25 <tibbs|w> I guess if someone wants to champion it they can restart the process.  I haven't really looked into the issue.
18:35:40 <tibbs|w> Unfortunately I found a lot of stuff like that while cleaning up.
18:35:55 <tibbs|w> Someone said they would write a draft or something, but nothing happened after that.
18:37:11 <tibbs|w> The simple proposal in comment 10 was what we voted on.
18:37:27 <tibbs|w> We could always reconsider; I think this is still an issue.
18:37:45 <tibbs|w> But I wouldn't want to do that today.
18:38:12 <geppetto> FWIW, that's: "Packages must not use both relative %doc in the %files section and manual installation of documentation files into %{_docdir} in a single spec file"
18:38:24 <geppetto> And I'm happy to +1 that again, today
18:38:40 <tibbs|w> Didn't pass because people wanted .... something.
18:38:50 * geppetto shrugs
18:38:56 <tibbs|w> Additional restrictions on places where %doc is not allowed.
18:39:15 <tibbs|w> Honestly I'll +1 it as well.  If we need to restrict it more, we can do that later.
18:39:32 <orionp> when a package's installer installs into %docdir
18:40:56 <tibbs|w> orionp: Was there more to that statement?
18:41:03 <tibbs|w> If not, I failed to understand.
18:41:11 <orionp> that's the other situation to worry about
18:41:22 <tibbs|w> Ah, well, it would still be a concern.
18:41:25 <orionp> which may or may not be noticed
18:41:47 <tibbs|w> But getting rid of some of the problem is better than getting rid of none of it.
18:42:06 <orionp> yes
18:42:35 <tibbs|w> So should I just re-state the proposal at the bottom of the ticket and put it up for vote collection?
18:42:41 <tibbs|w> We're at +2 right now.
18:43:56 <tomspur> tibbs|w: yeah, could you re-state it please?
18:44:07 <tibbs|w> No problem.  Move on?
18:47:07 <geppetto> #topic #304 	asking for bundling exception for the package "rubygem-rdiscount"
18:47:11 <geppetto> https://fedorahosted.org/fpc/ticket/304
18:47:30 <tibbs|w> Someone said it was still relevant.
18:47:47 <tibbs|w> But it's an ancient ticket.
18:48:23 <tibbs|w> I don't see why the package doesn't just link against an existing package.
18:48:25 <geppetto> I guess this is a fork
18:48:41 <geppetto> tibbs:  Some source files have been modified. Some functions have more parameters. I do not know why.
18:48:47 * geppetto shrugs
18:48:49 <tibbs|w> Hmmm.
18:49:00 <geppetto> it does say ruby on the box ;)
18:50:16 <tibbs|w> This might be in the "don't care" pile, except that this probably parses untrusted data.
18:50:42 <orionp> yeah
18:52:14 <Corey84> +1
18:52:36 <orionp> why the heck does yum info no list the srpm name?
18:52:42 <orionp> sorry, bitching
18:52:46 <geppetto> add -v
18:53:11 <geppetto> Hmm, that doesn't either
18:53:43 <geppetto> repoquery --source pkg
18:53:58 <orionp> thanks
18:54:28 <geppetto> I guess I don't care
18:55:36 <tibbs|w> Not sure what Corey84 was +1'ing.  Mr. "realname", did you have information to add?
18:55:46 <tibbs|w> geppetto: Don't care in what sense?
18:56:07 <Corey84> wrong room nirik   sorry
18:56:19 <geppetto> I may change my mind … I don't mind too much random forked ruby code bundling
18:57:02 <geppetto> but I know suspect that it's bundling a huge C library
18:57:29 <orionp> Looks like the source is identical to me
18:57:41 <geppetto> of libmarkdown?
18:58:38 <orionp> of the whole discount package essentially
18:58:45 <orionp> which provides libmarkdown
18:58:52 <tibbs|w> Uhh..
18:59:01 <orionp> plus stuff
18:59:11 <tibbs|w> If that's the case this is a pretty simple "no".
18:59:40 <tibbs|w> Maybe add your analysis to the ticket? It's possible that things have changed in the eternity since the ticket was opened.
18:59:52 <orionp> http://ur1.ca/ji1jq
19:00:07 <orionp> is a diff
19:00:26 <orionp> so some added/removed files, but the common files are the same
19:00:30 <tibbs|w> Well, yeah, that does look like not much changed.
19:01:09 <geppetto> tibbs|w: what's 19 months between friends
19:01:26 <tibbs|w> If you're in a hole, you have to dig yourself out somehow.
19:01:33 <geppetto> indeed
19:01:49 <geppetto> So, anyway … -1
19:01:52 <tibbs|w> I did get pretty much everything cleaned up.
19:02:16 <tibbs|w> Yeah, -1 unless orionp's analysis turned out to be wrong.
19:02:26 <tibbs|w> But I suspect we might have to do the work here, and... ruby.
19:02:43 <geppetto> yeh, we'll have a pretty good backlog/schedule by next week … by easter it should look great.
19:03:08 <tibbs|w> In a month when the needinfo tickets start dying, the full list will be pretty short.
19:03:23 <tibbs|w> And I have several more tickets to announce and close out.
19:03:33 <tibbs|w> Maybe we'll be able to have one hour meetings again.
19:04:02 <geppetto> yeh
19:04:22 <tibbs|w> Is that pretty much it for today?
19:04:55 <orionp> I need to get some work done....
19:04:56 <tibbs|w> 495 came in a bit late.
19:05:58 <tibbs|w> A couple of the writeup tickets didn't really come with a draft, so I'm having to just cook something up myself.  I suppose if I screw that up someone will yell.
19:06:40 <tibbs|w> We still have a crap load of tickets in the "meeting" state but it's way too much to get to in one day.
19:07:48 <tibbs|w> Would be super nice if people could look them over, and at least make comments.
19:08:10 <tibbs|w> That's report 13 in the trac.
19:08:10 * geppetto nods
19:08:27 <tomspur> ok
19:08:28 <geppetto> I try to look at 12 and 13 on wed.
19:08:48 <geppetto> as I do the schedule
19:08:56 * orionp is afraid he barely has enough time for the meetings
19:09:04 <geppetto> so I know roughly what we'll be talking about, and can make some comments with time for them to respond etc.
19:09:07 <tibbs|w> I'll keep plowing through.  Still have two drafts to write.
19:09:21 <tibbs|w> Yeah, I do that too.  If we all did, it might go a bit faster.
19:09:24 <geppetto> orionp: Yeh, as tibbs|w said … hopefully we can get back to having 1 hour meetings soon
19:09:29 <tibbs|w> But everybody is busy.
19:09:32 * geppetto nods
19:09:43 <geppetto> #topic Open Floor
19:10:19 <tibbs|w> We're down to 64 total tickets, most of them in needinfo.
19:10:48 <tibbs|w> I'll ping those as needed and close them out in a month.
19:12:02 <tibbs|w> Really we're close to being completely cleaned up, and I have some time today and this weekend to try and get a bit more done.
19:12:08 <tomspur> Is it possible to subscribe to wiki edits in the packaging section?
19:12:38 <tibbs|w> I think so.
19:12:47 <tibbs|w> I usually make sure that box is checked when I make a change.
19:12:54 <tibbs|w> But I've been the only one making changes lately.
19:13:18 <tibbs|w> I do have a plan for reorganizing the main guidelines page which I will present eventually.
19:13:44 <tibbs|w> I don't think you can subscribe to an entire hierarchy of pages, though.
19:15:06 <tomspur> It seems to need to put each page separately on the watchlist
19:15:16 <geppetto> yeh
19:15:43 <tibbs|w> You can edit the raw watchlist.  So if someone's watching everything, just paste in their list.
19:16:52 <tibbs|w> Anyway, I guess I'm done.
19:17:12 <tibbs|w> Expecting a horde of graduate students wanting faster-er computers.
19:18:09 <tomspur> :)
19:22:28 <orionp> thanks all!
19:22:44 <geppetto> #endmeeting