Extras/SteeringCommittee/Meeting-20070308

2007 March 08 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Christian Iseli (ch4chris)
• Rex Dieter (rdieter)
• Toshio Kuratomi (abadger1999)
• Kevin Fenzi (nirik)
• Dennis Gilmore (dgilmore)
• Jesse Keating (f13)
• Warren Togami (warren)
• Tom Callaway (spot)

Absent

• Bill Nottingham (notting)
• Jeremy Katz (jeremy)
• Josh Boyer (jwb)

Summary

Closing fedora-extras mailing list

• FESCo approved the closing of the f-e-l. thl will will work on this.

Sponsor Nominations

• Jarod Wilson was nominated and accepted as new sponsors.

Packaging Committee Report

• FESCo approved the Packaging Committee's guidelines regarding:
• Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html
• http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs

fedora-usermgmt

• FESCo had a long discussion on this. RedHat BaseOS folks need to be involved. It is to late to have a solution for this by Fedora 7, will target Fedora 8.

Tracker Bugs

• The main blockers FE-NEW, FE-REVIEW, FE-ACCEPTED will be changed to flags.

Log

<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
<tibbs|h> I'm here.
<bpepple> Hey everyone, who's around?
* c4chris|w here
nirik is here.
<abadger1999> I'm here
<f13> I'm here
* f13 marks his calendar to remember this more often
* rdieter waves
<bpepple> Ok, let's start slowly...
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Jarod Wilson, nominated by Dennis Gilmore
<bpepple> I noticed quite a few '+1' for Jarod on list.  Any here have a problem with making him a sponsor?
<nirik> +1 from me... anyone who can do a pretty good job dealing with the mess that is beryl gets my vote. ;)
<bpepple> +1 here also.
<rdieter> +1
<c4chris> +1
<tibbs> +1
<abadger1999> +1
<cweyl|work> nirik: good point :)
<bpepple> Ok, I don't see anyone giving a '-1', so Jarod is a sponsor in my opinion.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- closing fedora-extras list
<bpepple> thl mentioned on the mailing list that he wanted FESCo to give a vote on whether to close the f-e-l list.
<f13> +1 to closing, once we fix all the automated reports that go there
<bpepple> +1 here also.
<rdieter> f13: +1
<c4chris> closing +1
<nirik> +1, yeah, need to make sure the reports all go to devel or whatever.
<cweyl|work> will we be automagically subscribing those on -extras but not on -devel to -devel?
<tibbs> Please no automatic subscriptions.
<nirik> no. Possibly we could invite them?
<thl> cweyl|work, mailman inites was the plan (see the list discussion)
<abadger1999> tibbs: +1
<c4chris> yes, invite
<cweyl|work> thl: ok, cool.
<tibbs> Best to just send one announcement and let people deal with it if they want.
<f13> tibbs: an invite helps, it's reasonable IMHO
<bpepple> thl: I don't see anyone in favor of keeping f-e-l open, so consider it approved.
<nirik> ok, so who can do this? someone in infrastructure ready to drive it forward?
<thl> bpepple, thx
<thl> nirik, I'll poke the neccessary people
just remind me if I'm to slow
<nirik> thl: excellent. Thanks.
--- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm -- https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
<thl> nirik, I need warren first, as he is the list admin for fedora-devel
<tibbs> Speak of the devil.
<thl> tibbs, :)
<nirik> thl: also, can you mail mschwent about the reports? might also mention to him that we should like to see them on every push?
* warren adds this channel to auto-join
<f13> warren: can you do the auto-invite of all folks currently on fedora-extras and point them at fedora-devel ?
<thl> warren, you were traveling atm, or am I wrong with that?
<warren> thl, I got extremely sick while traveling and went home yesterday.  I'm a bit worse today.
<thl> warren, k, it's not urgent; ping me please when you are okay again adn have some spare minutes
<thl> bpepple, I'd say move on please
<bpepple> thl: np
<warren> thl, what do you need?
<thl> warren, we need to discuss some details for closing fedora-extras-list
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process - Tracker Bugs -- warren
<abadger1999> not sure about garbage collecting.  It's certainly desirable to inform people of unmaintained software but I don't know if we actually want to remove it.
<warren> thl, ah, ok that can wait.
<thl> but we don#t have to do that now; it's not urgent
--- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm -- https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
<bpepple> abadger1999: agreed.
<nirik> yeah, the garbage collection package has upsides and downsides.
<thl> nirik, agreed
<nirik> we don't want to remove people's locally installed or other repo packages. Thats evil.
<thl> but doing something IMHO is better then doing nothing in this case
<cweyl|work> I'd definitely be irked if I upgraded a box and suddenly a package I was using "disappeared".  I can only imagine what an end user would think...
<thl> then a yum plugin would be best afaics
<rdieter> cweyl: even if that package is orphaned and/or no longer maintained?
<cweyl|work> (just my $0.02)
rdieter: yes.
<thl> rdieter, +1
* c4chris is afraid the garbage collector package is a great opportunity to shoot oneself in the foot...
<cweyl|work> c4chris: it's a great way to shoot other people in the foot, as well :)
<c4chris> yes
<rdieter> I'd be more afriad of having orphaned packages myself, but that's just me.
<thl> rdieter, +1
<f13> I really don't like the garbage collector idea as a package.
<nirik> how do other distros deal with this?
<f13> yum list extras + some local thought on what to do with it.
<thl> anyway, if it's disliked let's ignore it
but I'd like to see the problem solved...
a yum plugin would be ideal, but I have no time or skills to write it atm
<rdieter> fwiw, I like it (for lack of a better solution)
<warren> think about what anaconda does
<cweyl|work> rdieter: if the package still works, I don't really care if it's maintained or not.  if I did, I'd either go maintain it or figure out some other way to achieve what I needed...  but I don't like the idea of a package going away just because someone else has decided I don't need it anymore
<f13> I don't like the idea of removing somebody's software just because we no longer ship it
<warren> wouldn't people be upset if anaconda removed things during an upgrade that broke deps?
<nirik> the one that I had recently is bmp-xosd... bmp is no longer shipped, so I disabled that subpackage, but now people with it installed get a broken dep on upgrade. Should I add a Obsoletes?
<f13> doesn't mean they don't want to keep using it.
<nirik> anaconda just ignores those right?
<warren> forcefully ignores
<rdieter> and now you may have broken deps, yuck.
<bpepple> Maybe some kind of plugin that notified users of packages that weren't being maintained?
<f13> bpepple: yum list extras
<nirik> bpepple: yeah, that could get nasty depending on the interface tho.
<rdieter> bpepple: sure, but what about *now* until such a mythical plugin exists.
<nirik> as a small step, perhaps logwatch could add a 'yum list extras' report... but I bet most users don't read logwatch reports.
<thl> "package-cleanup --orphans" does most of the stuff we need
<thl> maybe we could steal some ideas there?
* warren sees this as bordering on the lunatic requests of people wanting the ability to upgrade when deps are broken.
rdieter didn't know about package-cleanup --orphans (cool)
<thl> or for now: tell users to run it before and after a big dis update?
s/dis/dist/
<c4chris> I like that much better
<nirik> what package is that in? yum-utils?
<thl> c4chris, well, but it doesn't solve the problem at hand
nirik, I think so
<f13> well, there are problems with that
<cweyl|work> thl: I'm still not sure that it's an actual problem :)
<f13> it'll whack anything it doesn't find in your configured repos, so anything you've hand installed... boom
<cweyl|work> (it == orphaned packages installed on someone's system)
<thl> cweyl|work, it seems it is one for a lot of people...
cweyl|work, maybe it would be less a problem if the yum errors would be easier to interpret
<nirik> if those packages break, users get mad, report bugs which are ignored.
<f13> thl: somehwat nature of hte beast doing continual upgrades vs fresh installs.
* thl fears that skvidal will show up and say "send patches"
<cweyl|work> thl: and the other way for others :)  I might feel more comfortable if it were optional.
<skvidal> errors easier to interpret?
<thl> f13, sure
<skvidal> what errors?
<f13> skvidal: I'm assuming broken deps due to orphaned package
<warren> Both anaconda and yum refuse to choose what to do about this, which is probably wise?  (Except anaconda and yum refuse in different ways.)
<cweyl|work> e.g. this hypothetical "orphan death package/plugin" isn't required by any base package on any system, so it can be removed easily.
<nirik> so, bottom line is that a fedora-orphans package doesn't seem like something we want now without a lot more thought... so perhaps we shoudl move on?
<cweyl|work> nirik: +1 for more thinking :)
<f13> cweyl|work: I'm strongly against using a package for this.
<thl> skvidal, if a yum updates fails because locally installed package foo was in f6, but is not in f7 anymore, and you aborts because foo has a dep that is not fullfilled by f7
<cweyl|work> f13: you won't get an argument from me :)
<f13> cweyl|work: UI in add/remove software and/or yum to show you orphans and let _you_ decide what to do with them is best IMHO
<thl> skvidal, even I get sometimes confused by the yum output
skvidal, but afaics it's actually the putput from rpm
<bpepple> f13: +1
<skvidal> yes, it is
<cweyl|work> f13: +1.
<nirik> f13: yeah, perhaps in anaconda too someday for upgrades?
<c4chris> f13: +1
<bpepple> Ok, we should probably move on, since this is going to need more discussion.
sgtpepper has quit ("switching from wireless to cable...")
<f13> nirik: maybe, but that would require kickstart love to do SOMETHING non-interactively
<nirik> good point. need a 'remove orphans' or 'ignore orphans' flag perhaps? anyhow, talk for another day
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process - Tracker Bugs -- warren
<thl> nirik, the problem is that somebody needs to code the stuff; and I see nobody doing this
* thl will stop now; new topic
<f13> nirik: thl probably should be driven through yum-devel and anaconda-devel lists.
<thl> f13, agreed
<bpepple> warren must have stepped away.  moving on....
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<tibbs> Did everyone see the summary?
<abadger1999> tibbs: Thanks a bunch!
<bpepple> tibbs: yup, thanks for the summary.
* rdieter thanks tibbs for taking one for team by volunteerting to do summaries. (:
<nirik> yeah, thanks tibbs.
<bpepple> There were two items I believe we need to vote on ratifying today.
<tibbs> So there are two issues up for ratification.
Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html
Not much there, really.
<bpepple> +1
<nirik> +1
<dgilmore> +1
<rdieter> +1
<f13> +1
<abadger1999> +1
* f13 notes that this is about how to package them, not whether or not they shoudl be packaged.
<f13> Fedora board decided they should, so we just have to define how.
<warren> +1
<tibbs> f13: Yes, the PC doesn't want to wade into that quagmire.
<f13> indeed
<tibbs> If anyone has any comments about the proposal, please let us know before next Tuesday, when this will get written into the guidelines.
Next was this: http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs
Disallowing %config under /usr.
I'll quote the entire proposal:
Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora.
<nirik> +1 from me... it does affect a merge review I am currently doing, but I think it's the right thing to do (a2ps) ;(
<abadger1999> +1
<bpepple> +1, seems reasonable to me.
<rdieter> +1 (though kde is currently borked wrt this)
(though fixable)
<dgilmore> +1 as long as kde is fixed
* bpepple is clueless when it comes to kde.
<f13> +1
<tibbs> I think everything is fixable with symlinks at least; that's rather ugly, but most of PC thinks %config in /usr is uglier.
<c4chris> +1
<warren> How does that effect upgrades?
(replace file with a symlink)
<rdieter> it's the replace dir's with symlinks that get ugly.
warren: file  <-> symlink isn't a problem.
<tibbs> I think an rpm expert should answer that question; I'm not one.
In any case, symlinks are just one solution.
<warren> I replaced some files in squirrelmail with symlinks to move configs out of /usr before.
There were no complaints.
But I also suspect there are no users. =)
+1
<tibbs> So I suppose if there are dissenting opinions or finds something that would hold up implementation of this guideline, please let fedora-maintainers know so that PC can address it.
<bpepple> tibbs: thanks.
<tibbs> Those were the only guideline proposals.
Of interest, PC will hold its meetings in this channel starting Tuesday.
And #fedora-packaging is gone.
That's about it.
<bpepple> tibbs: cool.  what time do you usually meet?
<tibbs> I have to convert to UTC...
<rdieter> Tue 17:00
<warren> BTW, is the perl-devel thing something we should discuss?
It seems controversial.
<abadger1999> 9AM Pacific Time... It was Daylight savings adjusted.. But I don't know now that the US has changed its DS laws...
<f13> warren: not really relavent here yet
<tibbs> Crap, that's right; we need to decide if the meeting time stays at 1700 or shifts an hour to deal with US DST.
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- fedora-usermgmt?
<tibbs> I hate DST.
<bpepple> Is this really something for FESCo right now?
<warren> fedora-usermgmt upsets people, but he's the only one actually trying to solve the problem.
* nirik wonders now that warren is back around if we should go back to the flags item to deal with it?
<abadger1999> warren: +1
<warren> If people don't like fedora-usermgmt, could we PLEASE figure out a real and standard solution?
* thl wonders why this topic is EPEL specific
<thl> it seems to be a general problem afaics
<tibbs> I don't want to wade into the usermgmt debate, but I do wonder if there's some easy way to just remap users post-installation.
<rdieter> thl: +1
<bpepple> thl: it's not, I just threw it there so I would remember.
<thl> yes, EPEL brought that topic up, but it should be soled for Fedora and EPEL
<thl> bpepple, k :)
<warren> We don't have to figure out usermgmt today, but we have to stop ignoring it.
<thl> warren, +1
* rdieter thinks we should just ignore those who are complaining... (:
<thl> I'd say build a group of people that work out a solution
<bpepple> thl: +1.
<thl> I#d say those people that are complaining about it should do that
<warren> thl, that worked well for kernel module standards. =(
<thl> warren, kmods work for a lot of people
<warren> *CORE* (or whatever becomes of it) must have a standardized usermgmt solution shipped by default
<thl> it's not perfect, but they work
<warren> it has to be ratified and used
or people wont accept it
* nirik uses it in one of his packages. I really don't care either way, but we need a standard here.
<thl> nirik, +1
<c4chris> yes
<abadger1999> We have to have something like it.
<rdieter> Is there anyone willing to drive the issue, and a solution?
without a driver, this car is going nowhere fast.
<bpepple> rdieter: agreed.
<thl> rdieter, +1
<abadger1999> Who here has the biggest problem with fedora-usermgmt?
<warren> We need to communicate 1) what is the problem?  2) what negative effects are there of ignoring it?  3) what exactly the solution entails
And it shouldn't be called fedora-usermgmt.
<abadger1999> :-)
<warren> It should just be a standard part of the distro.
<f13> abadger1999: mmcgrath and thimm seemed to
<thl> rdieter, thimm seems to really dislike fedora-usermgmt, but seems he doesn't want to have that job
<rdieter> thl: and he *still* doesn't understand why it exsits or how it works. ):
<abadger1999> And thimm doesn't see value in static assignment at all....
<thl> rdieter, :)
<warren> Could we have FESCO at least agree that we have to stop ignoring this?
<rdieter> warren: and do what exactly?
<warren> And the base distribution should provide this kind of functionality as a standard?
<nirik> yes, we need a standard. We could push it to the packaging folks? :)
<warren> The exact implementation details have to be discussed.
If people aren't willing to discuss it, then whoever works on it gets to decide.
<rdieter> warren: ok, +1.
<c4chris> standard +1
<bpepple> warren: +1 to a standard.
<f13> and we should get Red Hat's BaseOS group involved since it would affect many of those packages which add users.
<thl> nirik, +1 for the packaging folks ;-)
f13, +1 as well
<warren> f13, nod
<rdieter> f13:++
<warren> f13, maybe we could even assign driving to one of them =)
<nirik> f13: agreed. Are some of them likely to have more time soon when 5 is out the door?
<f13> nirik: hopefully.
<dgilmore> +1 from me
* f13 looks at RHEL4 and RHEL3 update releases...
<f13> I have to step away for a moment.
<warren> f13, I'll talk with my manager and see if there are any obvious ways to drive this in baseOS.
<tibbs> This goes all the way to the installer (which will need to allow configuration of this stuff before package installation) so many people will need to be involved.
<f13> man, I really hope we don't have to ask the user a questiona bout this.
<warren> The end result wont be called fedora-usermgmt.
<nirik> I'd be ok with a static mapping, or with more configurability with useradd or whatever, we just need everyone to have to use the same thing.
<warren> It should have known defaults that doesn't require asking the user.
<f13> any such systme should have a reasonable default and just use it, letting "experts" override the reasonable default somehow.
<warren> f13, +1
<nirik> agreed.
* warren goes to talk to his manager.
<bpepple> ok, so does this go to the packaging committee to be worked on?
<nirik> so, who is driving this? warren? packaging folks? mailing list?
<abadger1999> bpepple: No.
<bpepple> abadger1999: who should be driving this then?
<warren> we need multiple people buying in
<abadger1999> If it's going to be incorporated into baseOS then packaging committee needs to stay hands off for a while.
<nirik> yeah, but if we want it to go anywhere we need a few people or a person to push for it to happen, right?
<rdieter> abadger1999: as long as the proposals are brought by baseOS folks, it should be ok.
* spot is more than content to let someone else step on this landmine
<nirik> perhaps mmcgrath would like to? He doesn't like the current solution, but understands it? :) mmcgrath ?
<mmcgrath> buhh,
<abadger1999> rdieter: +1.  I'd be very happy if they brought the solution to the table.
* mmcgrath reads up
rdieter see's the quote of the week, mmcgrath: buhh,  :)
<mmcgrath> heh :)
is there no way to make fedora-usermgmt transparent?  IE not in the specfile in any way?
<thl> mmcgrath, is the specfile overhead really problematic?
<mmcgrath> thats where my issue with it is.
and thats where the EPEL issues are as well.
<abadger1999> So warren, do you think you can get feedback on whether there's someone within the base OS engineers that will commit to pushing this forward by next week?  Or have some idea of timeframe?
<tibbs> Make useradd consult a table of suggested uid assignments.
<mmcgrath> if part of the install process was "copy fedora usermgmt to /usr/sbin/useradd" we'd be all set
<warren> abadger1999, already talking with my manager about this
<abadger1999> Cool.
<mmcgrath> I'm glad to help with what needs to be done but I think I'm a bit too emotional with this particular topic to be honest.
perhaps too passionate, I just think without full integration it feels like a hack.
<bpepple> Ok, maybe while warren is talking to his manager we should move on.
<rdieter> bpepple: +1
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<bpepple> any other items people want to discuss?
<abadger1999> bpepple: Do we want to go back to tracker bugs now?
<dgilmore> did the sponsor vote happen?
<rdieter> how long should cvsadmin branch requests take (2+ days?). (:
* dgilmore was late
<nirik> I haven't done anything on the SponsorResponsabilities or the Roadmap for release cycles. ;)
<bpepple> dgilmore: yes.  Jarod was approved.
<dgilmore> rdieter: not that long
<dgilmore> rdieter: ill get onit when i have lunch soon
<rdieter> I'm still waiting (unless I did something wrong): http://bugzilla.redhat.com/230071
<nirik> warren: if you are still there, can we do the discussion about the cvs flags? would be very nice to get that done and solved...
<rdieter> dgilmore: thanks, np.
<bpepple> abadger1999: Yeah, but since warren was driving it, didn't make much sense to talk about while he's away.
<warren> i'm here
<warren> what is the issue with cvs flags?
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora - Tracker Bugs
<dgilmore> warren: i dont think the admins get all the emails
<nirik> sorry, tracker bugs.
should we get someone to replace all of them with flags? or only some? or leave them all as they are?
<warren> ah
hm
Since the migration turned out to be fully a one-to-one mapping, do you see any theoretical issues in an auto-migration that didn't send mail?
<nirik> c4chris: do you have thoughts? since you deal with them for your status report?
<warren> dgilmore, I haven't seen any signs of not receiving flag e-mails
<c4chris> not really
<nirik> I'd be ok with changing them all if it can be done without 2billion emails. We still need NEEDSPONSOR and DEADREVIEW, but the rest go away? or even deadreview?
<warren> dgilmore, are you sure your filters aren't hitting and throwing into other folders?
<c4chris> I'm fine if they are gone
<dgilmore> warren: its possible
<warren> NEEDSPONSOR and DEADREVIEW are small enough to keep
<tibbs> DEADREVIEW should be fedora-review ="-", shouldn't it?
<c4chris> the troublesome bit is how to get the approval date for packages...
<warren> tibbs, I thought so
<c4chris> tibbs: yes
<warren> c4chris, we have the approval date for packages now?
<c4chris> warren: not exactly, it's just the date of last change for the ticket...
<nirik> can you get flag change time?
<tibbs> Can flags have more states than ? + - and " " ?
<c4chris> which will all change if we remove the blocker on all those tickets...
nirik: dunno
<spot> Legal needs to stick around.
<warren> (Regarding usermgmt, it is too late for fedora 7, so we should target a standard in base OS for Fedora 8?)
<nirik> tibbs: yeah, but a bunch of the merge reviews are in - now from when the procedure was to set that to get the maintainer to do something.
<c4chris> nirik: but I'd like to know
<warren> tibbs, no more states are possible
<tibbs> nirik: Those should be easily fixable.
<warren> flags can optionally be assigned to specific people, but we haven't used that anywhere yet.
<nirik> you can query on 'flag setter'
<warren> If you can think of a good reason to use assign to specific person, we can try it.
<tibbs> warren: It's unfortunate that flags have only four values.
<c4chris> can we get flags in column output in any way ?
<tibbs> It would make more sense for them to have real textual values.
<nirik> anyhow, we can look at that at some point... are we agreed to change all the blockers to flags?
<warren> The main blockers anyhow
FE-NEW, FE-REVIEW, FE-ACCEPTED?
<bpepple> warren: +1
<tibbs> First we must change '-' to '?' as appropriate.
<nirik> yeah, +1 on those.
<tibbs> Or at least if we want to deal with DEADREVIEW, I guess.
<warren> tibbs, unless the reviewer gave up, then it should go back to blank
<nirik> there are currently 52 merge reviews in -
<warren> Regarding the merge reviews, I think we should clearly communicate a realistic policy at this point.
Merge Review is not a gatekeeper into Fedora 7, but just a cleanup sweep.
The cleanup will continue toward Fedora 8.
<rdieter> warren: +1
<bpepple> warren: agreed.
<tibbs> Definitely.
<c4chris> sure
<warren> f13, should the Merge Review cleanup stop at test4?
<tibbs> We're making progress, but any pre-F7 goal is just hilarious at this point.
<nirik> well, either we need to agree to release f7 with core/extras in diffrent VCS'es or we need to agree that all of them aren't going to be reviewed and just merge them at some poitn.
<warren> f13, (further cleanups of spec files stop at test4 so we have a more predictable result in F7)
<nirik> tibbs: agreed.
<warren> nirik, when infrastructure is ready, they will just be merged
<nirik> yeah, makes sense.
<warren> I'm lacking food and oxygen, so I'm going for now.
<nirik> warren: ok. So you will see about getting those changed? I guess that should be all on that topic... ;)
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<bpepple> ok, anything else before we call it quits?
<c4chris> nothing here
* bpepple will end the meeting in 60
* bpepple will end the meeting in 30
* bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End