From Fedora Project Wiki
Fedora Packaging Committee Meeting 2009-03-31
Present
- Jason Tibbitts (tibbs)
- Rex Dieter (rdieter)
- Tom Callaway (spot)
- Toshio Kuratomi (abadger1999)
- Xavier Lamien (SmootherFrOgZ)
Regrets
- Denis Leroy (delero)
- Dominik Mierzejewski (Rathann|work)
- Hans de Goede (hansg)
- Ralf Corsepius (racor)
Votes
The following proposals were considered:
- Documentation Naming
- https://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming
- Accepted (5 - 0)
- Embedded Desktop Files
- https://fedoraproject.org/wiki/PackagingDrafts/EmbeddedDesktopFiles
- Accepted (5 - 0)
Other Discussions
The following additional items were discussed; see the logs for full details.
- Publican Documentation Package guidelines
- https://fedoraproject.org/wiki/Publican_Documentation_Packages
- The committee found several issues.
- Wordpress Plugin Packaging
- https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_%28draft%29
- Reception was generally positive, but the committee had a few questions.
- Meeting time
- A proposal will be floated to change the meeting time to a two hour block at 15:00UTC on Wednesdays.
IRC Logs
| *** spot sets the channel topic to "Fedora Packaging Committee". | 12:01 | |
| spot | rdieter, abadger1999, SmootherFrOgZ, tibbs: ping | 12:03 |
|---|---|---|
| tibbs | Howdy. | 12:03 |
| abadger1999 | pong | 12:03 |
| rdieter | yo | 12:03 |
| abadger1999 | apologies, I didn't get a chance to update the conflicts guidelines. | 12:04 |
| spot | well, racor said he wasn't coming due to the time change | 12:05 |
| spot | I don't see Rathann or delero | 12:05 |
| tibbs | The time is back to what is was previously. | 12:05 |
| spot | and I don't think SmootherFrOgZ is around | 12:05 |
| spot | i'll give it a few more minutes, but we do not have quorum | 12:06 |
| * SmootherFrOgZ is | 12:06 | |
| spot | aha! | 12:06 |
| spot | okay, great! :) | 12:06 |
| spot | first item: https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft | 12:07 |
| spot | ... but, abadger1999 hasn't had a chance to update them | 12:08 |
| * spot is awake, honest. | 12:08 | |
| abadger1999 | yeah | 12:08 |
| spot | okay, lets move on to the next item: https://fedoraproject.org/wiki/Publican_Documentation_Packages | 12:09 |
| spot | i'm not a huge fan of embedding .desktop files in the spec | 12:09 |
| tibbs | I don't have a problem with it. | 12:09 |
| tibbs | It is not uncommon to embed short source files in the spec. | 12:10 |
| abadger1999 | I've been talking with docs about this. there's really two parts. I don't have a problem with either. | 12:10 |
| * spot won't vote against it for that, but I think it makes the spec less manageable | 12:10 | |
| tibbs | I think it's a rather poor idea to embed the version in the package name, however. | 12:11 |
| SmootherFrOgZ | i also don't, but i'd prefer to manage it outside of the spec | 12:11 |
| spot | i think that abadger1999's suggestion at the bottom of the draft is preferable than exception casing it for Publican | 12:11 |
| spot | although, it is worth leaving the example in | 12:11 |
| tibbs | Do our guidelines actually forbid echo >> blah.desktop <<END in a specfile currently? | 12:12 |
| abadger1999 | tibbs: The justification for that is that the "Fedora 11 XXX Guide" is a different document from the "Fedora 12 XXX Guide" | 12:12 |
| spot | tibbs: i don't think so | 12:13 |
| tibbs | abadger1999: Just like gcc 4 is different from gcc 3. | 12:13 |
| abadger1999 | tibbs: Although docs is trying to convince the publican application authors to allow them to leave the version number out if they want. | 12:13 |
| abadger1999 | tibbs: Well... If you think of it as a book, it makes more sense. | 12:13 |
| tibbs | It doesn't really make more sense to me. | 12:13 |
| tibbs | A book can have a version, sure. | 12:14 |
| tibbs | But we have well-established method for dealing with things that have versions. | 12:14 |
| spot | do these packages conflict (diff versions of same manual)? | 12:14 |
| abadger1999 | It's not the book that has the version in this case... The book is about a different version of the software. | 12:14 |
| abadger1999 | (In our case, Fedora 11 vs Fedora 12). | 12:15 |
| abadger1999 | spot: No conflicts. They're meant to be parallel installed. | 12:15 |
| spot | will they actually be maintained across multiple branches in parallel? | 12:15 |
| abadger1999 | That's the idea (from the publican side). | 12:15 |
| tibbs | And they are making a promise to provide a new one for each Fedora release? | 12:16 |
| tibbs | Because when you name things that way, you're making an implicit promise. | 12:16 |
| spot | well... this is close to the "Multiple packages with the same base name", but not quite. | 12:16 |
| abadger1999 | The docs folks have agreed that they may want to do that for some packages (Like release notes and install guide) but want to talk the publican authors into going version-less for Security Guide and such. | 12:16 |
| tibbs | If you just have version 2 of the document, it doesn't imply any link to any particular Fedora version. | 12:17 |
| spot | I'm not really buying the OS version embedded in the name... | 12:17 |
| spot | we have the %{?dist} tag explicitly for that | 12:17 |
| tibbs | If you name the document after the Fedora version, then you get users who want the F13 version and not the moldy F12 version. Sort of like the problem we have with dist tags now. | 12:17 |
| abadger1999 | I've got a few docs folks coming over. | 12:18 |
| abadger1999 | jjmcd and ke4qqq. | 12:18 |
| abadger1999 | tibbs: I agree that it doesn't make nearly as much sense if we aren't making a new package for each new release. | 12:19 |
| spot | i'm just not sure what the value of having the Fedora10-HowToFooAndBar in the f-12 branch is. | 12:19 |
| spot | especially if there is also a Fedora11-HowToFooAndBar and Fedora12-HowToFooAndBar in the f-12 branch too | 12:19 |
| ke4qqq | spot: how about having Fedora12-howtofooandbar in the f-10 branch? | 12:19 |
| spot | ke4qqq: how could that possibly be useful? it would refer to changes that are not necessarily present | 12:20 |
| ke4qqq | which strikes me as more likely scenario | 12:20 |
| spot | it would be far useful to have a single version in each branch that is kept current and relevant for that branch | 12:20 |
| ke4qqq | it's possible that I am reading documentation on my local machine on f10 while getting ready to upgrade my machine or machines I manage | 12:20 |
| f13 | which you can easily do from the website | 12:21 |
| jjmcd | You don't see sysadmins who have more than one version on their network wanting to access documentation for all their boxes? | 12:21 |
| tibbs | It's not as if the other versions can't be online somewhere. | 12:21 |
| tibbs | The other thing is that we'll end up with the F10 version still around on F22 unless someone keeps remembering to get rel-eng to block the old ones. | 12:21 |
| tibbs | And they will sit around in CVS forever. | 12:22 |
| tibbs | It just doesn't seem to scale well to me. | 12:22 |
| ke4qqq | if we followed that to it's logical end then why would we have the documentation locally at all? | 12:22 |
| ke4qqq | the scaling and aging is a valid concern | 12:22 |
| spot | well, if Fedora docs is responsible for blocking old docs... | 12:23 |
| spot | perhaps it could go in one of the checklists | 12:23 |
| spot | my other concern is that I don't want the OS version embedded in publican docs just because they came out of publican | 12:24 |
| tibbs | It's just one more thing to do. I know we're not responsible for policy in that area, but shouldn't folks generally try to minimize that kind of thing. | 12:24 |
| spot | if the docs aren't Fedora distribution version specific, they shouldn't do that | 12:24 |
| spot | (this might be how it works now, but the guidelines seem to imply that all Publican docs have this behavior) | 12:25 |
| f13 | yeah, it seems like the reasons are just excuses for not fixing the publican flaw | 12:25 |
| abadger1999 | To me, these are packages of content. Which doesn't always fit the software-packaging model. | 12:25 |
| jjmcd | f13: I see both use cases, but honestly, I don't understand why Publican insists on the version number | 12:25 |
| abadger1999 | I'd rather the docs team had control over the "Should we package these docs that are specific/pretend to be specific to each release". | 12:26 |
| spot | abadger1999: i would prefer that to permitting all publican generated docs to have the Fedora version embedded in %{name} | 12:26 |
| abadger1999 | <nod> | 12:27 |
| spot | if docs wanted to maintain multiple versions of the same docs with the existing base name exception in NamingGuidelines, they could do so now | 12:27 |
| spot | e.g. HowToFooAndBar & HowToFooAndBar-Fedora11 | 12:28 |
| abadger1999 | So do we need any language at all? Perhaps just let docs know that there's no issue with having the Fedora Release number as part of the title/name of their doc but we think there's issues they might want to consider? | 12:28 |
| jjmcd | Most (but not all) of our docs are specific to the release, so it makes some sense to have the Fedora version in the name, but we also need to get Publican fixed for the other use case | 12:28 |
| f13 | well, one thing is that it'll break anything wanting to require "fedora-release-nots" | 12:28 |
| f13 | er "fedora-release-notes" | 12:28 |
| abadger1999 | jjmcd: Does that seem like a reasonable statement? | 12:29 |
| abadger1999 | f13: Virtual Provide? | 12:29 |
| jjmcd | Does anything do that? | 12:29 |
| f13 | anything requiring them, or putting them in comps, or kickstarts, etc.. will have to constantly edit them to embedd a version | 12:29 |
| f13 | abadger1999: which one wins? | 12:29 |
| abadger1999 | f13: Any :-) | 12:29 |
| f13 | it's a concern to consider. | 12:30 |
| spot | f13: yeah, i think that the current version for a branch should not have the version embedded in it | 12:30 |
| * abadger1999 checking repoquery | 12:30 | |
| spot | i don't have a problem with it doing Provides: FooBar-Fedora12 | 12:30 |
| spot | to me, it feels less like we're trying to document a valid use case and more like we're hacking around a broken tool | 12:31 |
| jjmcd | I think we have both going on, actually | 12:31 |
| spot | in all fairness, we've permitted guidelines to hack around broken tools in the past | 12:32 |
| ke4qqq | spot: that echoes a lot of the sentiment within docs as well, yet the use case, at least at first blush seems valid | 12:32 |
| f13 | we already have guidelines that allow for the broken behaviouir | 12:32 |
| spot | so there is precedent here, but I am reluctant to permit too broad of an exception | 12:32 |
| spot | If the documentation is really Fedora version specific AND the docs team feels there is a need to have multiple versions in the same branch, then and only then, they should be able to do so | 12:33 |
| spot | But as a general case, to simply permit all publican docs to be sloppy, no... i don't think so. | 12:33 |
| abadger1999 | repoquery --whatrequires fedora-release-notes | 12:33 |
| abadger1999 | fedora-release-0:10-1.noarch | 12:33 |
| spot | [spot@velociraptor sandbox]$ repoquery -q --whatrequires --alldeps fedora-release-notes | 12:33 |
| spot | lynx-0:2.8.6-20.fc11.x86_64 | 12:33 |
| abadger1999 | That's already a virtual provide, though. | 12:35 |
| spot | ke4qqq/jjcmd: does that statement make sense? | 12:35 |
| jjmcd | which statement | 12:35 |
| ke4qqq | spot: it makes sense - I almost wonder if we should be inferring that you want us to ask for specific documents/packages to provide exceptions to, rather than a general guideline | 12:35 |
| spot | "If the documentation is..." "But as a general case..." | 12:36 |
| jjmcd | yes, I think that is good | 12:36 |
| spot | Well, I'm not sure how we would setup the requests. | 12:36 |
| spot | We could change the text to something like: | 12:37 |
| ke4qqq | neither am I..... we'll be happy with the above dispensation I believe. | 12:37 |
| ke4qqq | at least as happy as we can be with the tool in the condition it is in. | 12:37 |
| jjmcd | Yes, I think it reminds us to get the tool fixed | 12:38 |
| spot | "Documentation packages (as approved by the Fedora Documentation SIG) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed." | 12:38 |
| spot | That opens the window a bit, but not so wide that trucks are driving through it. | 12:39 |
| jjmcd | Fedora Documentation Project rather than SIG | 12:39 |
| ke4qqq | perhaps s/SIG/subproject/ | 12:39 |
| spot | sorry. guessed wrong. :) | 12:39 |
| spot | "Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed." | 12:39 |
| jjmcd | Forgiven: You don't call it DocsProject 10 times a day | 12:39 |
| ke4qqq | worksforme | 12:40 |
| abadger1999 | I like that. Leaves the docs project in charge with a clear idea of when it is or is not appropriate. | 12:40 |
| jjmcd | Well Eric come lately | 12:40 |
| Sparks_Too | :) | 12:40 |
| spot | so, give me a second, I'm going to break this into two drafts | 12:40 |
| jjmcd | spot just now articulated the rule and we all agreed to sell the farm in your absence | 12:41 |
| Sparks_Too | jjmcd: You can sell the farm... just don't sell the ship. | 12:41 |
| spot | https://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming | 12:42 |
| spot | FPC folks, what do you think about it? | 12:42 |
| abadger1999 | +1 | 12:43 |
| abadger1999 | I like it. | 12:43 |
| SmootherFrOgZ | sound good to me | 12:43 |
| tibbs | So how many of these things are going to be dumped on the review queue every release? | 12:44 |
| * Sparks_Too takes a look | 12:44 | |
| tibbs | With some reasonable packaging guidelines they should be trivial to review, but the reviewers are increasingly over-over-overloaded. | 12:44 |
| abadger1999 | A related question would be -- does docs have the manpower to both package and review them? | 12:45 |
| Sparks_Too | spot: I'm not sure we have an approval process. | 12:45 |
| ke4qqq | abadger1999: yes | 12:45 |
| tibbs | The queue has grown by 50 packages in the last two weeks. | 12:45 |
| abadger1999 | Cool. | 12:45 |
| Sparks_Too | spot: What should we be looking at to approve? | 12:45 |
| ke4qqq | we'll take responsibility for reviewing docs produced stuff - we have enough packagers floating around to handle that sanely I think. | 12:45 |
| spot | Sparks_Too: if it were me, i would ask "is this documentation really version specific? is there value in having multiple releases in the same dist at once?" | 12:46 |
| spot | by version, i mean "OS version" | 12:46 |
| jjmcd | I think there is more value being able to install than having in the dist e.g. --enablerepo | 12:48 |
| jjmcd | Nice to install for example rawhide RNs without clobbering my current copy | 12:48 |
| spot | well, i'm content to defer that decision to Fedora Docs | 12:48 |
| spot | they're going to bear the majority of that burden anyway | 12:49 |
| spot | if it becomes unbearable, we can always revisit this | 12:49 |
| Sparks_Too | spot: Okay, I can do that. Should we look at anything else prior to submitting it for review? | 12:49 |
| spot | Sparks_Too: i suppose that is up to Fedora Docs. Of course, it needs to meet the rest of the Fedora Packaging and Naming guidelines | 12:50 |
| Sparks_Too | spot: I foresee a problem coming down the road. Each language is packaged independently. So that's going to mean a lot of packages hitting the review process within a short amount of time. | 12:50 |
| ke4qqq | yeah I was about to bring that up as well. | 12:50 |
| spot | Sparks_Too: each language is packaged independently? | 12:50 |
| spot | seriously? that's just broken. | 12:51 |
| Sparks_Too | spot: Yes | 12:51 |
| ke4qqq | another tool issue | 12:51 |
| tibbs | Oh, please no. | 12:51 |
| spot | yeah, i'm not going to let that slide. | 12:51 |
| Sparks_Too | spot: In RH the reasoning is so there aren't 200MB docs... | 12:51 |
| ke4qqq | I suspect it's a plot to dramatically increase fedora package count :) | 12:51 |
| Sparks_Too | being downloaded for just one language. | 12:51 |
| spot | learn about subpackages. | 12:51 |
| Sparks_Too | So you would be able to install a language versus a document. | 12:51 |
| Sparks_Too | If that makes sense. | 12:51 |
| abadger1999 | subpackage ++ | 12:52 |
| ke4qqq | right, single srpm, 35 rpms | 12:52 |
| Sparks_Too | ke4qqq: This is a RH thing and not a Fedora thing. | 12:52 |
| spot | subpackages should be fine | 12:52 |
| spot | 35 base packages would not be | 12:52 |
| Sparks_Too | spot: Okay, not familiar but would be. | 12:52 |
| Sparks_Too | s/would/will | 12:52 |
| spot | Sparks_Too: basically, think of how the openssl package generates openssl and openssl-devel | 12:53 |
| spot | it is just one package for review (openssl) | 12:53 |
| spot | HowToFooAndBar could generate HTFAB-en and HTFAB-de | 12:53 |
| Sparks_Too | spot: Okay... so would we need ALL the languages in the package before it is approved? | 12:54 |
| tibbs | No. You can just add a language once the package is in. | 12:54 |
| spot | Sparks_Too: nope. you can add subpackages as they are done. | 12:54 |
| spot | FPC, we're almost out of time | 12:55 |
| Sparks_Too | spot: Okay. That works for me. Our meeting is tomorrow so I'll bring it up then. I don't have a problem with any of this, just need to learn more. | 12:55 |
| spot | can we vote on: https://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming ? | 12:55 |
| spot | +1 from me | 12:55 |
| abadger1999 | +1 | 12:55 |
| SmootherFrOgZ | +1 | 12:55 |
| tibbs | +1 | 12:56 |
| spot | tibbs, rdieter? | 12:56 |
| rdieter | +1 | 12:56 |
| spot | okay, it passes | 12:56 |
| spot | next item: https://fedoraproject.org/wiki/PackagingDrafts/EmbeddedDesktopFiles | 12:56 |
| spot | that is the second half of the original Publican Draft | 12:57 |
| abadger1999 | .+1 | 12:57 |
| SmootherFrOgZ | +1 | 12:57 |
| spot | +1 | 12:57 |
| tibbs | I don't see why we need to talk about this at all. | 12:57 |
| tibbs | The language is fine, so +1 for that if folks really think we need to say something about it. | 12:58 |
| spot | tibbs: i think it was not clear to some people that this was permissable. | 12:58 |
| tibbs | I suppose because we mention SOURCE3 in the example and folks assumed that you couldn't just put a file name there? | 12:58 |
| SmootherFrOgZ | tibbs: :) | 12:59 |
| spot | rdieter: ? | 12:59 |
| abadger1999 | tibbs: Yeah, the original explicitly said include a .desktop file... If I was smarter, I would figure out how to remove the file/inline mention altogether. | 13:00 |
| rdieter | +1 | 13:02 |
| spot | okay, thats +5 it passes | 13:02 |
| rdieter | abadger1999: nod | 13:02 |
| spot | next item: https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_%28draft%29 | 13:02 |
| spot | this looks okay to me, with the caveat that if any wordpress plugins aren't noarch somehow, they'd need to be adjusted accordingly | 13:03 |
| spot | i know nothing about the format of wordpress | 13:03 |
| abadger1999 | This looked pretty good to me too. | 13:04 |
| abadger1999 | spot: ianweller was going to ask you about the licensing note in the spec file. | 13:04 |
| spot | I'm going to go ahead and vote +1 | 13:04 |
| abadger1999 | Is that okay? | 13:04 |
| SmootherFrOgZ | i'd just add a -p flag to cp, to keep timepstamp of some files | 13:04 |
| tibbs | It wasn't on the todo list so I need to read it. | 13:04 |
| SmootherFrOgZ | +1 | 13:04 |
| rdieter | +1 | 13:04 |
| spot | abadger1999: assuming they come from that repo, yes. | 13:04 |
| abadger1999 | +1 | 13:05 |
| spot | abadger1999: its loose licensing intent, but intent nevertheless | 13:05 |
| abadger1999 | Okay. | 13:05 |
| spot | tibbs: go ahead. | 13:05 |
| tibbs | So should I assume that the two wordpress variants can't change to just get their plugins from a common directory? | 13:05 |
| spot | tibbs: that would be logical, eh? :) | 13:06 |
| tibbs | SmootherFrOgZ: cp -a implies -p. | 13:06 |
| tibbs | Actually it implies -dpR. | 13:07 |
| tibbs | So I don't have a problem with this, but wouldn't it be prudent to at least ask the wordpress packagers if there's any possibility of a shared plugin directory? | 13:08 |
| tibbs | Maybe that's already been done; I'm not familiar with this issue. | 13:09 |
| abadger1999 | We could kick that back to ianweller to find out. | 13:09 |
| SmootherFrOgZ | tibbs: afaik, wordpress-mu is a bit different than wordpress, but we should ask wordpress folks or ianweller directly | 13:10 |
| spot | sure, lets do that | 13:10 |
| SmootherFrOgZ | abadger1999: nod | 13:10 |
| abadger1999 | I suppose it depends on whether the variants are in the process of diverging or converging. | 13:10 |
| tibbs | Well, the thing is that this guideline sort of assumes that they take the same plugins. | 13:10 |
| spot | especially given that the spec template shows it copying the files. :) | 13:10 |
| tibbs | If that's something that we know is going to change then it would be better to get it right now rather than having to go back to this guideline when things change later. | 13:11 |
| spot | we should ask ianweller whether there will be any divergent cases where the mu plugin is different from the normal wordpress plugin | 13:11 |
| spot | if not, then they should use a common dir | 13:11 |
| abadger1999 | I asked him that and he said theoretically but none yet. | 13:12 |
| tibbs | The other alternative is to make them search a common dir and then variant-specific dirs. | 13:12 |
| abadger1999 | <nod> | 13:12 |
| tibbs | Or the other way around; whatever. | 13:12 |
| tibbs | But that gets into internals which might not be easy to change. Best to at least ask about it. | 13:13 |
| spot | yeah, lets at least ask about it. if the answer comes back as no, we can probably vote over email | 13:13 |
| spot | okay, so that was the last item i saw on the agenda | 13:14 |
| spot | are there any other items? | 13:14 |
| tibbs | Do we want to talk about the meeting time, given Ralf's message? | 13:14 |
| tibbs | Have we ever succeeded in getting from him a time which would be better? | 13:15 |
| spot | i don't think so | 13:15 |
| tibbs | I recall asking but not receiving a response. | 13:15 |
| tibbs | Not much we can do about it, then. | 13:16 |
| spot | i think we'd have to go earlier, but we can't go too much earlier because abadger1999 is on US Pacific | 13:16 |
| spot | its a rather small window. :/ | 13:16 |
| abadger1999 | I can do it earlier than now (time change) | 13:16 |
| tibbs | My brain can't wrap around the time changes. | 13:16 |
| spot | abadger1999: two hours earlier? | 13:16 |
| abadger1999 | Right now we're starting at 10AM Pacific. | 13:16 |
| * abadger1999 makes hand wavy motions | 13:17 | |
| tibbs | Was the last meeting an hour earlier for Europeans or an hour later? | 13:17 |
| abadger1999 | Mostly I can do 8AM Pacific. | 13:17 |
| spot | tibbs: earlier, i think | 13:17 |
| abadger1999 | Unless my daughter misses the bus or similar. | 13:17 |
| SmootherFrOgZ | tibbs: earlier | 13:18 |
| spot | but we can't just go one hour earlier because of rdieter's kde sig conflict | 13:18 |
| spot | unless we change the day | 13:18 |
| spot | so we have to go two hours earlier | 13:18 |
| tibbs | KDE has said that they're flexible, but I don't want to try and push them around. | 13:18 |
| tibbs | It's unfortunate that it's worked out this way but I don't know what else we can do to accommodate Ralf. | 13:19 |
| spot | tibbs: can you send out an email to everyone proposing that we move to 1500 UTC on tuesday? | 13:19 |
| spot | see if anyone complains | 13:19 |
| tibbs | The other problem is that we frequently run over time. | 13:20 |
| tibbs | Currently we have nobody meeting after us. | 13:20 |
| abadger1999 | <nod> That is a great benefit | 13:20 |
| SmootherFrOgZ | so, could the best way be change the day ? | 13:20 |
| tibbs | We'd have to change the day and the time. | 13:21 |
| spot | maybe. go earlier and change the day | 13:21 |
| tibbs | Bugzappers is in this channel at 1500UTC. | 13:21 |
| tibbs | on Tuesdays. | 13:22 |
| tibbs | 1500 is free all other days. On Wednesdays, 1600 is free as well. | 13:22 |
| spot | yeah, we can't go earlier and not have someone after us | 13:22 |
| spot | but we could always move out into some other channel if we ran over | 13:22 |
| spot | (unless we went two hours earlier on wednesday) | 13:22 |
| tibbs | Well, we can take two hours on Wednesdays at 1500. | 13:22 |
| spot | i could do that | 13:23 |
| tibbs | That's the only day where that works. On Thursdays we can take 1.5 hours. | 13:23 |
| tibbs | But that puts us close to FESCo again. | 13:23 |
| spot | FESCo is friday | 13:23 |
| spot | they still would have two days, effectively. | 13:23 |
| tibbs | Yes, but we want more than one day between us and them. | 13:24 |
| tibbs | So Thursday is out but Wednesday is ideal. | 13:24 |
| tibbs | I'll propose Wednesday at 15:00 UTC. | 13:24 |
| spot | sounds like a plan. | 13:24 |
| tibbs | Would anyone who is here object to that? | 13:24 |
| * spot hears no objections | 13:26 | |
| spot | i also don't hear any other items for today, so i will close out the meeting | 13:26 |
| spot | thanks everyone | 13:27 |
| tibbs | I'm off for food. | 13:27 |
| SmootherFrOgZ | thanks all | 13:28 |