Ubuntu Wiki

Agenda

• Review ACTION points from previous meeting
• Maverick Alpha2 subcycle
  • Deadline for specs submission

• Weekly Updates & Questions for the QA Team (hggdh)

• Weekly Updates & Questions for the Kernel Team (jjohansen)

• Maverick Papercuts: Start of the alpha-2 round (ttx)

• Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)

  • How to handle updates to ec2-ami-tools, ec2-api-tools (582387) (smoser)

• Open Discussion
• Announce next meeting date and time

Minutes

Review ACTION points from previous meeting (ttx)

• ttx to confirm spec submission deadlines with Jos: DONE
• ttx to walk SpamapS through the spec proces: DONE

Maverick Alpha2 subcycle and specs

• specs need to be set to review by EOB May 26 (Extends deadline by 1 day)
• design mandatory, implementation (work items) should have a full rough plan, user stories can be filled in later.

Weekly Updates & Questions for the QA Team (hggdh)

• zul needs help getting back ability to nominate bugs for lucid
• QA workflow spec to remain as server team's responsibility (jiboumans)

Weekly Updates & Questions for the Kernel Team (jjohansen)

• status update on ec2/uec kernel upgrades
  • built many, none have booted, will check vmlinuz stripping/xen settings (jjohansen)
• CEPH will be enabled in next upload to maverick

Weekly status for Server documentation (sommer)

• Server guide for lucid had a broken PDF, fix committed and awaiting upload to "h.u.c" (sommer)
• documentation specs to be moved under Ubuntu launchpad project to allow usage of work items tracker (sommer)
  • [ACTION] sommer to try to move server doc spec to Ubuntu specs

Maverick Papercuts: Start of the alpha-2 round (ttx)

• All should blog/announce papercuts (ttx)
• Minor features / wishlist are included because not LTS cycle (ttx)
• nominate by marking bugs as affecting 'server-papercuts' project
• nominations will be reviewed next week, sub cycle begins Jun 2nd, ends week before Alpha2 release

Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)

• Two bugs nominated, 567179 & 583542, to be declined pending more information

• New SRU review process spec revealed with shiny pictures https://wiki.ubuntu.com/ServerMaverickSruProcess

Open Discussion

• EC2 AMI-API tools in multiverse are out of date whenever amazon adds services/regions/etc.
  • PPA vs. backports discussion results in PPA *and* backports upload as way to get latest tools to users.

Announce next meeting date and time

• Next meeting will be Tue, Jun 1 18:00 UTC 2010

Log

[19:00] <MootBot> Meeting started at 13:00. The chair is ttx.
[19:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:00] <SpamapS> ajoi
[19:00] <smoser> 0/
[19:00] <ttx> Welcome to the 15428th Ubuntu Server Team meeting
[19:01]  * smoser claps
[19:01] <ttx> Agenda is fresh at https://wiki.ubuntu.com/ServerTeam/Meeting
[19:01] <ttx> Lucky scribe is SpamapS
[19:01]  * SpamapS bows
[19:01] <ttx> SpamapS: details about minutes publication at: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#Team%20policy
[19:01] <zul> muhaha
[19:01] <ttx> [TOPIC] Review ACTION points from previous meeting
[19:02] <MootBot> New Topic:  Review ACTION points from previous meeting
[19:02] <ttx> * ttx to confirm spec submission deadlines with Jos: DONE
[19:02] <ttx> Deadline was today EOB, but we'll discuss that later
[19:02] <ivoks> oh?
[19:02] <ttx> * ttx to walk SpamapS through the spec process
[19:02] <ivoks> doh.
[19:02] <ttx> DONE as well, I think. He ran out of questions
[19:03] <ttx> [TOPIC] Maverick Alpha2 subcycle and specs
[19:03] <MootBot> New Topic:  Maverick Alpha2 subcycle and specs
[19:03] <ttx> We need to finalize specs, review them and assign some of them to the Alpha-2 iteration this week
[19:04] <ttx> Specs that are ready must be set to "Review" status
[19:04] <ttx> Given that a fair number of them are not yet in that status, I assume that today's deadline might be difficult to reach
[19:05] <ttx> So please move as many as you can to that status today. And the new deadline is tomorrow EOB
[19:05] <zul> yay!
[19:05] <ivoks> thank you!
[19:05] <mathiaz> ttx: what'S the most important items that should be part of the specs?
[19:05] <ttx> We'll review the specs starting today, asking questions on the whiteboard
[19:05] <mathiaz> ttx: should WI be already defined?
[19:05] <ScottK> ivoks: I'll take care of the mail stack spec.
[19:05] <mathiaz> ttx: can the user stories be postponed?
[19:05] <ivoks> ScottK: ok
[19:06] <mathiaz> ttx: or should the spec be completly ready?
[19:06]  * ScottK even started on it already.
[19:06] <ttx> mathiaz: design is the most important. Implementation (or WI) should at least give an idea of how much work is involved
[19:06] <ttx> mathiaz: if you need to pick something to leave out, user stories are a good candidate
[19:07] <mathiaz> ttx: ok - so in order of importance: 1. Design 2. Work Items (=implementation) 3. Other sections
[19:07] <ttx> mathiaz: I have a few specs where I'm missing info, so having an open plan in the spec is ok too. Something where the first steps of Implementation is "find the right design" :)
[19:08] <ttx> mathiaz: yes
[19:09] <SpamapS> such as "cloud-loadbalancer - create proof of concept LB config backend (puppet or REST): TODO
[19:09] <ttx> Ideally community specs would be filed by that deadline as well. Especially if they rely on some outside help
[19:09] <ttx> If they are not ready by tomorrow EOB we'll have trouble incorporating them in the general server roadmap
[19:09] <jiboumans> appologies for the late join, a call ran somewhat over. Thanks ttx for getting things started.
[19:10] <ttx> jiboumans: floor is yours, sir
[19:10] <jiboumans> ttx: that went fast :)
[19:10] <jiboumans> so, what ttx said ^ ;)
[19:10] <mathiaz> ttx: well - you've started the meeting
[19:10] <mathiaz> ttx: so only you can drive the bot
[19:10] <ttx> mathiaz: I can drive the bot.
[19:10] <mathiaz> ttx: (that may be a detail in the meeting though)
[19:11] <jiboumans> ttx: anything more on blueprint/spec prep?
[19:11] <ttx> I don't think so... Questions ?
[19:11] <ttx> Of course you can start working on urgent items on your specs.
[19:11] <jiboumans> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:11] <ttx> Also last thing...
[19:12] <ttx> Remember that merging is in full swing, and needs your help :)
[19:12] <zul> done and done
[19:12] <ttx> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:12] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:12] <hggdh> none ATM. I just marked my specs for review
[19:12] <jiboumans> hggdh: excellent. any input needed from us for those that you'd like to bring up?
[19:12] <zul> i would like to bring up something actually
[19:12] <hggdh> only the additional test rig
[19:13] <hggdh> zul, please go ahead
[19:13] <jiboumans> hggdh: let's sync up on that outside this meeting to get the fine points clear
[19:13] <zul> it seems my access to nominate bugs for lucid has disapeared which slows me down is there a way to get that fixed?
[19:14] <ttx> Daviey/kirkland: are you around ?
[19:15] <jiboumans> i'll take that as a 'no'
[19:15] <jiboumans> zul: can you raise it with kirkland/daviey via mail please?
[19:15] <SpamapS> not sure if this is pertinent exactly, but I added myself as a bug triager on Fridays
[19:15] <zul> jiboumans: sure
[19:15] <ttx> jiboumans: my question was unrelated to zul's problem
[19:15] <SpamapS> per zul's request I might add
[19:15] <ttx> I don't think they can help
[19:15] <jiboumans> ttx: my bad
[19:16] <mathiaz> zul: hm - has you membership in some team expired latelyÉ
[19:16] <mathiaz> zul: ?
[19:16] <zul> mathiaz: i dont think so
[19:16] <jiboumans> zul: in that case we'll need to contact a losa right?
[19:17] <mathiaz> zul: I talk to bdmurray - he may be able to figure it out
[19:17] <ttx> zul: see with bdmurray first
[19:17] <zul> jiboumans: probably lemme poke around a bit more
[19:17] <jiboumans> alright, anything else on QA?
[19:17] <hggdh> no news there for now
[19:17] <zul> not from me
[19:17] <ttx> hggdh: should the qa workflow spec be considered a server or a QA spec ?
[19:18] <ttx> i.e. who should be the approver ?
[19:18] <hggdh> ttx: this is a good Q, I cannot answer. I would venture a mix
[19:18] <ttx> jiboumans: where do you want it ?
[19:18] <jiboumans> ttx: since we initiated it, leave me as the approver for now
[19:19] <ttx> ok, same for UEC testing, I suspect.
[19:19]  * hggdh thinks it saner
[19:19] <jiboumans> definitely for UEC testing
[19:19] <ttx> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:19] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:19] <jiboumans> jjohansen: o/
[19:19] <jjohansen> hey :)
[19:19] <jiboumans> i was wondering about the kernel upgrades in uec/ec2
[19:19] <jjohansen> So I have started playing with the maverick pv-ops ec2 kernel
[19:20] <jiboumans> you're way ahead of me i see
[19:20] <jjohansen> I have built several but none have successfully booted :(
[19:20] <jjohansen> At the moment I am trimming configs and rechecking packaging/builds
[19:20] <zul> jjohansen: need help?
[19:20] <jjohansen> nah, not yet any way
[19:21] <jjohansen> its early can't really expect it to go right the first few times
[19:21] <zul> jjohansen: its probably nothing to do with the configs, its probably more to do with the vmlinuz you'll have to strip it
[19:21] <jjohansen> so hopefully we will have a kernel in a few days
[19:21] <SpamapS> I have an item in the cluster filesystem spec about Ceph being available as a module in the maverick kernel (which it is not in the latest). Do I need to add a work item in my spec for somebody on the kernel team?
[19:22] <jjohansen> zul: hrmm it should be stripped but I'll check
[19:22] <ivoks> one thing
[19:22] <zul> jjohansen: xen versions have different boot loaders
[19:22] <jjohansen> We already have that on our misc configs
[19:22] <ivoks> that's a cloud filesystem
[19:23] <jjohansen> ceph should be enabled with the next upload
[19:23] <SpamapS> jjohansen: ty. :)
[19:23] <jiboumans> SpamapS: good to add a workitem anyway so we can keep track of it
[19:23] <ttx> ok, any other questions for kernel ?
[19:24] <ttx> [TOPIC] Weekly status for Server documentation (sommer)
[19:24] <MootBot> New Topic:  Weekly status for Server documentation (sommer)
[19:24] <ttx> That's a new point :)
[19:25] <jiboumans> hi sommer
[19:25] <ttx> sommer: As discussed, it's good for you to have a forum for us to sync our respective needs, so here you go :)
[19:25] <sommer> there's been some good discussion on the ubuntu-doc list about new formats
[19:25] <ScottK> Is the 10.04 server guide available as a PDF?  It came up on #ubuntu-server recently and I didn't know where to point someone.
[19:25] <sommer> ScottK: there was an issue with the PDF for lucid, but I committed a change yesterday to take care of it
[19:26] <sommer> it just now needs to be rebuilt and uploaded to h.u.c
[19:26] <ttx> sommer: do you have a spec covering new sections that you want written for Maverick ?
[19:26] <ScottK> sommer: Great.  Thanks.
[19:26] <sommer> ttx: yep, https://blueprints.launchpad.net/ubuntu-docs/+spec/server-maverick-serverguide-updates
[19:27] <ttx> hm, I don't think that one can be picked up by our work items system, since it's not the same project
[19:27] <ttx> sommer: so you'll have to use that lot in the meeting to shout when you need outside help.
[19:27] <sommer> oh, should I change it?
[19:27] <jiboumans> ttx: would be great to have all server related blueprints in the WI tracker though
[19:27] <jiboumans> wonder how we can do that
[19:27] <ttx> jiboumans: it needs to be an Ubuntu spec
[19:28] <ttx> jiboumans: then if targeted against Maverick, work items assigned to team members would show up in our tracker
[19:28] <mathiaz> can't the spec be just reattached to the ubuntu project?
[19:28] <sommer> if not I can recreate it
[19:28] <ttx> I doubt that's possible
[19:28] <mathiaz> or recreate it
[19:29] <ttx> sommer: that would be great. Then you can have work items like "write draft of section x" and assign that to someone, and keep "Review draft of X" on your plate
[19:29] <jiboumans> that'd work very well indeed
[19:30] <ttx> [ACTION] sommer to try to move server doc spec to Ubuntu specs
[19:30] <MootBot> ACTION received:  sommer to try to move server doc spec to Ubuntu specs
[19:30] <jiboumans> next is you ttx on papercuts
[19:30] <ttx> [TOPIC] Maverick Papercuts: Start of the alpha-2 round (ttx)
[19:30] <MootBot> New Topic:  Maverick Papercuts: Start of the alpha-2 round (ttx)
[19:30] <sommer> what's the project name?
[19:30] <ttx> sommer: "Ubuntu" ?
[19:30] <sommer> doh, sooo simple :)
[19:30] <ttx> So in order to have a full alpha-2 round for papercuts, I anticipated the review and prepared the round in advance. I'll call for nominations today, and open nominations (until next week's meeting where we'll decide on the bugs for the round)
[19:31] <ttx> delaying one more week would jeopardize the length of that subcycle
[19:31] <jiboumans> ttx: that warrants a seperate mail to u-devel/-server right?
[19:32] <ttx> jiboumans: yes. I start with a blog post, then tomorrow an email... Then I would appreciate some echo on blogs of yours
[19:32] <ttx> I already know Yokozar will echo it, since he was in that UDS room
[19:32] <ttx> any other blogger with a large audience is welcome (kirkland ?)
[19:32] <ttx> We already have a few candidates from previous leftovers
[19:33] <ttx> Note that this time, you can nominate minor features as well !
[19:33] <zul> minor features like what?
[19:33] <ivoks> like utf8 in mysql by default?
[19:33] <ttx> The method is the same, mark as affecting the "server-papercuts" project
[19:33] <ttx> like things that would impact behavior, and that we refused because of FeatureFreeze during the lucid cycle
[19:34] <ttx> ivoks: a papercut needs to be non-conflicting
[19:34] <ttx> and simple to implement :)
[19:35] <SpamapS> otherwise we'd have to call it a paper stab
[19:35] <ivoks> it's simple alright
[19:35] <ttx> We'll review the nominations next week to come up with a list of candidates
[19:35] <ttx> and start the subcycle on Jun 2nd
[19:35] <ttx> to end it end of week before the Alpha2 release
[19:35]  * sommer heh stab
[19:35] <ttx> questions ?
[19:36] <ttx> we'll need everyone's help in fixing those papercuts btw
[19:37] <ttx> choosing them is the easiest part of the job :)
[19:37] <ttx> [TOPIC] Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)
[19:37] <MootBot> New Topic:  Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)
[19:37]  * mathiaz opens up the links
[19:37] <mathiaz> two bugs nominated for lucid:
[19:37] <mathiaz> bug 567179
[19:37] <ubottu> Launchpad bug 567179 in mysql-dfsg-5.1 (Ubuntu) "Update mysql-server-5.1 hangs up" [Medium,Incomplete] https://launchpad.net/bugs/567179
[19:38] <mathiaz> bug 583542
[19:38] <ubottu> Launchpad bug 583542 in openssh (Ubuntu) "ssh server doesn't start when irrelevant filesystems are not available" [Undecided,New] https://launchpad.net/bugs/583542
[19:38] <zul> ubottu: im testing bug 567179
[19:38] <ubottu> Error: I am only a bot, please don't think I'm intelligent :)
[19:38] <zul> stupid bot
[19:38] <zul> i have it fixed for maverick (567179) just need to get people in lucid to test it
[19:39] <mathiaz> I think both bugs are not ready for SRU as of now
[19:39] <ttx> mathiaz: ack
[19:39] <mathiaz> as they still need to more information to get to the triage state
[19:39] <mathiaz> I'm going to decline them
[19:39] <mathiaz> any bugs worth fixing from http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html ?
[19:39] <smoser> there is no fix for 583542 available
[19:40] <zul> 577165
[19:40] <mathiaz> smoser: ok
[19:40] <mathiaz> bug 577165
[19:40] <ubottu> Launchpad bug 577165 in vsftpd (Ubuntu) "Typo in etc/init/vsftpd.conf" [Low,Fix released] https://launchpad.net/bugs/577165
[19:40] <jiboumans> bug 573206 sounds important enough
[19:40] <ubottu> Launchpad bug 573206 in mysql-dfsg-5.1 (Ubuntu Maverick) "[SRU] upstart script does not load AppArmor profile" [High,Fix released] https://launchpad.net/bugs/573206
[19:41] <zul> jiboumans: its already fixed in lucid
[19:41] <ttx> jiboumans: it's already done apparently. Zul's magic
[19:41] <jiboumans> zul++ also way ahead of me
[19:41]  * jiboumans notes that being in UTC+8 means he's behind the times
[19:42] <RoAkSoAx> lol :P
[19:42] <mathiaz> I've written up the Spec for the updated sru-process in maverick:
[19:42] <mathiaz> https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-sru-process
[19:42] <mathiaz> https://wiki.ubuntu.com/ServerMaverickSruProcess
[19:42] <ttx> ooo, a graph !
[19:42] <mathiaz> so if you wanna comment on what's coming up please head there
[19:43] <mathiaz> and there are shiny diagrams as wel :)
[19:43] <zul> wohoo diagrams!
[19:43] <ttx> mathiaz: now I know why you don't have time to write user stories. Too busy doing shiny diagrams
[19:43] <mathiaz> ttx: :)
[19:44] <mathiaz> ttx: it's an experiment:
[19:44] <mathiaz> a picture is worth a thousand words!
[19:44] <jiboumans> agreed there
[19:44] <RoAkSoAx> +1
[19:44] <ttx> now you need to automate paperboard -> dia transition
[19:44] <mathiaz> that's all from me on the SRU front
[19:44] <mathiaz> ttx: I've got some ideas there :)
[19:45] <mathiaz> anything else?
[19:45] <mathiaz> on the SRU front?
[19:45] <jiboumans> smoser, you had something on ami/api tools?
[19:45] <smoser> yes.
[19:45] <smoser> seeking feedback.
[19:45] <smoser> ec2-ami-tools and ec2-api-tools are multiverse packages
[19:45] <smoser> they are updated by amazon to expose new features (or regions) on occasion
[19:46] <smoser> in the past we have provided backports of these via a ppa
[19:46] <mathiaz> smoser: one option is to push them to -backports
[19:46] <smoser> https://launchpad.net/~ubuntu-on-ec2/+archive/ec2-tools
[19:46] <mathiaz> smoser: they may actually be SRUable as well
[19:46] <smoser> right. so 3 options:
[19:46] <smoser> a. SRU
[19:46] <smoser> b.
[19:46] <smoser>  backports
[19:46] <smoser> c. ppa backports
[19:46] <smoser> we've been doing c.
[19:46] <ttx> (a) needs a TB derogation
[19:47] <mathiaz> smoser: under the exception that they're useless (?) if the network service changes
[19:47] <smoser> well they're never useless.
[19:47] <mathiaz> smoser: landscape-client is an example of package that an SRU exception
[19:47] <smoser> the old tools work, they just do not expose new functionality
[19:47] <mathiaz> smoser: right
[19:47] <mathiaz> smoser: so -backports is the best option
[19:48] <smoser> is there a reason to prefer -backports over ppa ?
[19:48] <mathiaz> smoser: -backports are easily discoveralbe
[19:48] <mathiaz> smoser: whereas PPA are less discoverable
[19:48] <smoser> i question it because there is a fair amount of use of the ppa, and education to use backports instead would be needed.
[19:48] <mathiaz> smoser: there is an option in the sources list manager to enable backports
[19:49] <mathiaz> smoser: and I think there -backports options in sources.list are also set but commented
[19:49] <jiboumans> we do have the option to enable the ppa on EC2 images ourselves
[19:49] <mathiaz> smoser: right - if it's common knowledge to enable the PPA then I'd stick with the existing option
[19:49] <SpamapS> In my brief time running Ubuntu server I've never used thes ources list manager.. but I've definitely setup a few PPA's to pull from
[19:49] <smoser> jiboumans, well.. tools are in multiverse, they're not in our images by design.
[19:50] <mathiaz> smoser: if the use of the PPA is advertised and documented then I'd stick with the PPA
[19:50] <smoser> mathiaz, if backports is the right thing, then i think we should go that route.
[19:50] <SpamapS> can the server guide be updated with that?
[19:50] <mathiaz> smoser: it seems that the use of the PPA is already common knowledge
[19:51] <ScottK> smoser: I've got no problem pushing the updated ec2 tools in backports.
[19:51] <ttx> since this derived from the SRU process discussion, let's move to
[19:51] <ttx> [TOPIC] Open discussion
[19:51] <MootBot> New Topic:  Open discussion
[19:51] <mathiaz> smoser: so I wouldn't change that
[19:51] <mathiaz> smoser: and as mentioned by ScottK we could publish the package to both -backports and a PPA
[19:51] <ScottK> mathiaz: Generally I think it's a problem to push people to use third party repositories when it's not really required.
[19:51] <mathiaz> smoser: it may add some overhad though
[19:51] <smoser> mathiaz, somewhat common knowledge.  googling probably finds it, but it finds backports also.
[19:52] <smoser> i am leaning towards re-education
[19:52] <smoser> backports is a common place for backports
[19:52] <mathiaz> ScottK: right - IMO the main issue here is how discoverable the repository to use is (be it a PPA or a -backports)
[19:52] <SpamapS> smoser: that is almost t-shirt worthy
[19:52]  * ttx leans towards reeducation too
[19:52] <ScottK> smoser: You know the backports procedure?
[19:52] <Daviey> o/
[19:53] <smoser> i can read
[19:53] <smoser> :)
[19:53] <ttx> SpamapS: we have a "quotes" page.
[19:53] <ScottK> OK.  Ping me if you have questions.
[19:53] <smoser> yeah. thanks ScottK
[19:53] <jiboumans> so... open discussion? :)
[19:53] <ScottK> I'd like to talk about package stack names.
[19:53] <SpamapS> I like the idea of having them in both
[19:53] <mathiaz> smoser: https://help.ubuntu.com/community/UbuntuBackports
[19:53] <ScottK> So far we have mail and cluster stack.
[19:53] <SpamapS> The PPA will get them right away.. backports upon completion of the process. Seems useful.
[19:53] <jiboumans> ScottK: go right ahead
[19:54] <zul> i like to say that im melting
[19:54] <ScottK> In mail stack, we're planning on using mail-stack-foo package names.
[19:54] <ScottK> I think having a general rule of [stackname]-stack-[function] is a good way to go.
[19:55] <jiboumans> ScottK: i've been following the thread on naming and i'd agree there
[19:55] <ScottK> I think cluster stack is similar, but not sure.
[19:55] <sommer> that makes sense to me
[19:55] <RoAkSoAx> ScottK: yes it is similar, though the difference is that in our scenarios we are in need of multiple machine
[19:55] <ScottK> Since I know you are pushing the idea of more community supported stacks, it seems like a good idea to have a standard naming scheme and have that documented.
[19:55] <jiboumans> ScottK: it caters to the road of least surprise (as opposed to 'dovefix' which makes sense mostly to those in the know)
[19:56] <SpamapS> are there other stacks in the pipeline?
[19:56] <ScottK> SpamapS: Not that I know of, but I know Canonical wants to encourage the concept.
[19:56] <RoAkSoAx> For Cluster Stack, names I've been thinking of is: cluster-stack-failover and cluster-stack-loadbalancing
[19:57] <ttx> ScottK: you apparently do not meet any resistance :)
[19:57] <SpamapS> how do stacks differ from tasks?
[19:57] <ttx> let's wrap up.
[19:57] <ScottK> ttx: Could you have someone document this policy?
[19:57]  * SpamapS will takethe answer offline. :)
[19:57] <ttx> ScottK: where would you see this policy ? As a server team policy ?
[19:57] <mcas> the stack packages are virtual packages?
[19:58] <ttx> ScottK: or something more TB-level ?
[19:58] <mathiaz> https://wiki.ubuntu.com/ServerTeam/KnowledgeBase
[19:58] <mathiaz> ^^ seems like a good place to document that for the time being
[19:59] <ttx> [ACTION] ttx to document (or delegate documentation of ) package stack names
[19:59] <MootBot> ACTION received:  ttx to document (or delegate documentation of ) package stack names
[19:59] <ttx> [TOPIC] Announce next meeting date and time
[19:59] <MootBot> New Topic:  Announce next meeting date and time
[19:59] <ttx> Next week, same place same time
[19:59] <ttx> #endmeeting
[19:59] <MootBot> Meeting finished at 13:59.