fesco
LOGS
17:02:15 <mitr> #startmeeting FESCO (2014-07-23)
17:02:15 <zodbot> Meeting started Wed Jul 23 17:02:15 2014 UTC.  The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:17 <mitr> #meetingname fesco
17:02:17 <zodbot> The meeting name has been set to 'fesco'
17:02:19 <mitr> #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones  sgallagh t8m jwb thozza kalev
17:02:19 <zodbot> Current chairs: abadger1999 dgilmore jwb kalev kylem mattdm mitr mmaslano nirik pjones sgallagh t8m thozza
17:02:21 <mitr> Hello everyone.
17:02:23 <mitr> Now that the election results have been published, do we want to apply the membership change to this meeting already?  Let’s see who is around first…
17:02:25 <mitr> #topic init process
17:02:31 <mattdm> hello!
17:02:32 <pjones> mitr: that's how it's worked in the past.
17:02:40 <thozza> hey
17:02:40 <kalev> hello everybody!
17:02:45 * nirik is only slightly around, but can try and follow things...
17:02:49 <mattdm> yeah let's make welcome new people as first agenda item?
17:02:52 <abadger1999> Hey everyone
17:02:54 <pjones> mitr: by which I mean: Sayonara, suckers!
17:03:06 <abadger1999> :-)
17:05:19 <t8m> hi
17:05:27 * jreznik is here for fesco :)
17:06:17 <dgilmore> hi
17:07:04 <mitr> Let’s get started then
17:07:13 <mitr> #topic Welcoming new FESCO members
17:07:51 <mitr> #info Welcome new FESCo members, Josh Boyer, Tomas Hozza, Kalev Lember!
17:08:16 <nirik> welcome indeed.
17:08:39 <kalev> hello hello
17:08:40 <nirik> and many thanks to abadger1999 aand pjones for their service.
17:08:45 <mattdm> yes, welcome and thanks!
17:08:49 <mitr> #info Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, for their service
17:08:49 <mattdm> and notting :)
17:09:01 * abadger1999 waves good bye :-)
17:09:04 <pjones> And kylem's week, right?
17:09:06 <dgilmore> thanks to all previous members :)
17:09:21 <mitr> oops
17:09:23 <mitr> #undo
17:09:23 <zodbot> Removing item from minutes: INFO by mitr at 17:08:49 : Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, for their service
17:10:09 <mitr> Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, Kyle McMartin for their service
17:10:16 <jreznik> btw. I sent erratum with correct terms information, sorry for mistake, it came from the ticket, elections announcement right up to the results email
17:10:17 <mitr> #info Thanks to the previous members Peter Jones, Toshio Kuratomi, Bill Nottingham, Kyle McMartin for their service
17:10:47 * mattdm takes responsibility for being wrong in the ticket. sorry!
17:11:15 <jreznik> one thing I did - updated the FESCo member list with terms people were elected for
17:11:29 <mitr> Since we have 2 members present both newly elected and departing, and given past practice, let’s continue with voting by the new members.
17:11:32 <jreznik> so it should be now much more visible/trackable
17:11:48 <mattdm> jreznik good call
17:12:03 * nirik updated the fesco list, let me know if I missed anyone
17:12:59 <mitr> #topic #1178 Fedora 21 scheduling strategy
17:13:01 <mitr> .fesco 1178
17:13:04 <zodbot> mitr: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178
17:13:50 <jreznik> so as stated in the ticket, we are not ready to freeze (as it was planned for this Tuesday)
17:14:04 <dgilmore> sadly I have to agree we need to slip, I think we are getting closer to resolving the issues
17:14:07 <jreznik> several issues, the most imporant is we even don't have full test composes available
17:14:18 <mattdm> it seems kind of like _far_ from ready.
17:14:25 <jreznik> so now the questoin is for how long
17:14:40 <kalev> as much as I hate to slip, I don't think there much choice here since the images are so much behind
17:14:56 <mattdm> Might we need to slip _more_ than two weeks?
17:15:05 <jreznik> to be honest, I agree with tflink 3 weeks with one week for Flock...
17:15:22 <jreznik> not to repeat f18 slipping by week when we already knew it's not enough
17:15:24 * dgilmore will be in Brno next week but the week after busy with Flock
17:15:27 * tflink is actually more for 4 weeks but 3 is better than 2
17:15:28 <thozza> I also agree with the concern pointed out in the comment #52
17:15:37 <thozza> (flock)
17:16:02 <kalev> one option might be to try and have 2 weeks unfrozen time between milestones, instead of the 3 unfrozen weeks we have now
17:16:26 <kalev> so we'd slip alpha freeze by three weeks
17:16:32 <kalev> but beta freeze only by 2 weeks
17:16:36 <tflink> as long as we don't repeat f18, that could work
17:16:36 <kalev> and final freeze only by 1 week
17:16:44 <mattdm> I feel like any attempt to squeeze future milestones is just lying to ourselves
17:16:51 <jreznik> yep
17:16:53 <mitr> Is the concern that we are in to bad a shape _now to freeze_, or that we _will be in a bad shape after the freeze_?
17:17:18 <mattdm> mitr we are definitely in bad shape now to freeze. I can't speak to the other.
17:17:28 <jreznik> mitr: the main concern is - it doesn't make sense to freeze and make it difficult for everyone when we know, we are not yet there
17:17:30 <mitr> i.e. if there were no Flock, would we be happy enough with moving the freeze to Aug 5?
17:17:52 <jreznik> mitr: I hope so, but with Flock, it's really 3 weeks
17:18:07 <mitr> jreznik: My point is really, that if we are _frozen_, there shouldn't be that many people we _need_ to work on the code so the impact of Flock shouldn’t be _that_ severe.
17:18:13 <jreznik> and I'd really like to avoid mangle with freezes for upcoming milestones now
17:18:27 <nirik> mitr: all our qa folks are very busy during freeze testing.
17:18:29 <mitr> (OTOH if everyone we need for the post-freeze work will be busy at Flock, then there is really no point.)
17:18:55 <mitr> nirik: Good point, and it’s QA asking for the extension.
17:19:03 <mattdm> I hate to see the overall schedule leaving halloween and landing on thanksgiving
17:19:46 <kalev> a bunch of Workstation key people are also going to be at Flock and can't help fix blockers if things come up
17:19:47 <jreznik> mattdm: we already made it on thanksgiving once, not ideal but
17:19:52 <mattdm> But, whelp, if we need the time, let's take it and make sure this comes out right.
17:20:01 <tflink> I'd hate to see another f18 more than I'd hate to see us slip the final release
17:20:03 <mattdm> we still have a slight margin left.
17:20:08 * mattdm throws salt over shoulder
17:20:19 <mattdm> tflink++
17:20:29 <jreznik> tflink: so January? :)
17:20:33 <tflink> the insanity around f18 is a great way to burn people out and lose contributors (in qa and releng, at least)
17:20:36 <mattdm> jreznik--
17:20:59 <tflink> jreznik: if the choice really came down to releasing in Januare instead of f18.next, yes
17:21:03 <jreznik> dgilmore: when do you expect you'll sort out compose issues?
17:21:17 <dgilmore> jreznik: no idea.
17:21:23 <mattdm> dgilmore: and is there anything that we can pull in more help on?
17:21:26 <dgilmore> I think i have sorted some of them this morning
17:21:34 <mattdm> it seems like a critical bottleneck....
17:21:43 <mattdm> (test composes, I mean)
17:21:50 <kalev> bcl might be able to help if it's the same livecd-creator issue?
17:22:16 <dgilmore> mattdm: the main issue right now is that things are randomly failing but when i run them to debug they work
17:22:17 <jreznik> yeah, without test composes, we can talk about x weeks slips but that means we don't have any data in hand and it's blind guessing
17:23:08 <dgilmore> 32 bit composes seem to be workinga gain
17:23:10 <dgilmore> again
17:23:22 <jreznik> good to hear
17:23:43 <dgilmore> they were failing for the last week
17:24:14 <nirik> perhaps we could push 2 weeks now, and revisit then before going into freeze?
17:24:29 <mattdm> dgilmore is there someway someone could help?
17:24:29 <dgilmore> nirik: thats okay by me
17:24:30 <tflink> what's the point of going into freeze the day before flock?
17:24:46 <dgilmore> mattdm: im pulling in people to help with the issues
17:25:13 <nirik> tflink: whats ever the point of freeze? to keep people from pushing in changes that don't fix blockers, stablize the tree
17:25:18 <mattdm> dgilmore: okay good. just making sure that you weren't feeling left on your own there
17:25:32 <nirik> now, granted many will be traveling and at flock and so wouldn't anyhow... but...
17:25:32 <dgilmore> mattdm: I am not
17:25:37 <jreznik> nirik: I think we have to go that way at least skipping flock
17:25:41 <tflink> nirik: sure, but freeze adds process weight and tends to annoy packagers
17:25:44 <mattdm> dgilmore cool
17:26:07 <dgilmore> mattdm: and once we have sorted out fedora.next composes ill be making sure that there is other releng folks capable of doing them
17:26:14 <dgilmore> so I am nota  bottle neck
17:26:17 <mattdm> I don't care (too much) about annoying packagers -- but I would  like the releng and qa people to be able to participate fully in flock without other obligations
17:26:30 <tflink> if a good chunk of the qa regulars aren't going to be testing until after flock, I don't think that our chances of hitting the alpha release a week after flock are very good
17:26:32 <nirik> tflink: sure... and it does mean there would be TC/RCs so people might feel like they need to test instead of being at flock
17:26:59 <mattdm> dgilmore Wasn't trying to call you one -- the composes themselves are the bottleneck
17:27:19 <dgilmore> mattdm: right
17:27:21 * nirik sees tflink's point. perhaps we do 3 weeks now and recheck then
17:27:32 <dgilmore> but I kinda am, and I dont want it to be so
17:27:42 <mattdm> +1 to nirik's proposal
17:27:47 <mattdm> dgilmore: *nod*
17:28:02 <jreznik> btw with two weeks and release on 18th, it means we would have like a three days for real work after flock
17:28:27 <kalev> I am for slipping the alpha freeze for 3 weeks if we slip now -- but can we make the unfreeze time between milestones 2 weeks instead of 3 to make up for some lost time?
17:29:31 <mitr> kalev: I don’t think historically that worked very well; people need time to install the test release and report bugs, and people need time to triage and fix bugs.
17:29:43 <mitr> But I don’t recall exactly when we last tried this.
17:29:45 <tflink> from a qa perspective, I'm not against the idea as long as you're flexible about extending that if it's needed
17:30:09 <nirik> mitr: I think it was f18... but we had... other problems then.
17:30:11 <tflink> entering freeze with badly broken stuff in the hope that it'll somehow get fixed in 2 weeks generally doesn't work all that well
17:30:56 <nirik> can someone mock out what kalev's proposal would be date wise?
17:31:04 * kalev tries.
17:31:19 * tflink doesn't care so much about when the dates are - more about making sure we have a snowball's chance of actually releasing 2 weeks after the freeze starts
17:31:34 <nirik> tflink: well, holidays and such need to be avoided.
17:31:49 <mattdm> I guess... does having a three week time mean people think "oh plenty of time" and do all the work in the last week anyway?
17:31:54 <tflink> nirik: true, I hadn't been thinking about that
17:31:55 <mitr> I suppose I’m +1 to nirik’s proposal (slip 2 weeks now, and reevaluate next week); if everything were in great shape next week, we won't need to slip too much—but we should be very ready to slip more.  (I’m not actually concerned about slipping a week at a time, at this point we don’t have any Change we would definitely keep slipping for unlike f18)
17:32:07 <t8m> I think 2 weeks unfrozen at least between alpha and beta is too short
17:32:23 <jreznik> mitr: I think nirik said 3 weeks
17:32:29 <kalev> nirik: this is how it would look with 2 weeks: http://fpaste.org/120222/06136711/
17:33:10 <mitr> jreznik: oh, right.  I missed the update.
17:33:47 <jreznik> kalev: one big note in the schedule file from poelstra is - don't try to play with milestones, just slip... we did it for f18 and it was mess in the end
17:33:53 <nirik> yeah, tflink talked me into 3. ;)
17:34:04 <dgilmore> ill go with QA
17:34:07 <mattdm> I'm +1 to 3 week slip, no built-in make-up time... I think trying to squeeze later just means we'll have to slip another time.
17:34:25 <thozza> I think it would make more sense to decide on the shortening once we get there and see how ready we are
17:34:43 <t8m> mattdm, +1
17:34:45 <mattdm> thozza: you mean unslip_ the schedule? that would be novel :)
17:35:27 <t8m> yep I don't see a big chance to do the unslip but we might try :)
17:35:27 <thozza> mattdm: I mean slip now after Flock, but leave the rest of the schedule (time period, not dates) the same
17:35:43 <jreznik> thozza: you can't do that!
17:35:58 <jreznik> thozza: ah, I understand - yes, it's the plan
17:36:48 <jreznik> so votes?
17:36:58 <mitr> So, formal votes on 3 week slip?  I count mattdm, t8m, unsure about nirik and dgilmore (please confirm explicitly)
17:37:08 <kalev> I am +1 for 3 week slip
17:37:26 <thozza> +1 for 3 week slip
17:37:28 <t8m> +1
17:37:29 <mitr> I’ll go with what QA asks for as well, +1
17:37:55 <dgilmore> +1
17:37:57 <nirik> +1 for 3 week slip
17:38:26 <nirik> we should make clear that in addition to not being ready for alpha freeze we also wanted to make sure flock wasn't a busy time for folks.
17:38:30 <mitr> #agreed Slip the schedule 3 weeks, per http://fpaste.org/120222/06136711/ (+7)
17:38:46 <kalev> nooo, undo this
17:38:57 <kalev> the fpaste above was a different proposal
17:39:00 <t8m> mitr, this is with the shortening
17:39:02 <kalev> with 2 weeks between releases
17:39:06 <mitr> #undo
17:39:06 <zodbot> Removing item from minutes: AGREED by mitr at 17:38:30 : Slip the schedule 3 weeks, per http://fpaste.org/120222/06136711/ (+7)
17:39:20 <mitr> #agreed Slip the schedule 3 weeks (+7)
17:39:41 <mitr> #topic #1322 Changes - Progress on Changes Freeze
17:39:43 <mitr> .fesco 1322
17:39:44 <zodbot> mitr: #1322 (F21 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1322
17:39:45 <mitr> There are no updates on this ticket; does anyone have a concern to discuss, or shall we move on?
17:39:57 <jreznik> mitr: ok, I'll update schedule and announce slip
17:40:16 <mitr> #action jreznik to update schedule and announce the slip
17:40:18 <mitr> jreznik: thanks!
17:40:39 <dgilmore> jreznik: cheers
17:41:09 <mitr> Moving on…
17:41:15 <mitr> #topic #1325 packagers doing dodgy things in review
17:41:17 <mitr> .fesco 1325
17:41:18 <zodbot> mitr: #1325 (packagers doing dodgy things in review) – FESCo - https://fedorahosted.org/fesco/ticket/1325
17:41:41 <kalev> so, I do think that package reviews are sometimes dodgy and people just set fedora_review+ without actually reviewing anything
17:41:53 <kalev> but in this case, I think it's all good and even better than in the average review
17:42:04 <kalev> two people were working on the package and reviewing each others changes and fixing actual issues the other found
17:42:13 <kalev> they probably didn't follow the package review process to the _letter_, but they definitely followed the _spirit_ of the process by having two people review each others changes
17:42:26 <t8m> I think the review was done but not exactly formally according to the process
17:43:15 <kalev> kwizart: we've had this so far: http://fpaste.org/120227/06137379/
17:43:16 <thozza> I think it was a little bit confusing, but not to the point that they deserve any kind of punishment
17:43:16 <t8m> So I definitely do not see a need to do any punishment against the reviewer+maintainer
17:43:26 <thozza> and there was also some misunderstanding
17:44:06 <dgilmore> there is no indication that the review was done
17:44:17 <dgilmore> that sources were verified
17:44:18 <mitr> t8m: well we don’t know because we don’t have the written record (pasted rpmlint etc.) we require precisely to know :)
17:44:21 <kwizart> kalev, thx for the spirit, indeed formalism is missing,
17:44:24 <dgilmore> that licenses were checked
17:44:36 <dgilmore> and that they switched like they did mid review is not okay
17:44:38 <nirik> I know we don't require checklists or anything, but it always makes me nervous when a reviewer says "looks ok, approved"
17:44:40 <dgilmore> we have policies
17:44:49 <mitr> dgilmore: IMHO switching is perfiectly OK if it is clear that it happened.
17:44:50 <dgilmore> the bug should have been closed and a new one opened
17:45:00 <mitr> dgilmore: the only think we actually require is pasting rpmlint, not any of the checklists that some people do paste.
17:45:29 <mattdm> I don't think we have ever mandated the fedora-review checklist
17:45:29 <mitr> (Which is kind of nonsense, but then we should be automating this instead of adding more manual steps, so…)
17:45:31 <dgilmore> mitr: right, there is generally some indication that a review was done
17:45:39 <t8m> mitr, +1
17:45:41 <dgilmore> in this case I do not believe it was at all
17:46:41 <mitr> So what now?  Ask for an explicit fedora-review checklist processing?  Ask them to find a third reviewer?
17:46:41 <kwizart> <dgilmore> the bug should have been closed and a new one opened, agreed, but why raising fesco about this ??? and not writting directly to me ?
17:46:59 <dgilmore> kwizart: because it was shady what was done
17:47:30 <kwizart> dgilmore, like when I'm reviwring the uboot patches ?
17:47:32 <dgilmore> mitr: I think at the least someone else should review the package
17:47:43 <dgilmore> kwizart: ?
17:48:02 * nirik thinks it was just miscommunication...
17:48:38 <kwizart> sorry for others eyes , but few days ago i've submitted an issue on uboot non-upstream patches added that broke my system
17:48:46 <mattdm> sooo, I think the missing thing is step 5 in http://fedoraproject.org/wiki/Package_Review_Process#Reviewer
17:48:47 <kwizart> I want to know if this is linked ?
17:48:57 <mattdm> "Include the text of your review in a comment in the ticket. For easy readability, simply use a regular comment instead of an attachment. "
17:48:58 <kwizart> And ausil is the maintainer
17:49:16 <dgilmore> kwizart: ausil is me
17:49:22 <mattdm> that doesn't mean pasting the fedora review, but at least some text assuring that the basics are covered
17:49:34 <kwizart> https://bugzilla.redhat.com/show_bug.cgi?id=1119741
17:49:55 <kwizart> yes we know who is ausil
17:49:57 <mattdm> soooo... proposal: new reviewer to make sure that is done in this ticket, and, gentle reminder to do that in the future?
17:50:10 <dgilmore> kwizart: all those patches were on their way upstrema
17:50:12 <dgilmore> upstrema
17:50:15 <dgilmore> upstream
17:50:22 <dgilmore> kwizart: and its off topic for this
17:50:33 <nirik> mattdm: +1
17:50:45 <dgilmore> mitr: +1
17:50:48 <kwizart> dgilmore, fait enought if you said i's offtopic,
17:51:08 <mitr> kwizart: we don’t do reviews of packaging after the initial review (regrettably?)
17:51:31 <mitr> mattdm: +1 (where “do that” is “do reviews in a documented transparent way",. not “always find a 3rd party if these two people meet in a review”)
17:51:45 <dgilmore> kwizart: we are talking about the package review not u-boot
17:52:01 <mattdm> mitr yes :)
17:52:50 <kwizart> dgilmore, fait enought if you said it's offtopic, it could have be a personal issue with me
17:53:23 <kwizart> same with xorg-x11-drv-freedreno, you have explicily removed my acl without any reason ?
17:53:28 <dgilmore> kwizart: its not an issue with you, though I do wish you would be open and talk about what it is your doing and wouldnt step on peoples toes all the time
17:54:09 <kwizart> quote ?
17:54:53 <thozza> kwizart: there was indeed no clear acknowledgement of successful review in the comment
17:55:22 <mitr> More votes?
17:55:49 <thozza> +1 for mattdm proposal with mitr's note
17:55:55 <kwizart> thozza, I agree with redoing the review, formalism was missing, I appologies, but I don't understand why this was raised to fesco
17:56:10 <t8m> +1 same as thozza
17:56:11 * mattdm is +1 to own proposal, including mitr's note
17:56:40 <thozza> kwizart: I see, however what's done is done. let's deal with it
17:56:42 <kwizart> if it's missing communication with ausil, I want to clear that
17:57:11 <mitr> #agreed new reviewer to make sure that is done in this ticket, and, gentle reminder to do reviews in a documented transparent way in the future (+5)
17:57:31 <mitr> kwizart, dgilmore: clearning that up seems like a great idea but let's not do it right here right now
17:57:55 <mitr> #topic Next week’s chair
17:58:15 <kwizart> ok I still needed to raised this point publicly, thx for your decision
17:58:18 <mitr> Actually, before that: kalev, thozza: Are you OK with this meeting time, or shall we do a new whenisgood round?
17:58:27 <kalev> mitr: works for me
17:58:59 <kalev> no idea about jwb though
17:59:04 <thozza> mitr: I doubt we can find better time that will suite everybody
17:59:14 <thozza> but can try
17:59:36 <mitr> OK, one more round won't hurt.
17:59:39 <mattdm> jwb often has dropped in on the meetings around this time (or at least when it was an hour later)
17:59:51 <mitr> #actinon mitr to send a whenisgood
18:00:34 <mitr> #info The next FESCo meeting will happen in the currently scheduled time, whenisgood results to apply starting the week after.
18:00:40 <mitr> Now, anyone to chair the next meeting?
18:01:19 <kalev> I'll be at guadec next week, might be missing from the fesco meeting because of that
18:01:50 <mattdm> I'm *really* trying to avoid any new commitments before flock :)
18:02:05 * thozza unfortunately wont be available next week at this time (traveling)
18:02:35 <nirik> I guess I could.
18:02:39 <t8m> I will be on holidays next week
18:03:10 <mattdm> are we even going to have quorum next week?
18:03:17 * dgilmore will be in Brno next week and not sure what exact availability he will have
18:03:23 <nirik> sounds like perhaps not
18:03:52 <mitr> So far 3 missing, so we could lose one more.
18:04:29 <mitr> #info nirik to chair the next meeting
18:04:33 <mitr> nirik: Thanks!
18:04:39 <mitr> #topic Open Floor
18:04:43 <mattdm> thanks niriik!
18:04:51 <mitr> Anything else to discuss today?
18:05:00 <kalev> anyone else going to guadec?
18:05:05 <mattdm> Should we change the fesco replacement policy permanently?
18:05:17 <mattdm> eg: in the event of open seats, we hold a special election?
18:05:52 <thozza> mattdm: sounds reasonable
18:05:58 <nirik> mattdm: perhaps. Might be worth a bit more thought than just doing it in open floor tho? file a ticket for next time?
18:06:23 <mattdm> nirik: okay, sounds fair
18:06:58 <kalev> and it might be good to discuss it with the fedora board first
18:07:16 <mattdm> kalev: sure
18:07:44 <jreznik> kalev: as the same could apply to board too (and famsco)
18:07:49 <kalev> yeah
18:09:24 <t8m> mattdm, this should be a decision of board, shouldn't it?
18:09:47 <t8m> mattdm, I think FESCo should not change rules of its own elections by themselves
18:09:52 <mitr> t8m: FESCo can come with the Board to a proposal that we think would be suitable, though.
18:10:04 <mattdm> t8m unclear. I think we can come up with a proposal
18:10:13 <t8m> sure we can
18:10:15 <mitr> t8m: (Historically FESCo predates the board so the rules are unclear but having the Board ratify seems reasonable.)
18:10:23 <mattdm> here, the intention is for it to be _more_ democratic, so I don't think there's any problem
18:10:55 <t8m> yep, but I'd like to see formal ratification by Board
18:11:19 <mattdm> t8m sounds good
18:11:49 <mattdm> https://fedorahosted.org/fesco/ticket/1326
18:11:56 <mitr> Anything else for open floor?
18:12:36 <mitr> If not, I’ll close the meeting in 2 minutes…
18:14:02 <jreznik> schedules are updated but I have to go now, I'll send announcement later today
18:14:40 <mitr> Thanks everyone!
18:14:41 <mitr> #endmeeting