16:00:56 <spot> #startmeeting Fedora Packaging Committee
16:00:56 <zodbot> Meeting started Wed Aug 18 16:00:56 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:13 <spot> #topic Roll call
16:01:59 <spot> racor, rdieter, abadger1999, SmootherFrOgZ, Rathann|work, tibbs|h : ping
16:02:04 * Rathann|work present
16:02:17 <abadger1999> spot: Here
16:04:05 <spot> well, we can wait a few minutes
16:04:31 <racor> here
16:06:37 <tibbs|h> Yep.
16:06:52 <spot> okay, thats 5.
16:06:52 <tibbs|h> No speakers on this computer, unfortunately.
16:07:11 <spot> #action Quorum achieved (5)
16:07:23 <spot> Okay, I'm going to work through the trac items first
16:07:41 <spot> #topic https://fedorahosted.org/fpc/ticket/5 - /usr/share/gtk-doc directory ownership issue
16:08:07 <spot> i actually did a draft on this one based on some discussion with the rpm folks and the desktop folks
16:08:13 <spot> https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership
16:09:48 <tibbs|h> Trying to figure out what changed.
16:10:07 <spot> in practical terms on the gtk-doc directory issue, it means that packages can own /usr/share/gtk-doc/ without needing to Requires: gtk-doc
16:10:09 <tibbs|h> I see a couple of bullet points at the top
16:10:26 <rdieter> here
16:11:09 <spot> tibbs|h: i rewrote the "directory ownership" rules to try to simplify and clarify them
16:11:27 <spot> tibbs|h: some of the examples were slightly altered/reworded as a result
16:11:38 <tibbs|h> The second example is completely different.
16:12:32 <Rathann|work> the draft looks fine to me, except that I don't like the idea of requiring apps dropping files in /usr/share/gtk-doc/ to own that directory as well
16:13:17 <rdieter> Rathann|work: or they can Requires: gtk-doc
16:13:33 <tibbs|h> Or it could just be stuck in filesystem.
16:13:36 <Rathann|work> yes they can, but in reality they don't require gtk-doc to function
16:13:36 <rdieter> Rathann|work: or did you have something else in mind?
16:13:47 <spot> Rathann|work: the concern is that the rpm folks wanted to ensure that there was never a situation where packages in a dep chain had files in an unowned directory
16:13:51 <abadger1999> The last two examples are really the same.
16:14:04 <Rathann|work> yeah I understand, so even if I don't like it, I'm not opposed
16:14:09 <rdieter> fwiw, I like the draft,
16:14:19 <spot> abadger1999: yes, but the perl example came up enough that it has been worth keeping
16:14:20 <Rathann|work> abadger1999: I was just about to say the same thing
16:14:30 <racor> gtk-doc is a devel package, so forcing packages to own it would be wrong.
16:14:44 <spot> racor: this doesn't force packages to own it, it actually does the opposite
16:14:52 <abadger1999> spot: Oh I'm sorry the second to last and third to last.
16:15:11 <Rathann|work> yes, the bash-completion and gtk-doc examples look similar
16:15:19 <spot> ah.
16:15:23 <spot> that is a good point.
16:15:30 <racor> spot: Yeah, badly put on my part. Requires:gtk-docs would be wrong
16:15:31 <spot> i could probably simply drop the bash-completion item
16:15:42 <spot> racor: agreed
16:16:04 <spot> or, i could merge it into the above section
16:16:11 <spot> two examples in that space may not be a bad thing
16:16:43 * spot is going to merge it, one sec
16:18:26 <spot> okay, reload
16:18:39 <spot> those items have been merged, and the "filesystem" exception is now highlighted there
16:19:51 <spot> If anyone has additional comments, please speak up, otherwise, lets vote.
16:20:40 <abadger1999> Add an {{admon/note|Keeping devel packages out of the dep chain|In the specific case of gtk-doc, we would an end-user application (evolution) requiring a devel package (gtk-doc).  To keep the minimal install size low, we don't want such deps to occur so it is preferable to multiply own the directory}}
16:20:52 <abadger1999> Good change?
16:21:01 <spot> theres a grammar burp in there
16:21:31 <spot> "we would an end-user"
16:21:47 <rdieter> ... would not want ... ?
16:21:47 <abadger1999> we would have an end user
16:22:03 <abadger1999> would not want is better
16:22:15 <abadger1999> we don't want an end-user
16:22:18 <spot> abadger1999: well, its not necessarily wrong, but the point is that gtk-doc isn't in evolutions "natural dependency chain"
16:22:52 <Rathann|work> natural dep chain is mentioned at the beginning
16:23:39 <spot> "In the specific case of gtk-doc, we would not want an end-user application (evolution) artificially requiring a devel package (gtk-doc). To keep the minimal install size low, we don't want such deps to occur so it is preferable to multiply own the directory."
16:24:07 <abadger1999> Ah -- I was responding to racor's comment.
16:24:17 <Rathann|work> the rationale is fine, but isn't that a little redundant?
16:24:19 <abadger1999> [09:14:30] <racor> gtk-doc is a devel package, so forcing packages to own it would be wrong.
16:24:25 <abadger1999> [09:15:30] <racor> spot: Yeah, badly put on my part. Requires:gtk-docs would be wrong
16:24:27 <spot> Rathann|work: yes, it is redundant.
16:24:39 <spot> but i don't mind adding it to make things clear.
16:24:45 <Rathann|work> sure
16:24:49 <abadger1999> If we're not going to judge it as strictly wrong, no need for the change.
16:25:19 <spot> okay, then lets leave the change out.
16:25:25 <spot> any other comments before we vote?
16:25:37 <Rathann|work> abadger1999: we do think it's wrong, but the "why" is already covered by the "natural dependency chain" requirement
16:25:49 <tibbs|h> I do wish it was shorter, but I don't see how to make it do without removing examples.
16:26:12 <spot> tibbs|h: if you can think of a revision to condense it, we can revisit it in the future
16:27:04 <abadger1999> +1 to the draft
16:27:08 <tibbs|h> Got another complaint that the guidelines are too long this morning.  Not much to be done, honestly.
16:27:11 <spot> +1 from me
16:27:14 <tibbs|h> +1
16:27:25 <Rathann|work> +1 from me as well
16:27:30 <abadger1999> Yeah -- for the guidelines too long, I think the only solution is to better organize them.
16:27:43 <spot> abadger1999: i think you're right.
16:28:00 <kalev> the highlighted "Note on directories" at the top seems to mostly duplicate highlighted "An exception" down below
16:28:16 <racor> +1
16:28:30 <spot> kalev: this is intentional, someone wanted to make sure it was clear in both places.
16:28:44 <tibbs|h> Relating to this draft, I do think that at some point this committee or someone might consider finding directories which are significantly multiply-owned and move them into one of the filesystem packages.
16:28:49 * spot would have to dig in his logs to look up who
16:29:04 <abadger1999> spot: It's also i nthe bullet points at the top.
16:29:14 <abadger1999> #  any directories owned by the filesystem, man, or other explicitly created -filesystem packages
16:29:18 <spot> tibbs|h: i have enough landmines to step on at the moment. :)
16:29:27 <spot> abadger1999: do you think i should drop the note from the top?
16:29:34 <abadger1999> I suppose that  the {{admon}} at the top could be dropped.
16:29:40 <abadger1999> yeah.
16:29:47 <spot> okay, im fine with that
16:29:56 <spot> if it would change your vote to drop that note at the top, speak up. :)
16:30:14 <tibbs|h> Hey, one less warning block is a good thing.
16:30:24 <Rathann|work> agreed
16:30:30 <abadger1999> +1 :-)
16:30:33 <spot> okay. its dropped, and with +5, it passes.
16:30:44 <spot> rdieter: if you would like to vote for the record, go ahead. :)
16:30:54 <rdieter> ok, +1 (sorry, fetched coffee)
16:31:38 <spot> #action spot's draft approved (with minor revisions made in flight)
16:31:58 <spot> #topic https://fedorahosted.org/fpc/ticket/6 Recoll bundling exception
16:32:08 <abadger1999> spot: Hold one
16:32:27 <spot> abadger1999: mmkay. whats up?
16:32:47 <abadger1999> spot: We also need to decide whether we make people change this, let provenpackagers change it, let maintainers have totally free reign.
16:32:52 <abadger1999> For the specific gtk-doc case.
16:33:13 <spot> abadger1999: i know it is trendy to say this, but i think that's fesco's call
16:33:28 <abadger1999> Because someone did this: https://bugzilla.redhat.com/show_bug.cgi?id=604169
16:33:37 <abadger1999> spot: Well -- nirik opened the fpc ticket.
16:33:52 <spot> and we've clarified the guidelines as to how it should be handled
16:34:24 <abadger1999> So I think they want some input from us.  I'd say, old usage is gransdfathered but provenpackagers are welcome to update the packages.
16:34:30 <nirik> I would expect we would want maintainers to fix it... if someone here can update the ticket to point to the new guideline?
16:34:43 <spot> nirik: i threw the new guideline in the fpc ticket
16:35:12 <spot> i would be inclined to say that maintainers should fix it, but i'm not going to lose any sleep if they don't.
16:35:25 <spot> so, abadger1999's suggestion works for me.
16:35:35 * nirik nods.
16:35:51 <abadger1999> Cool.  Okay, we can go on to recoll.
16:35:54 <spot> i would also note that this is something that provenpackagers should be fixing in rawhide/master, not in pushed updates.
16:36:10 <spot> (since that inevitably gets asked)
16:36:27 <spot> okay, on to recoll.
16:36:38 <spot> abadger1999: i'm not entirely sure why this is on the FPC trac, can you explain?
16:36:39 <abadger1999> Note that recoll is touching the same area as this ticket: https://fedorahosted.org/fpc/ticket/8
16:37:08 <abadger1999> spot: We need to add the exception to hte guidelines -- I would really realy like to add why an exception was granted at the same time.
16:37:28 <spot> abadger1999: aha, okay
16:37:29 <abadger1999> spot: If you look at the changes I made to do ticket #8, you'll see what I'd like to do for recoll.
16:38:07 <abadger1999> Basically in the Exception section, add potential reasons people could be granted an exception.
16:38:10 <spot> gotcha.
16:38:28 <abadger1999> And then list the reasons that each specific case was granted one.
16:38:53 <spot> okay, so lemme try to figure out why i supported the exception for recoll
16:40:20 <spot> ... and i dont have notes on it.
16:40:34 <spot> nirik: is there a fesco ticket that might refresh my memory?
16:40:50 <tibbs|h> I generally support the addition of the 'Exceptions' section to the bundled library guidelines, but damn, it's a whole additional screenfull added to the guidelines.
16:41:16 <abadger1999> https://fedorahosted.org/fesco/ticket/431
16:41:17 <spot> tibbs|h: we could split it off into its own page.
16:41:27 <tibbs|h> Sure, some of it could go out of line.
16:41:41 <tibbs|h> I just don't know if that makes things better or worse for the packagers.
16:41:45 <nirik> spot: I think there was, can try and dig it up
16:41:54 <tibbs|h> At least in a single long document you can search.
16:42:00 <spot> okay, i have it.
16:42:29 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=612719
16:42:34 <abadger1999> Note: the whole No bundled libraries section is on a separate page already.
16:42:41 <tibbs|h> Oh, true
16:42:47 <tibbs|h> Then never mind, I guess.
16:43:08 <abadger1999> I understand the single long document can be searched idea too though -- that's how I find things in the FHS.
16:43:18 <spot> my reasoning here was that in cases where A) the upstream is defunct/dead _AND_ B) there are application specific changes to the bundled code
16:44:11 <abadger1999> spot: If upstream is defunct, why not push for the present package revitalizing that code base/project?
16:44:23 <spot> of course, this conflicts with the text in copylibs
16:44:28 <abadger1999> <nod>
16:45:08 <tibbs|h> I seem to be lagging quite a bit; please excuse me if I don't respond quickly.
16:45:12 <spot> well, okay, and C) the project using the forked bundled libs is not willing or able to revitalize the dead upstream
16:45:19 <spot> which is a crappy copout, really.
16:45:53 <tibbs|h> Well, they have chosen to continue maintenance of the code.
16:46:06 <tibbs|h> The only real difference is whether it's in a separate tarball or not.
16:46:26 <spot> tibbs|h: is it useful to others inside of that package?
16:46:39 <tibbs|h> I've no idea.
16:46:43 <abadger1999> tibbs|h: Okay... but if that's really the case, then we probably should have a unac subpackage with a library in it that other packages consume.
16:46:45 <spot> will anyone think "i bet there is a newer unac library in the recoll package i could use"
16:46:53 <tibbs|h> I mean, all code is potentially useful to others.
16:47:44 <spot> So, I think the binc bundled code in recoll falls under the "copylibs" exception in the draft text
16:47:58 * spot is looking at http://lists.fedoraproject.org/pipermail/devel/2010-July/139015.html
16:48:53 <spot> hmm.
16:49:18 <Rathann|work> it would appear so
16:49:20 <abadger1999> yeah -- so binc looks like -- there was an application, binc.  recoll copied code out of binc.
16:49:44 <abadger1999> I can see that falling under "copylib"... maybe I should clarify the wording to include snippets of code from other applications.
16:50:21 <spot> what about something like "bundled code has been forked and customized in a way such that it is only useful for the application using it" and "upstream is defunct/dead" and "authors of code fork are unable or unwilling to restart upstream"
16:50:37 <spot> i know thats a thick chain of conditionals
16:50:39 * abadger1999 wonders if that would help with a python bundling issue he's seen as well..... there it's strange because anything in site-packages is importable whether or not it's what upstream intends.
16:51:02 <abadger1999> I do not like  "authors of code fork are unable or unwilling to restart upstream"
16:51:11 <spot> i don't like it either
16:51:26 <spot> but if it is the practical reality, will we not permit it in Fedora?
16:51:38 <abadger1999> I could see the  forked and customized clause but not sure how we'd apply that well...
16:51:45 <abadger1999> I mean here's a counter example to recoll:
16:51:46 <spot> note that the rule is all three being true
16:51:50 <abadger1999> rsync bundling zlib
16:51:51 <spot> not "one of them being true"
16:51:56 <abadger1999> True...
16:52:01 <abadger1999> So that wouldn't apply to rsync.
16:52:04 <spot> yes.
16:52:52 <abadger1999> alright ... so forked and customized seems the most reasonable of these but.... how do we evaluate that?
16:53:21 <tibbs|h> Case by case.
16:53:27 <spot> i think tibbs|h is right.
16:53:38 <tibbs|h> Honestly I don't think we want this stuff to get in easily.
16:53:41 <abadger1999> I mean -- rsync felt like what it did with zlib was something that only it wanted to do but we now have another package that bundles zlib b/c it needs to be compatible with rsync.
16:53:53 <spot> looking at the diff between upstream and the bundled source might also make the changes more apparent
16:53:57 <tibbs|h> And we should certainly consider the exposure it brings to us and our users.
16:54:08 <spot> e.g. for libjingle in chromium, it is 20000 LOC.
16:54:24 <tibbs|h> But honestly we have to understand that we don't have the ability to control what upstreams do.
16:56:11 <abadger1999> true.  But we do have the option of not allowing the software in the distro because it would make the baby sys admin cry :-)
16:56:32 <spot> abadger1999: on the recoll case, i believe my grounds were A) (unac) "bundled code has been forked and customized in a way such that it is only useful for the application using it" and "upstream is defunct/dead" and "authors of code fork are unable or unwilling to restart upstream" and B) (binc) copylibs
16:56:36 <tibbs|h> And again we have to consider how this serves our purpose as a distro.
16:56:59 <Rathann|work> as long as nothing else in the distro uses unac, I think it's acceptable
16:57:22 <spot> Rathann|work: which i think is true.
16:57:33 * spot wouldn't mind adding that as another restriction
16:58:13 <spot> "bundled code has been forked and customized in a way such that it is only useful for the application using it" and "upstream is defunct/dead" and  "authors of code fork are unable or unwilling to restart upstream" and "bundled_code (pre-fork) is not otherwise used in Fedora"
16:58:26 <abadger1999> Okay, here's a question, shold we setup some way of tracking bundled libs?
16:58:35 <spot> abadger1999: yeah, we probably should.
16:58:43 <spot> abadger1999: maybe in the pkgdb?
16:59:11 <abadger1999> spot: Could be.  Or a wiki page.
16:59:13 * spot doesn't want to try to overload rpm provides for this
16:59:14 <tibbs|h> The farther you put it from the packager, the less chance it will actually be updated.
16:59:22 <spot> tibbs|h: a valid point
16:59:24 <abadger1999> I suppose we'll want to query it which means pkgdb is better.
16:59:35 <abadger1999> But yeah; tibbs|h's point...
16:59:45 <spot> but at the very least, exceptions could be processed in pkgdb at the same time they're approved
16:59:59 <abadger1999> We can query rpm tags and it's right there in the spec file so the packager has ready access...
17:00:22 * Rathann|work is also in favour of the rpm provides
17:00:27 <spot> abadger1999: we'd need to standardize it somehow
17:00:46 * spot notes that we are now at the 1 hour mark
17:01:07 <spot> abadger1999: do you have enough from me to amend the draft for recoll?
17:01:08 <Rathann|work> i.e. Provides: bundled_upstream_name = the_version_it_was_based_of
17:01:10 <abadger1999> Like bundled(zlib-1.1.4)
17:01:25 <Rathann|work> ah, right, abadger1999's idea is better
17:01:38 <spot> abadger1999: that seems sane enough
17:01:40 <Rathann|work> but let's modify it
17:01:50 <Rathann|work> Provides: bundled(zlib) = 1.1.4
17:01:58 <abadger1999> spot: Well, I personally don't like adding adding defunct or upstream is lazy as arguments for bundling.
17:02:16 <abadger1999> I do like adding the code has been forked customized to only be useful in this instance.
17:02:24 <spot> okay
17:02:25 <abadger1999> I just worry about evaluating that statement.
17:02:56 <spot> so, what i propose is that you add recoll and the justification that you're comfortable with
17:02:57 <abadger1999> Sound good if I revise the draft to include just that one additional condition for next time?
17:03:02 <abadger1999> <nod>
17:03:07 <tibbs|h> The bottom line is that any package can be granted an exception to any guideline.
17:03:08 <abadger1999> Sounds like a plan.
17:03:13 <spot> along with the text about how to indicate bundled bits
17:03:25 <spot> and we'll review it next time
17:03:58 <spot> any other comments on bundling before we move on?
17:04:18 <spot> #topic https://fedorahosted.org/fpc/ticket/7 - D Packaging Guidelines
17:04:32 <spot> https://fedoraproject.org/wiki/D%2Bpackaging%2Bguideline%2Bdraft
17:05:00 <tibbs|h> Can someone expand those macros for me?}
17:05:16 <tibbs|h> What's _d_libdir in practise, or is that not relevant to the discussion?
17:06:12 <tibbs|h> I objected to _d_includedir being /usr/include/d, but I think I was overridden by FESCo.
17:06:26 <Rathann|work> also I don't like this:
17:06:29 <Rathann|work> Because GNU strip can't extract debug symbols from static lib achieves.
17:06:40 <spot> http://pkgs.fedoraproject.org/gitweb/?p=ldc.git;a=blob;f=macros.ldc;h=60132c618d129a78470798b76cd994173807bb0a;hb=HEAD
17:06:51 <Rathann|work> this should at least be accompanied by a link to upstream bug report
17:07:03 <abadger1999> tibbs|h: I think we can say that /usr/include/d is wrong if we think it goes someplace else.
17:07:39 <spot> Rathann|work: the fact that debuginfo doesn't work on static libs is an open bug
17:07:47 <Rathann|work> ok
17:07:50 * spot has it written down somewhere
17:07:57 <tibbs|h> My concern is that at this point the guideline merely codifies existing practice.
17:08:20 <spot> tibbs|h: yeah, but so does most (all) of the lang specific guidelines
17:08:37 <tibbs|h> Only if the cart goes before the horse.
17:08:46 <tibbs|h> Do the guidelines first, then review the packages against them.
17:08:51 <spot> well, the cart is before the horse now.
17:08:56 <tibbs|h> Which is fail.
17:09:03 <Rathann|work> I don't understand the point of the makefile example
17:09:07 <tibbs|h> But that's partially because we haven't been able to meet.
17:09:09 <spot> yep. should we not act as a result?
17:09:23 <tibbs|h> My point is that there's not much we can do.
17:09:35 <spot> except codify existing practices in this case.
17:09:45 <tibbs|h> Might as well spellcheck the document and approve it.
17:09:51 <abadger1999> We can tell people they're wrong and must change....
17:10:01 <spot> abadger1999: we can.
17:10:09 <abadger1999> That's always a danger when you review packages before hte guidelines are reviewed.
17:10:14 <spot> i don't think there are hundreds of D packages in fedora at the moment
17:10:20 <tibbs|h> The template shouldn't have BuildRoot.
17:10:28 <spot> tibbs|h: thats easily cleaned up
17:10:33 <spot> it shouldn't have %clean either
17:10:36 <tibbs|h> Probably shouldn't have %clean, either.
17:10:42 <tibbs|h> But F12 does still need %clean.
17:10:58 <spot> well, it is not harmful to leave it then.
17:11:21 <rdieter> I'm ok with it, curious though why %_d_libdir isn't used in the .spec example though
17:11:30 <spot> rdieter: so am i.
17:11:53 <rdieter> probabaly just an omission/typo
17:12:19 <spot> rdieter: not sure about that
17:12:26 <spot> %files has %{_libdir}/%{name}/<static-libraries.a>
17:12:38 <spot> which is not %{_libdir}/d
17:12:45 <spot> (%_d_libdir)
17:12:50 <abadger1999> I think I agree with tibbs that hte expansions of the filesystem related macros should be listed.
17:13:03 <tibbs|h> They are actually there in the macros section.
17:13:07 <rdieter> they are
17:13:09 <rdieter> :)
17:13:31 <spot> i think the draft needs to be cleaned up a bit, for grammar and style
17:13:32 <tibbs|h> It's just that the English there is really tough to parse.
17:13:40 <rdieter> agreed
17:13:41 <spot> (also, the makefile section seems unnecessary)
17:14:09 <tibbs|h> Yeah, what is the point of the block after Libraries?
17:14:11 <abadger1999> ah.... /me wonders how he'd reformat this to be easier to read
17:14:24 <spot> i could probably take a shot at cleaning this up
17:14:32 <spot> and we could revisit it next time.
17:14:39 * rdieter nominates spot for sainthood
17:14:50 <spot> gotta be easier than working on chromium. ;)
17:14:59 <rdieter> ha
17:15:19 <spot> #action spot will cleanup D draft for next time
17:15:37 <spot> okay, so that is all of the trac tickets i am aware of
17:15:45 <spot> are there other items for discussion today?
17:15:55 <spot> #topic Open Floor
17:15:57 <tibbs|h> BTW, there are categories for pages needing updates with a release is branched, comes out or goes EPL.
17:16:00 <tibbs|h> EOL.
17:16:51 <rdieter> nice
17:16:52 <tibbs|h> Add Category:Update_on_f12_EOL and we can do things like remove %clean from all of the templates.
17:16:56 <abadger1999> spot: supercypher wanted the python naming guidelines revisited/clarified but I think I'm against it and he wrote his draft in a bz ticket.
17:17:17 <abadger1999> tibbs|h: That's good to know.  Thanks!
17:17:33 <tibbs|h> Not that anything's using them at this point.
17:18:02 <rdieter> .bug 623425
17:18:04 <zodbot> rdieter: Bug 623425 Review Request: python-pyside - Python bindings for Qt4 - https://bugzilla.redhat.com/show_bug.cgi?id=623425
17:18:23 <rdieter> ^^ it's in there if anyone is morbidly curious.
17:18:32 <tibbs|h> I've never seen that our python naming stuff is unclear.
17:18:53 <tibbs|h> I dislike the "py" exception, but the rule isn't confusing.
17:19:32 <rdieter> mainly, I think he disliked not using CamelCase and being consistent with other distros.
17:19:59 <rdieter> in this case anyway
17:20:31 <tibbs|h> I do wish we had lower-cased everything back in the beginning, but far too late now.
17:21:06 <spot> well, if someone wants to seriously rework the python naming guidelines, they can open a ticket.
17:21:17 <rdieter> agreed (if conflicts occur only due to case differences, we're in a world of hurt anyway)
17:21:24 <tibbs|h> BTW, did we get votes from the absent member?
17:21:41 <tibbs|h> We already have a rule about conflicts due to case differences.
17:21:43 <spot> tibbs|h: we did, but he abstained on everything, except for a possible +1 on #7
17:21:50 <spot> which never got to a vote.
17:22:54 <spot> Okay, last call for topics. If you have nothing, please indicate that you're ready for the meeting to close.
17:23:20 <spot> Nothing more from me.
17:23:48 <tibbs|h> Nor I.
17:23:55 <Rathann|work> Nothing here.
17:24:49 * abadger1999 had something but forgot it.
17:24:49 <rdieter> nothing
17:24:54 <abadger1999> So next time is fine.
17:25:17 <spot> okay, then i propose that we meet again next week
17:25:39 <spot> same time and day as today (Wednesday, Aug 25, 2010, 1600 UTC)
17:25:39 <abadger1999> Oh I remember
17:25:43 <rdieter> sounds good
17:25:51 <abadger1999> I'll just mention so we remember
17:26:18 <Rathann|work> fine by me
17:26:36 <abadger1999> Does FPC want to dispense with explicit fesco review and just have them note problems when they see them/people complain on the list.
17:26:51 <spot> abadger1999: can you open a trac ticket for that one and we'll discuss it next week?
17:26:54 * abadger1999 can do either tuesday or wednesday just fine.
17:26:58 <abadger1999> Yep will do.
17:27:05 <abadger1999> spot: Do we like trac then?
17:27:23 <abadger1999> I can start documenting it on the how to make an FPC draft page.
17:27:29 <spot> abadger1999: eh, i think it is better than the wiki method of yore.
17:27:40 <abadger1999> Cool.  baby steps :-)
17:28:09 <spot> okay, thanks everyone
17:28:11 <spot> #endmeeting