16:00 <infinity> #startmeeting Tech Booooooooard!
16:00 <meetingology> Meeting started Tue Apr 26 16:00:53 2016 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:00 <meetingology> 
16:00 <meetingology> Available commands: action commands idea info link nick
16:01 <infinity> #topic Action (action, ACTION, this Sunday only!) review
16:02 <infinity> We'll start with mine.  maas stuff still not done.  docker is in progress, discussion about TB size is completed and Mark's response was "do what you think is best", so I think we're down to 5.  I'll inform dholbach so he doesn't announce 6 winners.
16:02 <infinity> slangasek: juju SRU?
16:03 <slangasek> that's juju SRU exception documentation, yes? carry over
16:03 <infinity> Carried.
16:03 <slangasek> on the subject of maas sru, we have https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1509147 now
16:03 <infinity> #topic mailing list review
16:04 <infinity> slangasek: Yup.  With release behind me, I'll tackle MAAS stuff and make some sense of it.
16:04 <infinity> Mailing list seems full of resolved issues and election things, nothing interesting.
16:04 <infinity> #topic community bugs
16:04 <infinity> Nein.
16:05 <infinity> Nada.
16:05 <infinity> Zip.
16:05 <infinity> #topic next chair
16:05 <infinity> Next chair is a mystery, as the election should be done by then, but assuming we get reelected, it's kees.
16:05 <slangasek> fwiw the "resolution" of the request for php7.0 mre was to punt it to the sru team, who have no formal meetings or clear process for getting these things done
16:05 <stgraber> infinity: election is over, we are all re-elected
16:05 <slangasek> so while the TB has delegated that back to the SRU team, I'm not sure it hasn't left Nish in limbo
16:05 <infinity> stgraber: Oh.  Did I miss the mail?
16:05 <stgraber> infinity: so new TB is same as old TB, minus pitti
16:06 <slangasek> infinity: apparently :)
16:06 <stgraber> our membership has been renewed on LP till May 2018
16:06 * infinity wonders where that email went.
16:06 <kees> yay chairing
16:06 <slangasek> technical-board@lists.ubuntu.com
16:06 <infinity> Not to u-d-a or tb...
16:07 <infinity> Oh.
16:07 <infinity> Attached to an old thread.
16:07 <infinity> Naughty.
16:07 <infinity> Well, congrats us!
16:07 <infinity> Next chair is kees, then. :P
16:07 <mdeslaur> hehe
16:07 <kees> woo!
16:07 <infinity> With Marc backup.
16:07 <mdeslaur> ack
16:08 <slangasek> yes, it was a surprising result from a dark horse candidate
16:08 <infinity> #topic AOB
16:08 <slangasek> yes AOB
16:08 <slangasek> I think I suggested last time that we should double-check post-election that this meeting time is still good for the board
16:08 <infinity> So, since we have a renewed term, anyone have AOAOB to discuss?  Plans?
16:09 <mdeslaur> not sure if this is tech board worthy, but I'd like to discuss what the output of ubuntu-support-status should be
16:09 <infinity> It's the same board, minus pitti, though I think pitti was the reason we had this specific time.
16:09 <infinity> FWIW, I'm used to this time now, and changing will confuse me. :P
16:09 <kees> stgraber: what's your TZ?
16:09 <stgraber> this time works fine for me, but I'd be happy to move it later if it helps some folks
16:09 <infinity> kees: He's eastern, except when not.
16:09 <stgraber> kees: eastern
16:09 <stgraber> eastern but working pacific-ish hours usually
16:09 <kees> i'm ok keeping this, but ok to move too
16:09 <slangasek> infinity: yes, and we have not had perfect attendance at this time slot
16:10 <infinity> The entire board is between pacific and eastern now.
16:10 <infinity> So we could certainly move it a bit.
16:10 <mdeslaur> this meeting is during my usual lunch hour, but I don't mind keeping it or moving it
16:10 <infinity> Well, we all sound pretty wishy-washy. :)
16:10 <slangasek> I'm fine either way; just wanted to raise the question because I wasn't sure the time was working for everyone else
16:11 <infinity> Would we prefer easten afternoon to make it later for Pacific/Mountain?
16:11 <kees> deadlocked already!
16:11 <slangasek> does anyone care about the time enough to run a doodle poll?
16:11 <stgraber> we could push it by a couple of hours
16:11 <infinity> I prefer morning meetings so they don't break up my day, but then I run the risk of missing them when I've had an insomniac night.  *shrug*
16:11 <infinity> Basically, I can't win. :P
16:12 <infinity> So, I leave it to the PST/EST people to fight out, if they care enough to do so.
16:12 <slangasek> does anyone care about the time enough to run a doodle poll?
16:12 <slangasek> if not then the meeting can stay where it is
16:12 <mdeslaur> it can stay
16:12 <stgraber> I don't :)
16:12 <infinity> #vote does anyone care?
16:12 <meetingology> Please vote on: does anyone care?
16:12 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
16:12 <slangasek> though if we moved the meeting, we might manage to get rid of that -2 suffix on the channel ;)
16:12 <infinity> -1
16:12 <meetingology> -1 received from infinity
16:12 <slangasek> +0
16:12 <meetingology> +0 received from slangasek
16:12 <stgraber> -1
16:12 <meetingology> -1 received from stgraber
16:12 <mdeslaur> +0
16:12 <meetingology> +0 received from mdeslaur
16:13 <infinity> kees: Register carefactor? :P
16:13 <kees> -1
16:13 <meetingology> -1 received from kees
16:13 <infinity> #endvote
16:13 <meetingology> Voting ended on: does anyone care?
16:13 <meetingology> Votes for:0 Votes against:3 Abstentions:2
16:13 <meetingology> Motion denied
16:13 <infinity> The motion to not care carries.
16:14 <mdeslaur> laziness prevails
16:14 <mdeslaur> :)
16:14 <infinity> mdeslaur: So, support-status....
16:14 <infinity> mdeslaur: Retroactively fixing this is hard and potentially harmful (requires careful diffing of the archive when we ever do anything stupid like republish the release pocket).
16:14 <infinity> But we could, if there was enough pressure to do so.
16:15 <infinity> We could also band-aid it by making the tool just do an "if in main == status == same_as_base-files" or something. :P
16:15 <infinity> If the tool is deemed the "correct" way for people to determine status.
16:16 <mdeslaur> I was thinking of just doing main/universe for < xenial, and for xenial doing if main == same_as_base-files
16:16 <slangasek> I certainly don't consider it deprecated, in spite of the unfortunate bit-rotting that had happening
16:16 <slangasek> happened
16:16 <kees> (i thought my delegates would handle that that vote)
16:17 <mdeslaur> I don't think the seeds were accurate for precise to trusty
16:17 <mdeslaur> sorry, precise to wily
16:17 <infinity> mdeslaur: So, it's called UBUNTU-support-status, not CANONICAL-support-status, thus yor main/universe split isn't correct.
16:17 <infinity> Maybe we should determine what the tool's actually supposed to tell people.
16:17 <kees> didn't we just create a manual file back in dapper time?
16:17 <mdeslaur> infinity: right, but do you want to republish the stable releases?
16:17 <mdeslaur> or, alternatively, we could bundle a manual file with the tool for the stable releases
16:17 <infinity> mdeslaur: My point was that lots of stuff in universe for precise/trusty (correctly) lists itself as supported due to flavour LTSes.
16:18 <slangasek> infinity: per my comment on thread, I don't think letting flavors claim LTS "support" without any sort of CVE tracking is particularly honest
16:18 <mdeslaur> infinity: yes, but I don't think the seeds are right
16:18 <infinity> Sure they are.
16:18 <infinity> The seeds are correct, it's how we're interpreting them in LP that isn't what you expect.
16:18 <mdeslaur> yes, that's what I meant
16:18 <mdeslaur> you're nitpicking :)
16:19 <mdeslaur> ok, let me investigate and I'll come up with a proposal
16:19 <infinity> FWIW, this is the current logic: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py
16:19 <mdeslaur> slangasek: we did have a web page that tracked cves for flavour supported packages...I don't know if it's still alive though
16:20 <infinity> So, you can see we pick up desktop, server, and some supported seeds.  The bug is that we don't take *all* supported seeds (hence, we don't get all of main).
16:20 <mdeslaur> which we should
16:20 <infinity> The universe bits are accurate, it's just main that isn't, due to some confusion about the desktop/server split meaning that !desktop and !server got short times.
16:21 <infinity> mdeslaur: Anyhow, I'm not against republishing xenial-release if we have to.  It just requires great care.  I will flat out refuse to republish precise or trusty, though, so those would need some tool hackery to be "good enough".
16:21 <mdeslaur> infinity: let's say we fix that, is it worth republishing the release pocket, or should we just bundle a static list with the tool
16:22 <mdeslaur> so you'd be ok with xenial-release, but for earlier we hack the tools, that's fine by me
16:22 <slangasek> infinity: let's ignore precise+trusty for now; I'm not sure the tool *runs* in all of those releases
16:22 <slangasek> (that's how bad the bit rot was)
16:22 <mdeslaur> the nginx thread was trusty
16:22 <infinity> slangasek: The original archive reorg plan had a way to designate *who* support came from, which would (somewhat) mitigate your concern, as people can adjust expectations based on "community" versus "canonical", but with the current setup, we can't do much be keep it muddy.
16:23 <infinity> s/be keep/but keep/
16:23 <infinity> It may be slightly dishonest to claim lxde has 3y support when it's not the same support we provide for glibc, but it's equally dishonest to claim it's not supported when they committed to supporting it, so it's rock meets hard place.
16:23 <slangasek> infinity: well, as the TB what we can do is insist that flavors actually provide support in the way we mean it before granting them LTS status
16:24 <infinity> slangasek: Sure, that's not unreasonable.
16:24 <slangasek> which we have not done up to this point, at least for the meaning of support that I consider relevant
16:24 <mdeslaur> when we say "9m" support for everything in universe that nobody has commited to supporting, isn't that a lie?
16:24 <slangasek> I'm not asking to readjudicate all of that for 16.04, but I think we should put out a clearer standard for future LTS
16:24 <infinity> mdeslaur: I know the CVE tracker needs a lot of manual garndening.  Is there a way to run it in a "good enough" mode for !canonical-supported stuff that just does an okay job of importing things, ish? :P
16:25 <infinity> mdeslaur: So it's not extra workload for you, but the community people have a place to look?
16:25 <slangasek> mdeslaur: sure, maybe unseeded should be 0 instead of 9?
16:25 <mdeslaur> infinity: we did have a web page for flavours, let me figure out what happened to it
16:25 <infinity> unseeded is 0.
16:25 <mdeslaur> slangasek: that's kind of what I'm thinking
16:25 <infinity> mdeslaur: It would be a lie if that were the case, but it's not.
16:26 <slangasek> infinity: ah, ok
16:26 <stgraber> well, it's not 0, it's just not set (no Supported field), maybe we should actually set it to 0 too
16:26 <infinity> (xenial-amd64)root@nosferatu:/home/adconrad# apt-cache show libc6 | grep ^Sup
16:26 <infinity> Supported: 5y
16:26 <slangasek> in that case, 9m for flavor-seeded-but-no-track-record-of-doing-security-support is probably an ok compromise
16:26 <infinity> (xenial-amd64)root@nosferatu:/home/adconrad# apt-cache show thunar | grep ^Sup
16:26 <infinity> Supported: 3y
16:26 <infinity> (xenial-amd64)root@nosferatu:/home/adconrad# apt-cache show lazarus | grep ^Sup
16:26 <infinity> (xenial-amd64)root@nosferatu:/home/adconrad#
16:27 <stgraber> or "Supported: not"
16:27 <infinity> We could fill in the field, sure.  Empty == 0 historically, but meh.
16:27 <mdeslaur> are flavours that didn't apply for lts actually supporting stuff for 9m?
16:27 <infinity> That's more bikeshedding than fixing any real problem, I think.
16:27 <slangasek> agreed, -1 to bikeshedding
16:27 <infinity> mdeslaur: There are no non-lts flavours.
16:28 <infinity> mdeslaur: Anything you see with "9m" is due to the misfeature we're discussing, not flavours.
16:28 <infinity> mdeslaur: Basically, it's listed in a supported seed that we don't consider for LTS length.
16:29 <infinity> http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py#L36
16:29 <infinity> Those lists there are the ones that get LTS length.
16:29 <infinity> Any other supported seeds are 9m.
16:29 <infinity> That's the bit we'd fix if we were to republish.
16:29 <infinity> It's a two-line change or so to get all of main in.
16:29 <mdeslaur> SUPPORTED_SEEDS = ["all"]
16:30 <infinity> Yeah, SUPPORTED_SEEDS ends up being 9m.
16:30 <mdeslaur> who supports the supported seeds that aren't flavours, and aren't main
16:30 <slangasek> mdeslaur: there's no such thing?
16:30 <slangasek> seeds are in main, or they're flavors
16:31 <slangasek> more precisely: seeds are the definition of the products, including the community flavors; and some of those seeds are also defined as main
16:31 <mdeslaur> but xenial universe is chock full of 9m
16:31 <infinity> So, I can whip up a change on dogfood for people to see what this would look like if I pull all the ubuntu/main seeds in.
16:31 <slangasek> curious
16:31 <mdeslaur> who's supporting those packages in xenial universe for 9m
16:31 <slangasek> infinity: does maintenance-check follow build-deps?
16:31 <slangasek> this could be fallout from archive reorg
16:31 <infinity> slangasek: Oh, hrm.  It might.
16:32 <infinity> Though it shouldn't.
16:32 <infinity> Oh.
16:32 <infinity> Balls.
16:32 <infinity> No.
16:32 <infinity> following build-deps is a seed property.
16:32 <infinity> And we only turned it off in *our* seeds.
16:32 <infinity> So flavours will get *their* build-deps recursed.
16:32 <infinity> Derpy McDerpface.
16:33 <mdeslaur> hehe
16:33 <infinity> Okay, I think we might need to fiddle with this a bit on dogfood.
16:33 <infinity> Twiddle seeds to stop doing recursion, twiddle maint-check to include the rest of ubuntu/platform supported, and regen and see how scary the diff is.
16:33 <slangasek> infinity: well, the first few 9m hits I find in universe are Task: ubunutstudio-audio, plus a -dbg package.  Those seem like a different issue from build-deps
16:34 <infinity> slangasek: The studio ones seem entirely reasonable to be 9m.  They'd be in a studio seed that isn't desktop.
16:34 <slangasek> infinity: why is that reasonable?
16:34 <infinity> And almost everyone has bugs where they don't include a supported: ALL MY TASKS bit in STRUCTURE.
16:35 <mdeslaur> Supported: 9m
16:35 <mdeslaur> Task: edubuntu-desktop-gnome
16:35 <infinity> slangasek: Reasonable given the code, not reasonable as in "that's the desired output".
16:35 <slangasek> infinity: yes, so my question is what's the right way to fix those, given that no-follows-build-dep doesn't change it
16:36 <slangasek> do we expect anything seeded by an LTS flavor to get the LTS support length, the same as we expect for main?
16:36 <infinity> slangasek: Oh, the way to fix those studio ones is to include all their seeds in supported in STRUCTURE (and same for all flavours... Indeed, that's our correct fix too)
16:36 <infinity> slangasek: Yeah, I think that's what we want.
16:36 <slangasek> ok; I agree
16:36 <slangasek> does mdeslaur ?
16:36 <mdeslaur> yes
16:37 <infinity> Okay, this'll take some grinding on dogfood to work out a set of changes to maint-check and seeds and see if it turns out more correct.
16:37 <infinity> But I can take an action to play with that.
16:37 <slangasek> sounds good
16:37 <infinity> And then we can revisit if we want to republish or mangle tools.
16:37 <mdeslaur> infinity: let me know when you have something to look at
16:37 <infinity> But I think republishing will be the right answer.
16:38 <mdeslaur> and I can take care of the tools, whatever we ultimately decide
16:38 <infinity> mdeslaur: I think fudging the tools for precise/trusty will be fine.  There are no LTS precise flavours left, and only a couple of LTS trusty flavours soon, so meh.
16:39 <infinity> #action infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing
16:39 * meetingology infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing
16:39 <mdeslaur> infinity: ok, so the main/universe tool fudge I suggested earlier for precise and trusty would be ok?
16:40 <infinity> mdeslaur: Well, either that, or "if main, same_as_base_files" ... Then you're not demoting universe things that do claim 3/5.
16:40 <slangasek> now, what's the action re: making sure flavors are accountable for security updates before we declare them LTS, which I believe today they are not?
16:40 <infinity> mdeslaur: Since this bug/misfeature doesn't mean anything is listed as too long, only too short.
16:40 <mdeslaur> assuming the supported tags in precise/trusty universe actually make sense, I'll have to look first
16:41 <infinity> slangasek: We ask them to be accountable, enforcing that is harder.  But feel free to take an action to follow up on tooling available and educating them about their responsibilities.
16:41 <slangasek> infinity: "ask them to be accountable"> nack
16:41 <slangasek> there needs to be a burden of evidence here
16:41 <infinity> slangasek: Some things (like security having to go through the security team) make the process suck.  We might be able to do better there, with a community security PPA or something.
16:41 <mdeslaur> I'll take an action to look into the web page we had that listed open CVEs by flavour
16:42 <slangasek> o
16:42 <slangasek> k
16:42 <slangasek> I'm fine with the Ubuntu Security team driving that reporting
16:42 <infinity> #action mdeslaur to look into flavour CVE tracking
16:42 * meetingology mdeslaur to look into flavour CVE tracking
16:42 <infinity> Yeah, I'm fine with them driving it, as long as they don't also spend time gardening it.
16:42 <infinity> So, it should be mostly automagic (even if that means it has a ton of false positives)
16:42 <slangasek> if the Security Team doesn't have the time for that, though, I would say that we would need to put it to the flavors that they need to do this themselves
16:43 <infinity> Sadly, the way it's built, there's no way to give someone, say, SSO access to NACK an invalid CVE or something.
16:43 <infinity> But oh well.
16:43 <infinity> One step at a time.
16:43 <mdeslaur> a merge proposal works fine for now
16:43 <infinity> Check.
16:44 <infinity> mdeslaur: So, once we nail down the exact correct logic for maint-check, the same seed sets should be used to divvy up the flavours.
16:44 <infinity> mdeslaur: But we're diving into implementation here, so we can talk about that sort of thing later.
16:44 <mdeslaur> yes, perfect
16:45 <infinity> I don't disagree that the flavours have done a poor job of being "as good as Canonical's security team", but we can probably meet in the middle.  I hope.
16:45 <slangasek> I am not asking that the flavors be "as good as Canonical's security team"
16:46 <slangasek> I am saying we should not be rubber-stamping a 5-year LTS for a flavor when there is no committment whatsoever to provide security support
16:46 <stgraber> infinity: once the seeds are updated, http://people.canonical.com/~stgraber/supported-packages/lists/ should show the list of packages we expect each flavor to look at
16:46 <infinity> slangasek: Right, I know.
16:46 <infinity> stgraber: Oh, right.  That magic thing.  That's what Marc should be looking at.
16:47 <infinity> stgraber: The way that's built, can you pin shared responsibility on some things (like, studio/xu both owning xfce?)
16:47 <stgraber> that link above shows the list of packages that are unique to a given flavor (it knows what flavor depends on what other flavor)
16:47 <stgraber> infinity: we could change the logic to show that, though it'd then basically be straight germinate output
16:47 <mdeslaur> oh! nice
16:48 <infinity> stgraber: Cause studio's LTS application said they intended to help with xubuntu, rather than just rely on xubuntu fixing it all for them.
16:48 <infinity> stgraber: Well, not all flavours should report that way.  xu/studio are special. :)
16:48 <stgraber> infinity: ah, then we could change their config to say that it's not based on xubuntu, which would then include the xubuntu bits in their own list of packages too
16:48 <infinity> stgraber: Most flavours should report in the way you do already, just the stuff they're uniquely responsible for.
16:49 <stgraber> infinity: changed the studio config, next run will have them maintain anything that's not supported by ubuntu, so that will mean the xubuntu bits they use will show up in their list
16:49 <infinity> Perfect.
16:50 <infinity> Okay.  I think we've exhausted this topic from the POV of the TB meeting.
16:50 <infinity> And have given ourselves more work.  So, go us.
16:50 <slangasek> :)
16:50 <mdeslaur> hehe
16:51 <infinity> I think we should definitely reopen the flavour conversation with all of the flavour leads, but perhaps we should hold off until we've checked our own tooling to see if we can offer them an olive branch while also chastising them.
16:51 <infinity> Compliment sandwich style, as it were.
16:51 <slangasek> infinity: reopen for 16.04?
16:51 <slangasek> I think 16.04 is done; TB has approved these and we have to own that now
16:52 <infinity> slangasek: Well, yes, I think we want to make sure they're accountable for 16.04 updates.
16:52 <slangasek> but.. - yes, that
16:52 <infinity> slangasek: We approved it, but what we approved is them actually taking responsibility.
16:52 <slangasek> ack ;)
16:52 <infinity> slangasek: So, we need to make sure that's meaningful.
16:52 <infinity> To be fair, some do alright just by virtue of pushing new upstream point releases (ie: KDE).
16:52 <stgraber> also note that most of them only took 3y LTS this time around which is a bit more reasonable than the 5y a bunch of them had last time around
16:52 <infinity> Others could use a bit more of a shove.
16:53 <stgraber> the exception being Kylin IIRC
16:53 <infinity> And some only ship like 20 unique packages, so their burden is low.
16:53 <infinity> Yeah, kylin is the only 5y, and 99% of kylin is Ubuntu.
16:53 <infinity> Which is the only reason I didn't shoot them down.
16:53 <slangasek> fair
16:53 <stgraber> well, they apparently will be suppporting chromium for 5 years
16:53 <slangasek> even 3 years needs to mean something, though
16:54 <stgraber> but yeah besides that one, their delta seems fine
16:54 <infinity> slangasek: Absolutely.  My 5y/3y criteria was about overlap commitment and staffing.
16:54 <infinity> slangasek: The responsibility within the time period is obviously the same.
16:54 <infinity> (We talked a few flavours into dropping to 3 due to staffing)
16:54 <infinity> Anyhow.
16:55 <infinity> We're about to hit meeting end time for the first time in months.
16:55 <infinity> Which is scary.
16:55 <infinity> But potentially productive?  Yay.  We did a thing.
16:55 <stgraber> it'd have been nice to do the LTS review for flavors before release week as I expect a bunch of them would have been tweaking their seeds to reduce the number of packages they end up being responsible for
16:55 <infinity> Well, we planned to do a thing.
16:55 <stgraber> but that's something we'll have to do better for 18.04...
16:55 <slangasek> yes
16:55 <stgraber> I'd recommend we do the flavor approval before we hit feature freeze next time, leaves them time to shuffle bits around to reduce their package list
16:56 <mdeslaur> stgraber: +1
16:56 <slangasek> when all is said and done let's write that down somewhere so we remember to do it in 1.5y time ;)
16:56 <infinity> stgraber: Yeah.  Though, for most of them, the stuff they're supporting is "their DE", and not much to drop there.
16:56 <infinity> studio being a whacky outlier, but they love shipping every multimedia thing ever.
16:57 <stgraber> infinity: well, I'd have expected kylin to ditch evolution and chromium-browser, lubuntu to notice they were supporting ltsp and some other random bits, ... we fixed a bunch of those last minute in London, would have been nice not to have to do it so late :)
16:57 <infinity> stgraber: Oh, yes, the ltsp thing was lolz.
16:57 <infinity> And I fixed a bunch of kylin stuff due to their forked seeds.
16:57 * mdeslaur spits coffee at mention of chromium-browser
16:57 <infinity> But I think that takes us to notice, not them. :(
16:57 <infinity> kylin's seeds have been broken for 1.5y.
16:57 <stgraber> mdeslaur: http://people.canonical.com/~stgraber/supported-packages/lists/ubuntukylin.xenial
16:58 <infinity> The part where no Kylin people even seemed to notice when I fixed their seeds implies that they never would have noticed they were broken either. :P
16:59 <mdeslaur> ok, can we wrap up?
16:59 <stgraber> infinity: well, we should absolutely point them at those package lists before granting them LTS status and have them confirm that they will do x years maintenance on all of those, I guess at that point they'll go "wth is package XYZ in our list?" and start fixing stuff to have a more reasonable list :)
16:59 <infinity> Yes!
16:59 <mdeslaur> not that I don't enjoy talking with you guys :)
16:59 <stgraber> but anyway, that's 18.04 talks at this point
16:59 <infinity> stgraber: Agreed.
16:59 <stgraber> mdeslaur: getting a bit hungry? :)
16:59 <infinity> stgraber: We probably need to document community LTS processes in general somehow, but let's leave that for another meeting.
16:59 <mdeslaur> stgraber: and dizzy :)
17:00 <infinity> #topic AOAOB
17:00 <infinity> Going once.
17:00 <infinity> Going twice.
17:00 <infinity> #endmeeting