| infinity | Agenda says I'm the chair, but it also says the meeting is two weeks ago. Did I forget to update the wiki, or did I forget to attend? | 15:57 |
|---|---|---|
| slangasek | I don't think two weeks ago counted as a meeting | 15:58 |
| slangasek | you can have a mulligan | 15:58 |
| infinity | Having a quick "break" before we start. | 15:58 |
| mdeslaur | \o | 15:58 |
| mdeslaur | hi kees | 15:59 |
| kees | hola! | 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 | Available commands: action commands idea info link nick | 16:00 |
| infinity | #topic Action (action, ACTION, this Sunday only!) review | 16:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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 | ACTION: 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:39 |
| 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:40 |
| 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:41 |
| 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 | ACTION: 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 :) | 16:59 |
| infinity | #topic AOAOB | 17:00 |
| infinity | Going once. | 17:00 |
| infinity | Going twice. | 17:00 |
| infinity | #endmeeting | 17:00 |
| meetingology | Meeting ended Tue Apr 26 17:00:19 2016 UTC. | 17:00 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-04-26-16.00.moin.txt | 17:00 |
| slangasek | thanks! | 17:00 |
| mdeslaur | thanks everyone! | 17:00 |
| stgraber | thanks! | 17:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!