16:09:37 <abadger1999> #startmeeting fpc
16:09:37 <zodbot> Meeting started Wed Nov 10 16:09:37 2010 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:09:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:10:20 <abadger1999> ##meetingname fpc
16:10:24 <abadger1999> #meetingname fpc
16:10:24 <zodbot> The meeting name has been set to 'fpc'
16:10:31 * abadger1999 needs to learn to type
16:10:34 <abadger1999> Who's here?
16:10:49 <tibbs|h> You and I, it looks like.
16:11:11 <abadger1999> spot, rdieter_work, racor, geppetto: ping
16:11:14 <racor> I am here
16:11:19 <geppetto> here
16:11:20 <abadger1999> Okay, that's three.
16:11:22 * thomasj lurking
16:11:23 <abadger1999> four
16:11:30 <abadger1999> Need one more for quorum.
16:11:37 <rdieter_work> here
16:12:05 <abadger1999> Alrighty.
16:13:36 <abadger1999> #topic Java packaging guidelines: https://fedorahosted.org/fpc/ticket/24
16:14:18 <abadger1999> People were discussing this on the list.  Does anyone here know ifthe discussion finished?
16:14:53 <tibbs|h> Which list?
16:15:27 <abadger1999> This is the thread: http://lists.fedoraproject.org/pipermail/devel/2010-November/144924.html
16:17:07 * abadger1999 sees if sochotni is available
16:17:12 <tibbs|h> My recollection of that is that they were discussing additional things they might want to change, and some issue unrelated to the guidelines.
16:18:25 <sochotni> here...
16:18:29 <abadger1999> hey sochotni
16:18:33 <sochotni> abadger1999: hi
16:18:44 <sochotni> thanks for letting me know
16:18:47 <abadger1999> Is the guidelines update posted in the fpc ticket ready for us to talk about?
16:18:55 <sochotni> yes
16:19:21 <sochotni> we are planning several small updates later on, but this is THE main update
16:19:52 <sochotni> the java guidelines have been behind actual practice for some time and we wanted to make them more up-to-date
16:19:56 <abadger1999> k  Is the diff also up to date?
16:20:00 <abadger1999> <nod>
16:20:14 <tibbs|h> There seems to be a typo added to the Wrapper Scripts section.
16:20:23 <tibbs|h> "provide a wrapper script in <code>%{_bindir</code>}."
16:20:55 <sochotni> abadger1999: the diff is attached to ticket AFAIK
16:21:04 <sochotni> yup: https://fedorahosted.org/fpc/attachment/ticket/24/draft.diff
16:21:51 <tibbs|h> Shouldn't the templates remove the stuff not needed in Fedora?
16:21:52 <sochotni> tibbs|h: you mean the '}' at the end?
16:22:02 <rdieter_work> sochotni: yes
16:22:19 <tibbs|h> sochotni: Well, it changed position with the </code> bit in this draft for some reason.
16:22:21 <sochotni> yes that's a typo
16:22:33 <geppetto> sochotni: Why the extra spaces in BR/Requires?
16:22:56 <sochotni> tibbs|h: fixed the typo
16:23:07 * rdieter_work doubts those whitespace changes matter much really
16:23:24 <geppetto> sochotni: Same problem later on with %{_bindir}
16:23:31 <tibbs|h> So the spec templates shouldn't have BuildRoot, %clean or the buildroot cleaning in %install.
16:23:37 <tibbs|h> I mean, if we're updating them.
16:23:58 <abadger1999> We'll need some EPEL5 pointers: * The javadoc subpackage '''MUST''' be declared <code>noarch</code> even if main package is architecture specific.
16:24:22 <akurtakov> I didn't know we have formatting guidelines
16:24:38 <tibbs|h> Pardon?
16:24:45 <akurtakov> anyway we will make it whatever the common thing is
16:25:09 <akurtakov> tibbs|h: I was speaking for the extra spaces and etc.
16:25:19 <tibbs|h> We're just asking because they appear in the diff.
16:25:31 <tibbs|h> So if you're requesting a change, we'd like to know why you're requesting the change.
16:25:32 <spot> ugh, i hate daylight savings time
16:25:38 <abadger1999> How does the build-classpath script work?  Does it use rpm to query the rpm database?
16:25:39 <tibbs|h> You can't expect that we wouldn't ask about it.
16:25:44 * spot apologizes
16:25:52 <sochotni> as for the EPEL5... is javadoc generated by gcj arch specific?
16:26:04 <sochotni> abadger1999: no, it's a stupid bash script
16:26:48 <akurtakov> tibbs|h: np,  it's always good if someone looks in the details
16:26:54 <sochotni> tibbs|h: the whitespace changes were caused by cleaning-up/prettyfying templates
16:26:54 <geppetto> sochotni: Another typo, near the bottom: <code>%{_jnidir</code>}
16:27:07 <geppetto> sochotni: And, <code>%{_libdir</code>}
16:27:25 <geppetto> And a couple of <code>%{_javadir</code>}
16:27:47 <sochotni> there are more for </code>} problems
16:27:53 <sochotni> seems like wrong search/replace
16:27:56 <abadger1999> sochotni: Okay.  How does build-classpath expands rpm package names into jar filenames?
16:28:17 <spot> abadger1999: i don't think it does, i think it looks at the filesystem
16:28:24 <akurtakov> abadger1999: it doesn't
16:28:33 <sochotni> abadger1999: what spot said
16:28:34 <abadger1999> Oh -- so this is a different definition of package? "You can use either package names (all jar files will be included) or jar filenames "
16:28:35 <akurtakov> abadger1999: it looks in %{javadir}
16:28:44 <sochotni> it just assumes it will find it in /usr/share/java basically
16:28:51 <abadger1999> Could we put something in there to explain what a package means there?
16:28:59 <spot> from the script: find "$extension" -follow -name "*.jar" -xtype f -printf %p
16:29:37 <akurtakov> abadger1999: this is because for packages that install more than 2 jars should put their jars into %{_javadir}/%{name}
16:30:43 <abadger1999> Okay -- so it is rpm package name?  Just that the filesystem is structured so that you can lookup the jars without querying rpm?
16:30:52 <sochotni> abadger1999: yup
16:30:54 <akurtakov> abadger1999: yes
16:30:58 <abadger1999> Okay, that makes sense now.
16:31:04 <abadger1999> Current wording is fine then.
16:31:08 <sochotni> that's why the jars have to be named according to rpm name
16:31:47 <sochotni> all those ">}" should be fixed now
16:32:26 <akurtakov> abadger1999: it's the If the number of provided JAR files exceeds two, you MUST place them into a sub-directory named %{name}.  line that defines this
16:34:04 <spot> fwiw, these guidelines look pretty good to me, with my recent java packaging experience. :)
16:34:42 <sochotni> most of these things have already been used for some time (%{_mavenpomdir} macro for example)
16:34:46 * rdieter_work of a mind to largely rubber-stamp this given this comes from the java-sig, and there seems to be nothing obviously bad/broken here.
16:34:48 <akurtakov> spot: thanks, I really see this update as the "bring them back to reallity"
16:35:06 <spot> akurtakov: *nod*
16:35:33 <sochotni> if there will be problems with changes...we'll fix the guidelines. It's not like this will be set in stone. (Not that I expect problems :-) )
16:35:57 <spot> with the typo cleanups, I'm +1 here.
16:36:05 <akurtakov> there are a number of other changes we would like to see but there is other work needed to allow changes/simplification of the guidelines
16:36:17 <geppetto> yeh, me too … +1
16:36:24 <rdieter_work> +1 too
16:36:36 <abadger1999> Why are we removing the rm of *.class and *.jar in the maven template?
16:37:04 <sochotni> abadger1999: well I haven't seen any maven package with bundled jars/classes
16:37:10 <sochotni> apart from test cases...
16:37:19 <abadger1999> test cases would count.
16:37:22 <spot> sochotni: i wouldn't assume that, i pulled lots of out etherpad deps. :)
16:37:37 <spot> out of, rather.
16:37:38 <sochotni> as in...small jars that are used for testing not ones that are run...
16:37:41 <sochotni> basically data files
16:38:00 <akurtakov> spot: it's really difficult to make maven use jars you ship
16:38:13 <akurtakov> you would have to either embed ant in in the build
16:38:21 <spot> akurtakov: yeah, but i'd still rather be safe than sorry her.e
16:38:25 <akurtakov> or install the jars in your local repo
16:38:42 <abadger1999> hmm....
16:38:42 <spot> on that topic
16:39:00 <spot> it would also be useful to use the updated jar checking in the templates
16:39:02 <akurtakov> spot: it's like requesting autotools based builds to always remove *.so files
16:39:33 <sochotni> spot: what do you mean?
16:40:06 <spot> oh, never mind. misread it.
16:40:19 <abadger1999> akurtakov: We do that.
16:40:37 <sochotni> abadger1999: yes, but do you have it in every autotools based project?
16:40:44 <akurtakov> abadger1999: to have a rm ... line in every %prep section?
16:41:03 <sochotni> I assume just ones that are ugly/behaving badly
16:41:05 <abadger1999> Or just depend on the packager to realize that they have to put it in, you mean?
16:41:07 <spot> i think i'd still feel better having it in the template, to prevent an accidental inclusion.
16:41:42 <abadger1999> Yeah... nim-nim felt that in the java world it was better to have it in... but if maven is different, then I can see leaving it out of the template.
16:41:57 * spot has seen tarballs which had both source and binary in the same tarball
16:42:01 <sochotni> ant builds need to have this definitely...
16:42:28 <sochotni> but I really see no use case to make all packages ugly, because of 2-3 packages
16:42:39 <spot> but i also see the point about how maven isn't likely to actually use/install those .jar files
16:42:42 <akurtakov> I can assure you that non-experienced maven user will have a really hard time making maven use the jars from his tarball
16:42:45 * abadger1999 fine leaving it out but lacks real-world experience on how widespread the problem is
16:42:50 <sochotni> because this really needs maven + ant combination to pull off
16:42:53 <spot> okay, i'm fine with leaving it out.
16:43:00 <abadger1999> Do we still want the explicit BuildArch: noarch for the javadodc subpackages?
16:43:14 <akurtakov> abadger1999: not if the whole package is noarch
16:43:46 * spot thinks the templates not being redundant is okay
16:43:51 <abadger1999> what package owns the %{_mavendepmapfragdir} ?
16:44:02 <akurtakov> abadger1999: jpackage-utils
16:44:22 <spot> (among many others...)
16:44:23 <sochotni> plus there is this: The javadoc subpackage '''MUST''' be declared <code>noarch</code> even if main package is architecture specific.
16:45:03 * spot is still +1 here. :)
16:45:21 <tibbs|h> sochotni: What about that statement?
16:45:52 <sochotni> tibbs|h: abadger1999 wanted to know about noarch in javadoc subpackages
16:46:05 <sochotni> < abadger1999> Do we still want the explicit BuildArch: noarch for the javadodc subpackages?
16:46:15 <tibbs|h> I would assume so.
16:46:30 <spot> tibbs|h: we only added that because the old templates were arch specific by default
16:46:35 <sochotni> tibbs|h: no, because when main package is noarch there is no need to sub-packages to be marked as such
16:46:36 <spot> tibbs|h: the new templates are noarch by default
16:47:13 <tibbs|h> Still, if we're doing that, why not drop the other stuff not needed by Fedora?
16:47:13 <abadger1999> Okay... I only have one more question :-)
16:47:43 <abadger1999> In the maven template %install we have this:
16:47:44 <tibbs|h> I mean, the guidelines as is already don't work for EPEL5, so there's no reason to keep that stuff in.
16:47:44 <abadger1999> install -pm 644 pom.xml $RPM_BUILD_ROOT/%{_mavenpomdir}/JPP-package-name.pom
16:47:59 <akurtakov> tibbs|h: what do you refer to?
16:48:10 <abadger1999> Is the filename literally "JPP-package-name.pom "
16:48:24 <tibbs|h> Do noarch subpackages work on EL5?
16:48:28 <abadger1999> Or is it JPP-%{name}.pom or something different.
16:48:31 <tibbs|h> I thought it was too old to support them.
16:48:47 <rdieter_work> tibbs|h: it is, correct (afaik)
16:49:28 <spot> tibbs|h: yeah, i think you're right.
16:49:30 <akurtakov> abadger1999: it is $RPM_BUILD_ROOT%{_mavenpomdir}/JPP-%{name}.pom
16:50:06 * abadger1999 fixes that to be clear
16:52:10 <abadger1999> Okay, +1 from me
16:52:17 <spot> +1
16:52:37 <geppetto> +1
16:52:40 <tibbs|h> So, I'm confused.  Are we leaving in the unnecessary parts of the templates or not?
16:52:51 <abadger1999> BuildArch is not there.
16:52:54 <akurtakov> tibbs|h: which ?
16:53:04 * abadger1999 okay with omitting other unnecessary parts if they're there
16:53:06 <tibbs|h> BuildRoot, %clean, cleaning of buildroot in %install.
16:53:18 <spot> tibbs|h: we haven't be forcing removal from the other guidelines either, it would seem to make sense to simply audit the entire guidelines and remove unnecessary items in one pass.
16:53:26 <abadger1999> yes, please take those out too.
16:53:32 <tibbs|h> Sure, but since we're changing stuff....
16:53:41 <spot> eh, okay
16:53:42 <abadger1999> eh, we're touching the guideline now, might as well...
16:53:44 <sochotni> I have no problem with removing it...
16:53:53 <akurtakov> sochotni: please remove them
16:53:56 <tibbs|h> Anyway, +1 either way; we'll just take it out later.
16:53:57 <sochotni> I don't think anyone else will mind...as long as EPEL will keep working..
16:54:06 <sochotni> I'll do it right away...
16:54:08 <spot> sochotni: well, EL-6 will work, EL-5 won't. :)
16:54:26 <tibbs|h> EL-5 won't work with those guidelines already.
16:54:44 <tibbs|h> But the EPEL folks already document these differences.
16:54:57 <sochotni> ok, removing cruft
16:55:48 <abadger1999> We're at +4 I think (spot, tibbs|h, abadger1999, geppetto)
16:56:13 <rdieter_work> +1 here still
16:56:22 <abadger1999> Okay, +5
16:56:41 <abadger1999> racor: +/- or comments?
16:56:42 <racor> 0 from me, this is not my domain.
16:56:42 <spot> akurtakov & sochotni: thanks for your work in this area, long overdue. :)
16:56:47 <abadger1999> <nod>
16:56:51 <abadger1999> Okay, it passes.
16:56:56 <sochotni> thanks guys
16:57:13 <racor> One point if [ -f /usr/share/java-utils/java-functions ] ; from the wrapper script doesn't make much sense to me
16:57:43 <akurtakov> thanks, we can finally work according to the guidelines :)
16:57:46 <sochotni> racor: that is so that if comeone copies the script to non-fedora system it won't barf with random errors
16:57:51 <racor> BR: /usr/share/java-utils/java-functions and the old scrtipt should suffice
16:57:59 <abadger1999> #info Java update ticket #24 passes (+1: 5, 0: 1, -1: 0)
16:58:12 <gholms|work> A file Requirement of something in /usr/share?
16:58:32 <akurtakov> racor: jpackage-utils needs updates as badly as the guidelines needed
16:58:39 <sochotni> racor: the app would probably crash with some weird classloading exception
16:58:39 <akurtakov> we're just not upto this point
16:58:46 <abadger1999> gholms|work: If the use case for that is "someone copying the file manually to another system requirements won't help.
16:58:59 <abadger1999> <nod>
16:59:07 <abadger1999> spot: Care to take over running the meeting?
16:59:12 <spot> abadger1999: sure.
16:59:58 <spot> i was here for ticket 24
17:00:01 <spot> did we do ticket 22?
17:00:49 <tibbs|h> Not yet.
17:00:55 <spot> okay then
17:01:03 <tibbs|h> We talked about it last week; I updated as promised.
17:01:08 <spot> #topic Ban Pretrans - https://fedorahosted.org/fpc/ticket/22
17:01:19 * spot eyes the bot
17:01:56 <spot> abadger1999: i think you'll have to tell the bot i can run the meeting. :)
17:01:57 <tibbs|h> You aren't a chair, I guess.
17:01:59 <abadger1999> #chair spot
17:01:59 <zodbot> Current chairs: abadger1999 spot
17:02:02 <spot> #topic Ban Pretrans - https://fedorahosted.org/fpc/ticket/22
17:02:17 <spot> this seems like a no-brainer to me.
17:02:32 <spot> err, this seems obviously correct.
17:02:33 <geppetto> Yeh, the title of the ticket is a bit off, given the text we are voting on … but +1
17:02:38 <abadger1999> +1
17:02:41 <rdieter_work> +1
17:02:46 * spot needs to remember not to confuse racor with slang. :)
17:02:48 <spot> +1
17:02:53 <tibbs|h> +1
17:03:13 <spot> that's +5, racor, would you like to vote for the record?
17:03:53 <racor> +1
17:04:22 <spot> #action Pretrans addition passes (+1: 6, 0: 0, -1: 0)
17:04:46 <spot> #topic Rpmlint clarifications - https://fedorahosted.org/fpc/ticket/21
17:05:00 <spot> tibbs|h: it looks like some of this is already done, is there anything else here to discuss/consider?
17:05:13 <tibbs|h> I made the minor changes and then proposed the additional sentence as promised.
17:05:31 <spot> additional sentence looks good to me.
17:05:35 <tibbs|h> But I don't know if it's worth it, honestly.  It's just that most people don't realize that you can get more output from rpmlint.
17:06:02 <tibbs|h> I always install built packages (in the mock chroot) and run rpmlint for the extra output.  Occasionally it confuses folks.
17:06:02 <abadger1999> Looks fine to add.
17:06:11 <spot> for the record, the additional sentence is: "Note that rpmlint will perform additional checks if given the name of an installed package. For example, yum install foo-1.0-1.f20.x86_64.rpm; rpmlint foo will perform a set of tests on the foo package that rpmlint foo-1.0-1.f20.x86_64.rpm cannot."
17:06:20 <racor> I am confused. I thought we already mandate running rpmlint on installed packages in reviews ...
17:06:55 <tibbs|h> We do.
17:07:05 <spot> tibbs|h: where?
17:07:25 <abadger1999> MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1]
17:07:27 <spot> i see where we talk about running it on the source and binary packages, but not the installed packages.
17:07:38 <tibbs|h> Oh, sorry, installed packages.
17:07:50 <tibbs|h> No, we don't mandate that.  I'm not sure if we want to do so or not.
17:08:12 <spot> while it is useful, i'm not sure whether it will make people less willing to review packages or not.
17:09:15 <tibbs|h> Honestly, I'm not sure if we even mandate that reviewers check that packages actually install.
17:09:17 <abadger1999> Depends on how frequently people review far afield from what they normally do I suspect.
17:09:47 <spot> I think i'd prefer to just add the information to the guidelines at this point, and not make it mandatory that anyone check it.
17:09:56 <rdieter_work> spot: +1
17:09:57 <racor> tibbs|h If so, we've failed
17:09:59 <abadger1999> I don't believe we do.
17:10:32 <spot> So, i
17:10:43 <spot> So, I'm +1 on adding the sentence as proposed.
17:11:00 * spot wonders who thought putting the ' next to the Enter key was a good idea...
17:11:01 * abadger1999 could add a package review with Requires: gobbledygook to test that hypothesis :-)
17:11:17 <abadger1999> +1
17:11:46 <abadger1999> we can discuss adding a test that the package installs and run rpmlint on the package name later, I suppose.
17:12:10 <spot> abadger1999: seems worthy of consideration.
17:12:38 <abadger1999> That's +3, racor, tibbs|h, geppetto: ?
17:12:40 <tibbs|h> +1
17:12:42 <geppetto> +1
17:12:43 <racor> +1
17:12:59 <spot> okay, thats +6, it passes
17:13:18 <spot> #action Rpmlint clarification sentence approved (+1: 6, 0: 0, -1: 0)
17:13:35 <spot> have we heard back from FESCo re: bundled libraries?
17:13:36 <racor> abadger1999: Yes, tibbs|h is right, we don't mandate a package must install ... funny.
17:13:47 <geppetto> fwiw I also created: https://bugzilla.redhat.com/show_bug.cgi?id=651958
17:14:13 <spot> geppetto: nice.
17:14:51 <spot> nim-nim: ping?
17:15:02 <abadger1999> nirik: fesco bundled libs...discussed already or is that next meeting?
17:15:19 <spot> darn, i am just full of fail today. :/
17:15:20 <nirik> next meeting (which is in about 1 hour and 15min)
17:15:21 <tibbs|h> geppetto: It's not terribly hard to do that in a script.
17:15:55 <geppetto> tibbs|h: yeh, but if it's there for everyone it'll be much more likely to be run (and can be put in docs. etc.).
17:16:10 <abadger1999> nirik: Should we talk about it firs?
17:16:18 <abadger1999> nirik: Or wait for fesco to discuss it?
17:16:42 <sochotni> FYI: I've been doing quite a few reviews recently and I didn't know about those additional rpmlint checks before
17:16:53 <nirik> well, if you guys want to discuss the idea of you handling exceptions that might be good, then at the fesco meeting I could indicate if you are willing to do that or not.
17:17:30 <abadger1999> So -- strawman poll: are we (fpc) willing to handle the exception process instead of fesco?
17:18:00 <abadger1999> This is something that we asked fesco if they wanted to handle many eons ago but it's not working out ideally.
17:18:15 <abadger1999> I'm +1 to being willing to handle it in fpc.
17:18:18 <spot> +1 for willingness to handle it in fpc
17:18:20 <geppetto> I'm "willing" to handle it … although I might be a little -1 happy
17:18:30 <tibbs|h> I don't think we're particularly overworked.
17:18:32 <geppetto> So +1 for willing
17:18:36 <rdieter_work> abadger1999: +1 willing
17:18:45 <tibbs|h> So, sure, we can handle it although honestly I doubt we'd approve very many.
17:18:58 <racor> +1 for willing, but my opinion on bundling is known.
17:19:29 * nirik notes the problem might be people getting rejected by FPC and then trying to get fesco to overrule/look at it again.
17:19:30 <abadger1999> tibbs|h, geppetto: <nod>  That's the general reason that we're presently in conflict with fesco about it.
17:19:40 <abadger1999> nirik: Okay, fpc would definitely be willing.
17:19:44 <abadger1999> <nod>
17:19:44 <nirik> cool.
17:20:01 <abadger1999> Yep, it'll shift the problem around but there's a likelihood that it will still exist.
17:20:15 <spot> so, i don't see any other pending tickets here,
17:20:16 <tibbs|h> So, assuming we're going to do this, what bureaucracy do we want to put in place?
17:20:26 <spot> tibbs|h: lets worry about that when it happens.
17:20:28 <abadger1999> Do we want to talk about whether we want to relax the guidelines?
17:20:32 <abadger1999> (bundling guidelines)
17:20:44 <geppetto> Does anyone want to?
17:20:47 * spot does not want to get too far ahead of ourselves
17:20:50 <tibbs|h> I think it's pretty much happening.
17:20:53 <abadger1999> Or do we just want to see if fesco is willing to let us continue to be strict about it?
17:21:23 <abadger1999> (as long as we're the ones saying no instead of them)
17:21:40 * spot proposes that we see what FESCo decides, given that we've been rather clear about how we feel about bundling. :)
17:22:03 <abadger1999> geppetto: There's been a lot of bundled lib exceptions recently where we (fpc) don't find a compelling reason for the exception to have been granted.
17:22:21 <nirik> is it really a lot? I thought it was 1?
17:22:35 <geppetto> abadger1999: *nods*
17:22:40 <abadger1999> gnu-dna thingy (doesn't remember how to spell it)
17:22:42 <spot> i wouldn't say a lot, but more than 1.
17:22:48 <abadger1999> xulrunner (multiple libraries)
17:23:11 <tibbs|h> I don't think I'm as anti-bundling as most, but I'd want to see things like documentation from packagers as to the reasons for bundling, security exposure from it and the plan for eliminating it.
17:23:30 <spot> tibbs|h: i think that is a sensible list of requirements.
17:23:35 <racor> i regret, my time's is up for today, i've got to quit.
17:23:42 <nirik> gupnp-dlna
17:23:45 <spot> racor: thanks for your involvement
17:24:11 * spot still thinks we should table this until FESCo decides who is authoritative on this issue
17:24:21 <abadger1999> No problems there.
17:24:22 <geppetto> spot: seems fair
17:24:37 <tibbs|h> Well, we're into overtime anyway.
17:24:42 <spot> okay, i see no other pending tickets (that are ready for discussion)
17:24:47 <spot> #topic Open Floor
17:24:53 <abadger1999> Writeups.
17:25:04 <abadger1999> #topic writeup approved guidelines
17:25:04 <tibbs|h> Well, I'll do 21 and 22.
17:25:39 <spot> i will at least do 20 and 24 after lunch.
17:25:50 <abadger1999> Should we assign these when we approve them so they don't get lost?
17:25:56 <abadger1999> (in the future)
17:26:00 <spot> abadger1999: probably.
17:26:07 <abadger1999> I'll grab 23 then
17:26:23 <spot> and i'll do #7 and #12
17:26:32 * abadger1999 grabs #20
17:26:35 <tibbs|h> When we announce these, should we make one big announcement or separate announcements for each change?
17:26:38 <abadger1999> oops spot has that
17:26:43 <spot> abadger1999: you're welcome to it!
17:26:48 <abadger1999> heh :-)
17:26:54 <abadger1999> okay, i'll take it
17:26:56 <spot> tibbs|h: a big announcement might be simpler.
17:27:13 <spot> how about we do this: send the announcement text to me, i will merge and send the big one
17:27:24 <tibbs|h> OK.
17:27:41 <tibbs|h> Or we could put the text in the tickets.
17:27:47 <spot> either/or.
17:28:08 <abadger1999> Sounds good.
17:28:12 <spot> it ends up in my inbox either way. :)
17:28:33 <tibbs|h> True.
17:28:55 <spot> #action tibbs to writeup 21 and 22, abadger1999 to writeup 20 and 23, spot to writeup 7, 12, 24
17:29:14 <spot> #topic Open Floor
17:29:49 <abadger1999> Nothing more from me.
17:33:25 <abadger1999> Thanks guys
17:33:29 <abadger1999> #endmeeting