From Fedora Project Wiki
Fedora Packaging Committee Meeting 2009-01-20
Present
- Denis Leroy (delero)
- Dominik Mierzejewski (Rathann)
- Hans de Goede (hansg)
- Jason Tibbitts (tibbs)
- Ralf Corsepius (racor)
- Rex Dieter (rdieter)
- Tom Callaway (spot)
- Toshio Kuratomi (abadger1999)
Regrets
- Xavier Lamien (SmootherFrOgZ)
Writeups
The following drafts have been accepted by FESCO and are to be written into the guidelines:
- PackagingDrafts/Font_package_splitting_rules_(2008-12-21)
- PackagingDrafts/Font_package_naming_(2009-01-13)
Votes
The following proposals are submitted to FESCo for approval:
- Explicit Requires
- PackagingDrafts/ExplicitRequires
- Note that this contains an additional section about commenting non-obvious items in spec files.
- Updated Haskell Guidelines
- Symlinks
IRC Logs
| *** spot sets the channel topic to "Fedora Packaging Committee Meeting - https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo". | 11:05 | |
| --> racor has joined this channel (n=rc040203@HSI-KBW-078-043-127-065.hsi4.kabel-badenwuerttemberg.de). | 11:05 | |
| spot | i see hans, me, and racor | 11:06 |
|---|---|---|
| * rdieter puts on fpc hat | 11:06 | |
| spot | abadger19991, tibbs, SmootherFrOgZ? | 11:06 |
| tibbs | Yep. | 11:06 |
| tibbs | First day of the semester; very busy here at work. | 11:07 |
| --> Rathann has joined this channel (n=rathann@fedora/rathann). | 11:07 | |
| Rathann | hi guys, sorry for being late | 11:07 |
| Rathann | I just got home | 11:07 |
| spot | no worries | 11:07 |
| * spot apologizes in advance, i have the US presidential inauguration on in the background | 11:08 | |
| spot | first draft for review: https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires | 11:08 |
| Rathann | +1 for ExplicitRequires | 11:09 |
| hansg | What is with the "non-superfluous or versioned explicit" language | 11:09 |
| hansg | If I read it correctly it states any explicit requires should have a comment? | 11:09 |
| spot | hansg: that's what it says | 11:10 |
| tibbs | That seems a bit excessive. | 11:10 |
| tibbs | I mean, rpm simply doesn't generate automatic dependencies for a lot of things. | 11:10 |
| spot | i can make that a should | 11:10 |
| hansg | It says that "non-superfluous or versioned explicit" should have a comment, but since superfluous Requires should be removed that means all Requires should have a comment ? | 11:10 |
| spot | yeah, that doesn't make much sense to be a must | 11:11 |
| spot | i'll make it a should | 11:11 |
| hansg | To be clear I'm not arguing against that per se, but the language seems more complicated then necessary | 11:11 |
| hansg | It could be just "Any explicit requires should have a comment" | 11:11 |
| spot | okay, it is no longer a must. :) | 11:11 |
| tibbs | Even then, I'd hate to see an argument about comments on dependencies for some python or ruby package review. | 11:11 |
| spot | hansg: i like that | 11:12 |
| tibbs | On some level, this is common sense. "Let RPM figure out what it can, fill in any dependencies it doesn't handle automatically." | 11:13 |
| hansg | Although I must agree with tibbs that it seems a bit excessive (hence the should I understand, but will reviewers understand) ? | 11:13 |
| hansg | For example any package which installs an icon under the freedesktop icon hierarchy has a "Requires: hicolor-icon-theme" | 11:14 |
| --> delero has joined this channel (n=denis@nat/sun/x-057c9b84b5d7f2a0). | 11:14 | |
| * spot made some of the language simplification changes | 11:14 | |
| delero | sorry for being late | 11:14 |
| hansg | I think putting a comment next to that in all such spec files will not help readability, but rather hurt it | 11:14 |
| Rathann | tibbs: python/ruby/whatever requires should ideally be discovered automagically, like perl | 11:14 |
| tibbs | Oh, sure, but they aren't. | 11:14 |
| tibbs | We live with the RPM we have, remember. | 11:14 |
| Rathann | indeed | 11:15 |
| hansg | This is not the RPM you are looking for :) | 11:15 |
| Rathann | delero: we're discussing https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires | 11:15 |
| tibbs | Maybe the python stuff us coming, but does it work for ruby or haskell or lua or whatever is coming up next? | 11:15 |
| delero | rathann: thanks | 11:15 |
| rdieter | this discussion tickles a memory... isn't this similar in spirit to the existing directory ownership guidelines? | 11:16 |
| racor | I think, in the last sentence, the "explicit versioned dependency" should be changed into "explicit dependency" | 11:16 |
| spot | racor: yes, i agree. (changes it) | 11:16 |
| tibbs | Are versioned dependencies really special to this guideline? | 11:16 |
| racor | tibbs, spot: IMO, no. | 11:17 |
| tibbs | I mean, there is often the issue of requires: glibc > 2.0 or somesuch. The version here is obviously superfluous. | 11:18 |
| tibbs | But that's not what this guideline is about. | 11:18 |
| spot | well, if it helps reviewers ask the question of whether that Requires: glibc > 2.0 is necessary, i think this has value | 11:19 |
| spot | (or Requires: glibc) | 11:19 |
| delero | +1 from me overall | 11:20 |
| spot | +1 from me as well | 11:20 |
| delero | is there a tool that will automatically prune out unnecessary Rs given a list ? | 11:20 |
| delero | (i.e. where one of the R already brings in the other one, like gnome,glib) | 11:21 |
| spot | delero: not that I know of, but it would be useful (and I suspect, not terribly difficult to write) | 11:21 |
| racor | IMO, the primary problem is explicit "package" deps tending to cause broken deps and installation bloat | 11:21 |
| racor | +1 | 11:21 |
| rdieter | +1 | 11:21 |
| tibbs | spot: I'm concerned that the guideline doesn't actually talk about the situation of versioned dependencies becoming out of date. | 11:21 |
| tibbs | It just says "out-of-date" but doesn't really define what it means. | 11:22 |
| tibbs | I know we have a general "present in the last two releases" rule, but it might be worthwhile to state that explicitly. | 11:22 |
| Rathann | good point tibbs | 11:22 |
| spot | okay, I can do that | 11:23 |
| hansg | Suggestion could we change the second part of the review guidelines modification from: "(2) ensure that any explicit Requires are explained with comments in the spec file." to "(2) ensure that any *non standard * explicit Requires are explained with comments in the spec file." | 11:24 |
| abadger19991 | here now | 11:24 |
| hansg | The * * denote the change | 11:24 |
| spot | i'm not opposed to that change. what does everyone else think? | 11:24 |
| hansg | Otherwise I'm afraid new inexperience reviewers are going to ask for comments for each and every Requires | 11:25 |
| tibbs | Does "ensure" sort of imply "must" to anyone? | 11:25 |
| Rathann | hansg: "non-standard" as in: not explicitely mentioned in packaging guidelines? | 11:25 |
| hansg | I know non standard is vague, but it atleast hints that not each and every Requires needs a comment | 11:25 |
| hansg | Rathann, yes and no that sort of covers it but not completely, Directory ownership requires are in the guidelines, but i'm sure there are other very straightforward Requires uses which are not | 11:26 |
| spot | tibbs: how does this sound as an added sentence: "For example, Fedora packages are only required to retain historical provides for two full release cycles." | 11:26 |
| racor | tibbs: yes, to me "ensure" is a synonym to "must" | 11:27 |
| tibbs | spot: Yes, I agree. | 11:27 |
| hansg | racor, tibbs to me too | 11:27 |
| abadger19991 | I'd -1 the whole of section (2). | 11:27 |
| delero | i'd add a comment to make it clear this only applies to Requires, not BuildRequires | 11:28 |
| tibbs | How about "please consider adding comments to dependencies which are nonobvious"? | 11:29 |
| tibbs | Hell, "please comment anything in your spec which is nonobvious". | 11:29 |
| hansg | abadger19991, that might actually be a good idea, the need to add comments in a non standard situation is something which applies to any non standard situation, so if we just leave in (1) for the review guidelines and adjust the package guidelines addition to match this (ie no talk about comments) I think it will be better | 11:29 |
| tibbs | But then we get to argue about obviousness. | 11:29 |
| *** abadger19991 is now known as abadger1999. | 11:29 | |
| hansg | tibbs, exactly we need a "please comment anything in your spec which is nonobvious". This does not belong (*here*) (as in no in a piece about Requires( | 11:30 |
| spot | how about: "SHOULD: Reviewer should examine an RPM package's list of dependencies and recommend that any unnecessary explicit Requires within the spec file are removed." | 11:30 |
| rdieter | my obviousness bikeshed is pale blue | 11:30 |
| hansg | spot: "SHOULD: Reviewer should examine an RPM package's list of dependencies and any unnecessary explicit Requires found must be removed." | 11:30 |
| spot | i don't like putting "must" in a SHOULD. | 11:31 |
| hansg | As in the checking the requires is optional, but if the reviewer goes through the trouble to do it, the submitter must fix it ? | 11:31 |
| abadger1999 | can we make it a MUST without the comment section? | 11:31 |
| spot | we could do it as a MUST and a SHOULD | 11:32 |
| hansg | Spot, But I'm fine with your original one too | 11:32 |
| hansg | spot MUST and SHOULD ? | 11:32 |
| hansg | I'm ok with making this a MUST without the comment thingie | 11:32 |
| spot | MUST: Reviewer must examine an RPM package's list of dependencies and any unnecessary explicit Requires found must be removed. | 11:32 |
| hansg | spot +1 | 11:32 |
| spot | SHOULD: Any explicit Requires should have a comment which describes why they are necessary. | 11:33 |
| hansg | spot -1 | 11:33 |
| spot | i think there is some value in the comments, we should encourage them, but not require them. | 11:33 |
| spot | if someone picks up a retired package, they may not know why there is a versioned Requires. | 11:33 |
| hansg | I think we need to add something like: "SHOULD: anything in the spec file which is nonobvious should have a comment explaining it" | 11:34 |
| spot | SHOULD: Anything in the spec file which is nonobvious (such as explicit Requires) should have a comment explaining it | 11:34 |
| hansg | Erm, sorry, but no. explicit requires can actually be very obvious | 11:35 |
| spot | such as "some explicit Requires" | 11:35 |
| hansg | How about: SHOULD: Any versioned Requires should have a comment explaining it | 11:35 |
| abadger1999 | If this is a top level SHOULD, it shouldn't mention Requires.... | 11:36 |
| spot | no, because that doesn't cover someone who really does need Requires: glibc for some horrible reason | 11:36 |
| hansg | I could live with that (change from Spot's proposal I -1 -ed is the adding of versioned) | 11:36 |
| abadger1999 | We can have a sentence in the longer explanation in the Requires guideline saying, Remember the "Should: Comments!" guideline | 11:36 |
| spot | abadger1999: yeah, okay, let me draft that up a bit... | 11:37 |
| hansg | spot, if someone needs something for some horrible reason that is plain non obvious and thus needs a comment independend on wether it is a Requires or some !@%$ ugly shell or whatever | 11:37 |
| spot | what would some other examples of non-obvious items in a spec file be? | 11:40 |
| tibbs | I'm always requesting that things be commented in specfiles, but I can't think of a single example off the top of my head. | 11:41 |
| abadger1999 | FHS violations | 11:41 |
| tibbs | Maybe things like Obsoletes:, complex licensing issues. | 11:41 |
| tibbs | When you run sed over libtool to filter rpath or pass -Wl,as-needed. | 11:42 |
| abadger1999 | Changes to optflags | 11:43 |
| hansg | sed -ing the hell out of Makefile(s) / configure scripts | 11:43 |
| hansg | Not using %configure because the configure script is non standard and does not like being called through %configure | 11:43 |
| hansg | Not using make install but DIY for various reasons | 11:43 |
| abadger1999 | excluding patented code from an upstream tarball | 11:44 |
| hansg | Need we go on ? :) | 11:44 |
| spot | no, i think thats enough examples. :) | 11:44 |
| spot | okay, take a look at it now | 11:45 |
| spot | https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires | 11:45 |
| rdieter | worksforme, +1 | 11:47 |
| abadger1999 | How about: :MUST: an RPM package's list of dependencies must not contain any unnecessary explicit Requires | 11:47 |
| hansg | looks good, but | 11:48 |
| hansg | Under "Addition to Packaging Guidelines" | 11:48 |
| abadger1999 | That's just because I don't think anything else speaks to reviewers specifically. | 11:48 |
| hansg | It still says: Any explicit Requires should be explained with comments in the spec file." | 11:48 |
| spot | abadger1999: that is better wording. | 11:48 |
| abadger1999 | Instead it's about what the package must conform to. | 11:48 |
| hansg | Its a should, but still a bit strong IMHO | 11:49 |
| spot | if i add "non-obvious" there... | 11:49 |
| spot | would that make it less strong? | 11:49 |
| hansg | Also "Packages should not contain superfluous explicit Requires within the spec file, except when absolutely necessary." is a bit double, when something is "absolutely necessary." it clearly is not "superfluous" | 11:49 |
| hansg | spot, adding no obvious +1 | 11:50 |
| spot | hansg: how about i drop superfluous from that sentence? | 11:50 |
| hansg | spot, yes that would be better | 11:50 |
| hansg | +1 with those 2 changes | 11:51 |
| spot | and really, we made that a must | 11:51 |
| spot | so... it should be a must in the guidelines too | 11:51 |
| hansg | spot, ack | 11:51 |
| spot | "Packages must not contain explicit Requires within the spec file, except when absolutely necessary. " | 11:51 |
| spot | okay everyone | 11:52 |
| spot | one last time. | 11:52 |
| abadger1999 | Okay, looks good. +1 | 11:52 |
| delero | +1 | 11:53 |
| spot | +1 from me | 11:53 |
| rdieter | +1 | 11:53 |
| Rathann | +1 | 11:53 |
| tibbs | +1 | 11:53 |
| racor | +1 | 11:53 |
| spot | i'm assuming hansg's +1 holds over | 11:53 |
| hansg | yes, still +1 | 11:54 |
| spot | it passes | 11:54 |
| spot | the next item is the updated Haskell guidelines | 11:54 |
| spot | https://fedoraproject.org/wiki/PackagingDrafts/Haskell | 11:54 |
| hansg | Yes I was already reading them (hence the no voting) | 11:54 |
| spot | I manually did a diff of the proposed new guidelines and the old ones | 11:54 |
| spot | the key differences are: some of the macros have been changed (the update reflects the new ones) | 11:55 |
| spot | They've improved some of the wording without changing the meaning, and they've documented the use of the "cabal" tool further | 11:55 |
| hansg | +1 from me | 11:56 |
| spot | +1 from me as well | 11:56 |
| Rathann | I like them although I have a question | 11:56 |
| * hansg goes to help put the children in bed, back in 15 or so | 11:56 | |
| Rathann | why are -doc and -prof subpackages optional? | 11:56 |
| tibbs | Well, the -prof packages aren't always generally useful. | 11:57 |
| tibbs | -doc packages might be pointless if there's very little documentation. | 11:57 |
| Rathann | all these %if %endif sections add clutter to an otherwise clean specfile | 11:57 |
| Rathann | just MHO | 11:58 |
| spot | yes, but that's not a new change. | 11:58 |
| Rathann | +1 from me anyway | 11:58 |
| spot | (and they're just templates, if you don't need those sections, you can drop them entirely) | 11:58 |
| Rathann | right | 11:58 |
| tibbs | +1 | 11:59 |
| spot | thats a +4... | 11:59 |
| racor | 0, i think this all should go to rpmdev templates and not into the FPG | 11:59 |
| abadger1999 | It's interesting that they have %cabal build but %cabal_install | 12:00 |
| Rathann | racor: it is in rpm macros provided by the ghc package IIUC | 12:00 |
| rdieter | +1 | 12:00 |
| Rathann | ah, you mean the spec templates | 12:00 |
| delero | +1 from me | 12:00 |
| Rathann | racor: yes, not a bad idea | 12:00 |
| spot | okay, +6, it passes | 12:01 |
| Rathann | or rpmdevtools-haskell subpackage | 12:01 |
| * spot notes that the templates aren't actually in the FPG, they're just linked to from the guidelines | 12:01 | |
| abadger1999 | +1 | 12:01 |
| spot | okay, next item (this should be fun): https://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 | 12:02 |
| spot | ignore the font related text here. | 12:02 |
| spot | the real question is, what do we want to require for symbolic and absolute links in Fedora packages | 12:02 |
| tibbs | Did we have any luck with just doing it automatically? | 12:02 |
| spot | last meeting, we hoped this could be handed with the "symlinks" utility as part of rpm | 12:02 |
| spot | Jeremy looked into it, but determined that it was not possible with that tool | 12:03 |
| spot | because it was finding tons of false positives due to the rpm buildroot being involved | 12:03 |
| abadger1999 | enrico pointed out that relative symlinks break when bind mounting or symlinking directories. | 12:03 |
| spot | The simplest solution would be to not require any sort of forced symlinking methodology and ask the rpmlint maintainer to silence that warning in Fedora | 12:05 |
| spot | basically, leave how a packager creates a symlink up to the packager. | 12:05 |
| spot | It seems there are notable pluses and minuses for both approaches. | 12:06 |
| Rathann | indeed | 12:06 |
| Rathann | I wonder why is option 3 any better | 12:06 |
| abadger1999 | option 3 is what debian does but I don't think it has any advantages. | 12:06 |
| spot | i think option 3 is how Debian tries to average it out. | 12:06 |
| Rathann | I'd say leave it up to the packager, but maybe document pros and cons of each option | 12:07 |
| spot | okay, that makes sense. what are the pros/cons of the absolute links | 12:08 |
| * spot is writing a new mini draft | 12:08 | |
| tibbs | The chroot issue, I guess, is the biggest one. | 12:10 |
| Rathann | absolute symlinks are straightforward and easier to create (you don't get lost in multiple ../../ levels) | 12:10 |
| Rathann | nicolas' draft says: "Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location." | 12:11 |
| racor | IMO, it's amd and programs which somehow try to resolve paths but get confused by obtaining unexpected results. | 12:11 |
| Rathann | http://www.mail-archive.com/debian-policy@lists.debian.org/msg22444.html | 12:13 |
| racor | Rathann: nicolas is right on this. It's essentially the same as what I referred to as amd issue. | 12:13 |
| racor | in a nutshell it is: Which directory will tools/programs be see if /foo/boo/ is mounted under /bar/baz/ ? | 12:15 |
| Rathann | something like that | 12:16 |
| Rathann | also, this is a very old issue: http://www.zarb.org/pipermail/rpmlint-discuss/2006-June/000094.html | 12:16 |
| racor | Rathan: This issue likely predates linux ;) | 12:17 |
| rdieter | the rpmlint-discuss thread includes some additional abs->rel recipes, worth exploring? | 12:18 |
| Rathann | https://www.redhat.com/archives/fedora-packaging/2006-August/thread.html#00277 | 12:18 |
| spot | https://fedoraproject.org/wiki/PackagingDrafts/Symlinks | 12:19 |
| Rathann | in particular: https://www.redhat.com/archives/fedora-packaging/2006-August/msg00289.html | 12:19 |
| Rathann | spot: s,/usr/bin,%{_bindir},g ;) | 12:20 |
| spot | heh, fixed now | 12:21 |
| spot | i know we're way over time, so if everyone still with us could take a look at that draft | 12:22 |
| Rathann | so if this passes, what are maintainers supposed to do about bugs like this: https://bugzilla.redhat.com/show_bug.cgi?id=474057 | 12:22 |
| buggbot | Bug 474057: medium, low, ---, than@redhat.com, ASSIGNED, meinproc4 creates absolute instead of relative symlinks for the common directory | 12:22 |
| spot | Rathann: they can decide to either make the change or close it wontfix | 12:22 |
| tibbs | Does rpm have any issues with symlinks (replacing symlinks with files/directories and such) that would relate to this guideline? | 12:22 |
| spot | tibbs: no, this one arose from rpmlint throwing warnings | 12:22 |
| tibbs | I understand; I'm just wondering if there's any instance where rpm itself would care whether a symlink is absolute or relative. | 12:23 |
| spot | not that i'm aware of. | 12:24 |
| rdieter | I'm ok with the draft as-is +1, there seems to be no clear cut winner | 12:25 |
| spot | I'm also +1 on this | 12:25 |
| *** rdieter is now known as rdieter_away. | 12:25 | |
| --> rdieter has joined this channel (n=rdieter@pcp089243pcs.unl.edu). | 12:26 | |
| abadger1999 | How about: "relative symlinks will point to the same file inside or outside of a chroot" | 12:26 |
| spot | as a pro? | 12:26 |
| abadger1999 | As the pro. | 12:27 |
| racor | spot: Can we let this proposal rest until the next meeting? | 12:27 |
| spot | sure. | 12:27 |
| abadger1999 | Just saying "better" leads to "Why are they better?" | 12:27 |
| spot | racor: i suppose we can, if necessary | 12:27 |
| spot | if possible, i'd like to vote on it now and then adjourn | 12:27 |
| abadger1999 | Since there's no actions to be taken by packagers, just information I'm +1. | 12:28 |
| Rathann | +1 | 12:28 |
| racor | abadger1999: rel symlinks are better in most cases ;) | 12:28 |
| spot | I count +4 for this | 12:28 |
| abadger1999 | heh | 12:28 |
| racor | spot: My time's up, I got to go, bye. | 12:28 |
| spot | racor: thanks for your time | 12:28 |
| spot | tibbs, delero, hansg? | 12:28 |
| hansg | I'm back, what should I vote about ? :) | 12:29 |
| spot | https://fedoraproject.org/wiki/PackagingDrafts/Symlinks | 12:29 |
| tibbs | I'm sort of ambivalent. | 12:29 |
| spot | tibbs: then this is the perfect draft for you, as it really lets the packager decide. ;) | 12:30 |
| hansg | +1 from me | 12:30 |
| spot | okay, thats +5, but if anyone else wants to vote on the record, feel free | 12:30 |
| nim-nim | relative symlinks have one more cons | 12:31 |
| nim-nim | they assume the value of rpm directory macros is known beforehand and set in stone | 12:31 |
| Rathann | I wonder how relative symlinks are better, aside from the chroot issue | 12:31 |
| tibbs | How about some requirement that packagers be consistent? | 12:31 |
| tibbs | Or is that important? | 12:31 |
| spot | tibbs: I think there is merit in that | 12:32 |
| spot | is anyone opposed to adding a line that says that packagers should be consistent with the symlinking method throughout a package? | 12:32 |
| nim-nim | spot: what's the value? | 12:33 |
| nim-nim | sometimes making a relative symlink will be trivial | 12:33 |
| delero | not a big fan of absolute symlinking | 12:33 |
| spot | well, if half of a package works with a chroot and the other half doesn't... | 12:33 |
| spot | i think it would be better if all of it worked or none of it. | 12:33 |
| spot | less unexpected surprises. | 12:33 |
| spot | "Packagers should use their best judgement when deciding which method of symlink creation is appropriate, but should also be consistent with whichever method they choose." | 12:34 |
| Rathann | spot: +1, even if that's obvious | 12:34 |
| nim-nim | spot: the case is when your package creates its own directory tree and does relative symlinks within it | 12:34 |
| nim-nim | (which is what the debian people tried to express IMHO) | 12:34 |
| nim-nim | but anyway I don't care as long as the warning is shot | 12:35 |
| spot | ehh, okay, i see that point. | 12:35 |
| spot | i"Packagers should use their best judgement when deciding which method of symlink creation is appropriate, but should also be consistent with whichever method they choose to use in the spec file." | 12:35 |
| spot | how about that? | 12:35 |
| spot | or should we just drop the consistency... | 12:35 |
| spot | eh. i'll drop the consistency req. if we really need it, we can add it later. | 12:36 |
| nim-nim | spot: IMHO the "consistency" thing is just too hard to define in a sane way | 12:36 |
| spot | nim-nim: yeah, i think you're right | 12:36 |
| spot | okay, the floor is open to any other items | 12:36 |
| spot | please keep in mind, we're waaay over time for today. :) | 12:36 |
| abadger1999 | spot: Well... /usr/bin/gzcat => gzip could be a valid relative symlink amidst more major absolute symlinks | 12:36 |
| Rathann | abadger1999: it's in the same directory, those are quite safe | 12:37 |
| abadger1999 | (sorry... was aimed at droppin gconsistency) | 12:37 |
| spot | if there are no other new issues, i'm going to call the meeting... | 12:37 |
| nim-nim | spot: just a question, what is the procedure to add a "check your font files" to the package review list? | 12:38 |
| Rathann | abadger1999: ah, right :) | 12:38 |
| spot | nim-nim: just write a draft that has the line you want to add to the ReviewGuidelines | 12:38 |
| * nim-nim does not want to do another audit next year | 12:38 | |
| nim-nim | spot: ok, will do | 12:38 |
| spot | alright, we're done for today. | 12:39 |
| spot | thanks everyone. | 12:39 |