From Fedora Project Wiki

Meeting 20070318

Attending

  • entr0py
  • nirik
  • quaid
  • thimm
  • thl

Summary

  • Some discussions about the meeting time; seems to be quite important for some people to make sure the current main EPEL drivers can make the meeting; But Sundays on the other hand are bad for some people (especially people that might get payed for packaging stuff in EPEL) and we try to check for alternative times by using the wiki page: http://fedoraproject.org/wiki/EPEL/NewMeetingTime ; if you would be interested to join the SIG meetings times please fill that table out! tia!
  • RHEL5 on the builders -- there are some issues getting RHEL5 in place, but they hopefully sort out soon; the current plan is to use a merged tree for building (as agreed on in the past)
  • we probably need to split the repo up for different users like CentOS, RHEL5 Desktop (4 flavours afaics: Client, VT, Workstation, WOrkstation + VT) and Server (2 flavours) to make sure yum doesn't run into missing-dep situations; maybe this can be done with a yum plugin, needs to be investigated. Anyone interested to help? thl will look into this, but that might take some days as he has others things on this plate
  • thimm wants to allow kernel modules, but thl and nirik would like to avoid them for now
  • some discussions how to push packages to the different repos and tested pacakge to the stable repo ; it was suggested to use three repos:
  • stable -- main repo
  • stable-testing -- test packages there for a short time period before they get *moved* to stable
  • devel/testing/updates-nextrel -- packages get queued up here; this becomes stable with the next quarterly update

The current proposal works with just two repos and suggested to build packages for devel/testing (against the latest updates that might become the next quarterly update) and then build the pacakge anew for stable if everything looks fine

Please discuss on the list!

  • thimm urges to have a "Voting body & fesco mandate" (btw, we have a fesco mandate, but it's not actually clearly written down). thl will write something up and present it to the world and FESCo

Note: there are some takes on the schedule at http://fedoraproject.org/wiki/EPEL/Schedule that could need some help.

Full log

00:00            --- | thl has changed the topic to: EPEL SIG meeting
00:00 <         thl> | ping EPEL SIG members
00:00 <         thl> | who's around?
00:00              * | quaid is here
00:00              * | thimm is
00:00 <     entr0py> | bjohnson here
00:00              * | nirik is here.
00:00            --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule
00:01 <         thl> | hi everyone
00:01              * | kanarip is here
00:01 <         thl> | dgilmore mentioned it would be likely that he could not join us today
00:01 <       thimm> | :/
00:01 <       thimm> | Isn't he the only one that insists on Sunday meetings?
00:02 <       nirik> | yeah, sunday or off business hours during the week...
00:02 <         thl> | nirik, yes, something like that was what dgilmore wants
00:03 <         thl> | and even if someone asks for this is doesn't mean that he has free time each week ;-)
00:03 <       nirik> | true...
00:03 <       thimm> | So, how about we move the meeting time into the work week?
00:03 <         thl> | I pinged mmcgrath in #fedora-devel
00:03            --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- meeting time
00:04 <         thl> | thimm, well, "off business hours" in the US means probably middle of the night for us europeans
00:04 <       nirik> | thimm: where was the link to that wiki timeschedule page you made? I was meaning to look at it and add, perhaps we could see what time works best based on that?
00:04 <       thimm> | Isn't he down-under?
00:04 <       thimm> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:04 <         thl> | thimm, dgilmore? no
00:04 <       thimm> | But noone entered anything in there
00:04 <         thl> | he comes from down under iirc, but is in the US for some years now
00:05 <       nirik> | do we have any west coast people at all? perhaps we could use that time as well?
00:05 <       nirik> | (for now)
00:05 <       nirik> | yeah, I think he's in MN.us.
00:05 <         thl> | quaid, are you on the west coast?
00:05 <       quaid> | I am
00:06 <       nirik> | ah, sorry, thought there weren't any west coast folks. :) My mistake
00:07 <       quaid> | we used this to figure out likely slots for our far-flung FDSCo members:
00:07 <       quaid> | http://fedoraproject.org/wiki/BobJensen/MeetingTimes
00:07 <         thl> | well, I stated my preferred times on the list in https://www.redhat.com/archives/epel-devel-list/2007-March/msg00203.html
00:07 <       quaid> | each person put in their unavailability by their initial, and we looked for the ligthest coverage
00:07 <       thimm> | similar to what we did with FPC
00:07 <       quaid> | thl: right, we tried that for a while, but it failed to make it obvious when the best times were
00:08 <       quaid> | so, if passing ideas back and forth doesn't help, me may need a matrix like this
00:08 <       thimm> | See http://fedoraproject.org/wiki/Packaging/NewMeetingTime
00:08 <       thimm> | This is what I used as a template for http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:08 <       nirik> | I would prefer to have dgilmore around, since he is dealing with so much of the infrastructure, but most times are ok with me otherwise.
00:09 <       nirik> | thimm: sundays are usually bad for you?
00:09 <         thl> | nirik, +1, we need to make sure the certain key driers so far can join the meeting normally
00:09 <       thimm> | Yes
00:09 <       thimm> | Sundays seems to be bad for many people including @RH.com
00:09 <       nirik> | yeah, true...
00:10 <       nirik> | from dgilmore's email to the list: " It would need to be between 23:00-3:00 UTC  or 11:30-12:30 UTC or on the weekends."
00:10 <       thimm> | We'd like more participation from the enterprise world and people with jobs like to work on Mo-Fr
00:10            --> | che (Rudolf Kastl)  has joined #fedora-meeting
00:10 <         thl> | thimm, we fist need to lift of...
00:10 <       nirik> | thimm: agreed.
00:11 <       thimm> | thl: If we close doors, how will we lift off?
00:11 <         thl> | anyway, can somebody fill out http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what we know so far
00:11 <         thl> | then we can ask the others to put up their time
00:11 <         thl> | and then we can look further
00:11 <         thl> | thimm, it's not that bad currently
00:12 <         thl> | and those that showed most interested seems to agree on sunday
00:12 <         thl> | for now
00:12              * | thimm looks around
00:12 <       nirik> | I think we are left with sunday or not having dgilmore available at the meetings.
00:12 <         thl> | nirik, +1
00:12 <       thimm> | nirik: Or both like today ...
00:13 <       thimm> | I won't be able to make it on other Sundays
00:13 <       thimm> | This is my first Sunday I could make it anyway
00:13 <       nirik> | what about saturday?
00:13 <       thimm> | Well, weekends in general are bad, but Saturday early (in UTC speech) are the lesser evil
00:14 <       nirik> | perhaps we can propose that to dgilmore. Or just pick a weekday meeting time and move on.
00:15            --> | engwnbie (Leo Canale)  has joined #fedora-meeting
00:15              * | thl still votes that somebody that pre-fills http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what is publically known; then we ask others to add their info, and then we'll look at it next week
00:15 <       thimm> | It would make sense for everyone interested to fill out his own slots
00:15 <       thimm> | That's how it worked at the FPC
00:16 <       thimm> | Cross out what you can't attend and ++ the lsots you prefer
00:16 <         thl> | thimm, go ahead and to it
00:16 <       thimm> | s/lsots/slots/
00:16 <         thl> | thimm, somebody needs to start
00:16 <         thl> | so others know how it shall look like
00:16 <         thl> | add mine and dglimores times, too
00:16 <         thl> | and others will join
00:16 <       nirik> | in my case as long as it's not fesco and at times I am awake it's ok with me. ;)
00:17 <         thl> | let's fill out the form until next week and then look at it?
00:17 <         thl> | and move on now?
00:18 <       nirik> | ok
00:18 <         thl> | somebody just needs to start afaics
00:18              * | thl will move on
00:18            --> | glezos (Dimitris Glezos)  has joined #fedora-meeting
00:18            --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- RHEL5 on the builders
00:19 <         thl> | we have some issues getting RHEL5 in place
00:19 <         thl> | but they hopefully sort out soon
00:19 <       nirik> | I think dgilmore was working on that. ;)
00:19 <         thl> | dgilmore, yes, he and mmcgrath are working on it
00:19 <       nirik> | FYI, centos has a 4.92 beta out to test with...
00:19 <         thl> | the big problem is:
00:19 <         thl> | do we need one merged tree
00:20 <         thl> | or different ones for Client and server
00:20 <         thl> | I'd say:
00:20 <       thimm> | thl: OK, my part is done
00:20 <       nirik> | I think we agreed on one merged tree in the past. I think Client and Server would make things too complicated.
00:20 <         thl> | nirik, +1
00:20 <         thl> | nirik, neertheless we need to split stuff somehow
00:20 <         thl> | otherwise Client users will run into missing dep issues
00:20 <       nirik> | split how?
00:21 <         thl> | if a pacakge requires something from the server
00:21 <         thl> | split the repo into Client (Desktop, VT, Workstation, VT+Workstation) and Server
00:21 <         thl> | or use a yum plugin
00:22 <         thl> | that prevents that people run into missing dep issues
00:22 <       thimm> | yum plugin sounds nicer
00:22 <         thl> | thimm, +1
00:22 <         thl> | that's my plan, too
00:22 <       nirik> | yuck. Yeah, yum plugin would be better...
00:22 <         thl> | as we would hae just one repo
00:22 <       thimm> | It will deal with any furture layering of RHEL products, too
00:22 <         thl> | and centos users simply could use all
00:22 <       nirik> | but who is going to write it? :)
00:22 <         thl> | nirik, that's the problem...
00:22 <       thimm> | Well, is it really a plugin?
00:23 <         che> | thl, well but the plugin cant just ignore missing deps
00:23 <       thimm> | Maybe it is yum core functionality
00:23 <         thl> | che, we'd need to ship list of packages
00:23 <       thimm> | Like a switch to deal with missing/broekn deps
00:23 <         thl> | where we know that deps will be missing
00:23 <         thl> | well, or something like that...
00:23 <       thimm> | This switch would be usefull for rawhide as well
00:23 <         thl> | I'll try to look into this during the week
00:23 <         thl> | and post to the list
00:24 <         thl> | but well, if somebody else is interested in solving this I won't mind :)
00:24 <         thl> | is anyone?
00:24 <       nirik> | didn't someone post a list of packages that were just in server/client? I can't find the list now...
00:24 <       thimm> | I did on epel and rhelv5 lists
00:24 <         thl> | nirik, is more complicated then just server vs client
00:25 <       thimm> | Just grep for evolution in the body
00:25 <         thl> | nirik, there are different client versions
00:25 <       nirik> | thl: in 4, but not 5, right?
00:25 <       thimm> | thl: sure?
00:25 <       nirik> | 5 just has a since client/workstation I thought.
00:25 <       thimm> | thl: difference in premium etc is support, not content
00:25 <         thl> | only RHEL5-Client-Workstation for example ships PHP and eclipse
00:26 <         thl> | thimm, not 100% sure, but quite sure, yes
00:26 <         thl> | you have a isntall-number
00:26 <       nirik> | ah, found the list... it's pretty small...
00:26 <         thl> | you have to fill in during install
00:26 <         thl> | and that decides about the package set you can install
00:26 <       thimm> | I see
00:27 <       quaid> | are the "not available" packages not oon RHN for those install types?
00:27 <       thimm> | so one media, several outputs
00:27 <         thl> | well, as I said, I'll try to look at this closer during the week
00:27 <         thl> | thimm, yes
00:27 <         thl> | quaid, are they?
00:27 <       quaid> | I don't know
00:27 <       thimm> | Makes organisation quite messy
00:27              * | thl has no RHEL5 at hand ATM
00:27 <       quaid> | this is a bit unexpected thinking to me ...
00:27 <       thimm> | quaid: It wouldn't make much sense, or not?
00:27 <       quaid> | well
00:28 <       quaid> | from a support perspective, sure, if you have Server and call about Eclipse on it ...
00:28 <       quaid> | but does that mean there is no way to get the package?
00:28 <       quaid> | I'm thinking about  dep resoling in particular
00:28 <         thl> | let's stop here
00:28 <         thl> | and further investigate during the week
00:28 <       quaid> | and not being to replace packages i nthe distro, etc.
00:28 <       quaid> | ok
00:28 <       thimm> | If the install number prohibit installtion of eclipse from the media they should also do so from the channels
00:28 <         thl> | does that sound sane?
00:28 <       nirik> | yeah, I think further investigation would be good.
00:29 <       nirik> | I would really prefer to just have one repo per release of epel... otherwise it's getting very complex for maintainers.
00:29 <         thl> | nirik, +1
00:29 <         thl> | and for us, too
00:29              * | thl will move on soon if nobody yells
00:29            --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates
00:30 <         thl> | do we all agree on that this is the way forward?
00:30              * | nirik re-reads it again quickly
00:30 <         thl> | not much changed in the past week
00:31 <         thl> | actually, the changes since the initial posting were quite small in general
00:31 <       thimm> | I disagree on kernel module policy
00:32 <         thl> | thimm, suggestions please :)
00:32 <         thl> | this was discussed on the list, wasn#t it?
00:32 <         thl> | did you speak up there? (/me wonders if he missed that)
00:32 <       thimm> | I did
00:32 <       thimm> | And you replied
00:32 <       thimm> | But I still disagree :)
00:32 <       nirik> | kernel modules are a nice can of worms. I think we want to at least avoid them until everything else is up...
00:32 <         thl> | nirik, +100 :)
00:33 <       thimm> | Also: why rebuild packages?
00:33 <         che> | from a usability point of view i like the dkms approach
00:33 <         thl> | thimm, ?
00:33 <       thimm> | From testing to stable transition
00:33 <       thimm> | Doesn't that defeat any testing/QA done?
00:33 <         thl> | thimm, that's not written there afaics
00:34 <         thl> | the testing branch simply becomes the stable branch when the quarterly update happens
00:34 <       thimm> | "go to a testing branch for a short time period and then build a second time for the stable branch"
00:34 <       nirik> | yeah, shouldn't need to do that... since ABI/API should keep stable in minor releases of RHEL, right?
00:34 <         thl> | thimm, that's something different
00:34 <         thl> | that's more a: "updates-testing" meachnism
00:34 <         thl> | and only for those rare cases where updates to stable are needed
00:34 <       thimm> | Yes, and this should be rebuilt as well
00:35 <       thimm> | Otherwise the "testing" part gets reset
00:35 <       nirik> | isn't that more "there were problems in testing, so a new release was needed to fix them before pushing to stable" ?
00:35 <       thimm> | That's different
00:35 <       thimm> | If the package has a bug it needs to get fixed in testng
00:35 <       nirik> | agreed.
00:35 <         thl> | thimm, can you please outline your thoughts on the list
00:35 <       thimm> | And when the bugs are off move the final testing package to stable
00:35 <         thl> | I think that would be the better place
00:36 <       thimm> | Well, these are no "thoughts", just general pratice
00:36 <         thl> | thimm, don#t forget that packages in testing might get build agianst something else then the ones in stable
00:36 <       nirik> | thimm: I agree, perhaps we need to clarify the document in that?
00:36 <         thl> | stable=rh-latest
00:36 <       thimm> | thl: that should not happen
00:37 <         thl> | testing=rh-what-becomes-next-quarterly-update
00:37 <         thl> | thimm, let's move this to the list
00:37 <         thl> | it becomes to complicated here on IRC in my opinion
00:37 <       thimm> | thl: There are two concepts mixes up then
00:37 <       nirik> | The only time I would think that would happen is if there were several packages in epel that depended on each other and needed to be pushed at once.
00:37 <       thimm> | You want "rawhide" and "updates-testing" in one repo
00:37 <       thimm> | That won't wokr
00:38 <       thimm> | For development we need to separate them, just like FC does
00:38 <         thl> | development is fedora
00:38 <       thimm> | security and major bugfxies go to the "updates-testing"
00:38 <         thl> | security and major bugfxies go to the "updates-testing" +1
00:38 <       thimm> | Any the prepeation for quarterly go to epel's "rawhide"
00:39 <         thl> | no
00:39              * | thl stopps here, this doens't lead to anything
00:39 <         thl> | lets move it to the list
00:39 <       thimm> | Why?
00:39 <       nirik> | security and major bugfixes go to "updates-testing" for a short time only and then get pushed to fix the security/major bug, right?
00:39 <       thimm> | Yes
00:39 <       thimm> | W/o rebuilding
00:39 <       thimm> | Otherwise the QA gets lost
00:39 <       nirik> | the minor updates/versions just keep sitting in updates-testing until the next minor
00:40 <         thl> | I'd say with rebuilding
00:40 <       thimm> | Yes, but that needs to be a separate repo
00:40 <       nirik> | thimm: +1 to no rebuild.
00:40 <         thl> | at leat if we build against rhel-what-becomes-update soon
00:40 <       thimm> | E.g. one for quarterly long-term updates and one for near-term updates to the current minor
00:40 <       nirik> | updates-testing and updates-nextrel ?
00:41            <-- | engwnbie  has left #fedora-meeting ( "I'm Done")
00:41 <         thl> | thimm, then we'd need to have 3 repos
00:41              * | thl thinks that's to much
00:41 <       thimm> | Whch three?
00:41 <         thl> | that will fail just as updates-testing fail
00:41              * | thl repeats: let's discuss it on the list
00:41 <         thl> | we don#t understnad each other here
00:41 <       thimm> | Let's talk in FC naming:
00:41              * | thl votes for moving on
00:42 <         thl> | and reisiting this next week and on the list
00:42 <         thl> | revisit
00:42 <         thl> | stupid keyboard
00:42 <       nirik> | so for each release, say RHEL5... there is a "5" repo with main packages, stable, pushed out. A 'updates-testing' thats usually empty, but sometimes has major security/bugfix packages, and a 'updates-nextrel' that has the packge updates for 5.1 waiting in it.
00:42 <       nirik> | thl: ok.
00:43 <       thimm> | nirik: something like that, yes
00:43 <       thimm> | Where the two latter repo are consdiered our development repos
00:43 <       thimm> | Not development as in == rawhide, but development as in where we do QA and shape packages for the next quarterly
00:43 <       thimm> | Anyway, let's move on
00:44            --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- what else?
00:44 <       nirik> | right. I think thats all doable, and mostly autopmagically so maintainers don't need to mess with it too much.
00:44 <         thl> | anything else for today?
00:44 <         thl> | repotag?
00:44 <       thimm> | Voting body & fesco mandate?
00:44 <         thl> | thimm, was discussed last week
00:44            --> | ChitleshGoorah (Chitlesh GOORAH)  has joined #fedora-meeting
00:44 <         thl> | but we can bring it up again
00:44 <       thimm> | I'm sure it wasn't voted on ;)
00:45 <       thimm> | repotag, fedr-ausrmgmt etc need a final voting somewhere
00:45 <         thl> | sure, because we'd need to ask FESCo first how to set up a voting body
00:45 <       nirik> | thimm: so what are you looking for? voting on tech issues where there is no consensus?
00:45 <       thimm> | It's either the sig or fesco
00:45 <         thl> | and the fest members around just said "try to continue without a oting body"
00:45            --> | lancelan (Lance Davis)  has joined #fedora-meeting
00:45 <       thimm> | thl: we need to suggest something and get iot ratified
00:45 <         thl> | thimm, seems a lot of people disagreed last week
00:46 <       thimm> | Last week?
00:46 <         thl> | last meeting
00:46 <       thimm> | On this irc?
00:46 <       nirik> | I think repotag should fall under packaging...
00:46 <         thl> | nirik, +1
00:46 <       thimm> | Where less than half of the sig can participate?
00:46 <         thl> | the summaries get send to the list
00:46 <         thl> | so people can look at it
00:46 <         thl> | and yell if they don#t like something
00:46 <         thl> | nobody yelled
00:47 <       thimm> | That's not to be deducted into everybody agrees
00:47 <       quaid> | fwiw, we aren't near ready to be a formal project
00:47 <         thl> | thimm, see https://www.redhat.com/archives/epel-devel-list/2007-March/msg00210.html
00:47 <       quaid> | so it is SIG or nothing , afaict
00:47 <       nirik> | I would much rather get to some tech consensus than brute force voting on issues where everyone gets unhappy in the end.
00:47 <       thimm> | Well, every sig does have to make decisions, right?
00:47 <         thl> | thimm, "some discussion about steering issues that got discussed on the list"
00:48 <         thl> | nirik, +1
00:48 <       quaid> | right, a SIG can vote, can't it?  I mean, anyone can hjold a vote, unless they are somewhere they will get shot for doing it :/
00:49 <         thl> | quaid, well, yes, but who is allowed to vote
00:49 <       thimm> | So the N people mentioned on the SIg list already form a voting body, is that what you're saying?
00:49 <         thl> | that can quickly become confusing if people just join the sig just to be able to vote
00:49 <         thl> | and how many votes does something need to get accepted
00:49 <       thimm> | 50%
00:49 <       thimm> | >50%
00:50 <         thl> | to much
00:50 <         thl> | that will deadlock soon
00:50 <       thimm> | That's how voting works
00:50 <       nirik> | so this is all for fedora-usermgmt banning? or ?
00:50 <       thimm> | No, its for everything
00:50 <         thl> | I'd say a group that decides about how epel moves forward should be 5 or 7 people
00:50 <         thl> | not more
00:50 <       thimm> | Then make a suggestion and have fesco ratify the list
00:50 <       nirik> | well, what I mean is what "everything" do we need voting for now? aside from usermgmt?
00:51 <       thimm> | repotag?
00:51 <       thimm> | repo layout?
00:51 <       thimm> | guidelines?
00:51 <       thimm> | policies?
00:51 <         thl> | thimm, we just do it the "if nobody yells it's okay" way currently
00:51 <         thl> | and that was what FESCo members in the last meeting prefered
00:51 <       thimm> | Which means 100% consensus or people are not paing attention
00:51 <         thl> | and non-FESCo members, too afaics
00:51 <         thl> | thimm, yes
00:51 <       thimm> | That's not a healthy way of a project
00:52 <         thl> | it worked so far
00:52 <         thl> | sure, if we grow
00:52 <       thimm> | It depends on the view I guess
00:52 <         thl> | then we need a committee
00:52 <       thimm> | so how do you deal with disagreement?
00:52 <         thl> | we try to avoid it for now
00:53 <       thimm> | Discuss until RHEL6?
00:53 <         thl> | or move it to FESCo
00:53 <       thimm> | Burry it under the carpet?
00:53 <       thimm> | Oh fesco will be grateful for esalating any decision to them
00:53 <       thimm> | For example repotag
00:53 <       thimm> | I would agree that pushing it to FPc is the right thing to do
00:54 <       nirik> | well, I would prefer to avoid the overhead, but if you want voting on issues, how about: anyone with a EPEL package can vote... voting to take place on a wiki page somewhere on each issue?
00:54 <       thimm> | At least not w/o a preference form EPEL
00:54 <         thl> | thimm, just out of interest, what's your opinion on repotag?
00:54 <         thl> | nirik, that has other disadantages
00:54 <         thl> | okay, I'll write something up for FESCo
00:54 <       thimm> | I don't really care, I would like to see one, but I wopuld rather see it decided upon either way before it gets an infininte  thread
00:54 <         thl> | I'll of course send it to the list beforehand
00:55 <       thimm> | thl: thanks! :)
00:55 <         thl> | anything else?
00:55 <       thimm> | Off the meeting: How do I import all my packages to EPEL?
00:55              * | thl will be afk soon anyway
00:56 <       thimm> | (All but a few non-EPELizable)
00:56 <       thimm> | Can someone here do a mass branching for me?
00:56 <         thl> | thimm, I asked last week for people to write a script to simplyfy mass-branching in cvs
00:56 <       thimm> | Who's doing the branches for EPEL, dgilmore?
00:56 <         thl> | thimm, I'll do this script properly myself later as no one showed interest
00:57 <       nirik> | might be best to generate a list and mail cvsadmins@fedoraproject.org?
00:57 <         thl> | thimm, cvsadmins, that includes dgilmore
00:57 <       thimm> | OK, I will try cvsadmins, thanks
00:57 <         thl> | anything else?
00:57              * | thl will close the meeting in 30
00:58 <       thimm> | bye all!
00:58              * | thl will close the meeting in 10
00:58 <         thl> | -- MARK -- Meeting end