=== cpaelzer_ is now known as cpaelzer === genii-core is now known as genii [15:59] o/ [15:59] *yawns* [16:00] i have my opinions RE: your initial post ddstreet and i'll share here - been a busy week so i didn't get a chance to actually reply heh [16:01] sounds good yeah, one good thing about realtime mtgs is it lets you carve out a bit of time, otherwise it's really hard to make time for all the things [16:01] yup [16:01] welcome to my world where the work got busy this week xD [16:02] i'm cautiously optimistic this mtg might not be too long, i think we are all mostly in agreement on most things [16:02] mapreri you around for us to start? [16:02] aye [16:02] i also have a few questions re: clarificationof things too but :P [16:02] ok let's do the official first [16:02] again putting out fires at work so i'm probably going to rapidfire my concerns and statements first if you will let me [16:02] but I'd like to ask one thing: how is it that, technically, does one accept/reject packages in a launchpad queue? [16:03] #startmeeting Ubuntu Backporters meeting [16:03] Meeting started at 16:03:01 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:03] Available commands: action, commands, idea, info, link, nick [16:03] mapreri: we could ask anyone who might know, i.e. vorlon who I know does AA tasks for accept/reject stuff [16:03] but that's a separate discussion of what we'd need after implement. [16:03] oops meeting started :) [16:03] oh good, it felt like I was alone in having this technical doubt :D [16:03] just quickly for the record, we do have the action item of figuring out membership process/etc but i think we should punt that [16:03] lets push that until we have full details of how backports will work [16:04] and jump right into general discussion [16:04] k [16:04] i'll wait before i rapidfire my clarification requests/concerns for you to give me the floor :P [16:04] yeah re: accept/reject i think they use tools from the ubuntu-archive-tools repo https://pad.lv/p/ubuntu-archive-tools [16:05] i *think* we may have the ACLs now to do that? but i'm not sure, i of course haven't actually tried it yet [16:05] let's put an action to ask someone about it [16:06] #action clarify how to accept/reject uploads to -backports queues [16:06] ACTION: clarify how to accept/reject uploads to -backports queues [16:06] ok i'm done witht he floor, you guys jump in [16:06] ok so [16:06] first [16:06] back when I was championing this process BEFORE I was on all the boards with all the hats... [16:07] I had suggested that requests can ONLY come from developers willing to watch the package and handle sec updates, etc. to it. NOT the backporters team, so that Backporters simply have the request/reject. [16:07] I see references to torching the 'anyone can request' part of the existing process and to torch the entire current process which I agree with [16:07] but are we going to limit requesting backports for approval, etc. to people who have upload rights (which would then need accept/reject for backports pocket from us)> [16:07] but are we going to limit requesting backports for approval, etc. to people who have upload rights (which would then need accept/reject for backports pocket from us)? [16:08] and therein require a request still to be filed for *approval* with justification therein as to why, and that that developer has still done testing to validate the program/package will still function? [16:08] (I didn't see any explicit definitions to this point, either that or i missed it in the thread of discussions) [16:10] mh [16:10] we don't have such thing in debian, and I believe that, depending on the amount of requests, would still risk to be too much for us to handle [16:11] otoh, we might want to also prevent people from filling up the bpo pocket [16:11] I don't think we should require people to give us explanation unless we see something fishy going on [16:11] but of course, uploading implies that the uploader did test properly before [16:11] ack. [16:12] so we would be limiting it, then, to those who can upload the given package, just that it'd require us to approve/reject the upload? [16:12] and certain things would be rejected based on where it sits? [16:12] i'm happy to write down in the rules that in case somebody regularly uploads stuff that then comes out it's not actually working will then be prevented (by us, manually) to contribute again or so. [16:12] yeah I would suggest that, regardless, we dictate the rules and write it down [16:12] i think it's ok if someone wants to upload and finds a sponsor to upload for them, right? [16:12] that's where it gets tricky [16:13] as usual the sponsor is also responsible for not uploading shit [16:13] yeah [16:13] ddstreet: if a Sponsor uploads it that's fine, but then SPonsored is required to make sure relevant patches, etc. are submitted for critical security bugs [16:13] and as for scope of what people can upload, obvious things (core bits, etc.) are not permitted except in SPECIAL CASES [16:13] (there are special cases for certain openstack things I think?) [16:13] teward: that's the same of the rest of the archive, isn't it? [16:13] s/think/think already/ [16:14] mapreri: well technically [16:14] I'm a Core Dev [16:14] if I try and upload a kernel package, i'm pretty sure it might let me, despite not being on the Kernel team, i'd get hell for it thoug [16:14] * mapreri is planning on writing the application for thatt one of these days, btw. [16:14] so technically i can upload to any pocket [16:14] not that I WOULD but in case of certain things it'd raise Hell [16:14] so we need to be clear what 'not allowed to touch' is [16:15] sure, then what? :) [16:15] as long as Sponsor or Uploader isn't stupid anddoesn't abuse it it's not aprolbme, but it was discussed setting limits [16:15] for some reason neither debian nor ubuntu had the principle of least privilege applied to upload permissions :3 [16:15] i'd like those limits to be more clearly defined is all [16:15] mapreri: so i'm going to stop you there briefly. [16:15] on the basis of "We need to tread careful here" [16:15] whether upload rights are a thing or not [16:16] we need to set the standard for the scope of what Backports covers [16:16] or we're going to end up in Sqaure One of backports that we had that led to the death of Backports in general again [16:16] so my question is: do we have a clearly defined scope of what we will/won't permit to be put into backports? [16:16] that was part of what was in ddstreet's mail as well. [16:17] and there certainly wasn't one before, and it may be hard to come up with one [16:17] my take, is that we'll blacklist thing as we go. starting with stuff that is already covered by HWE, and the cloud archive. [16:17] i do agree the kernel should be excluded [16:17] but I wouldn't go with a whitelist, except for the non-LTS releases where we don't want to hassle. [16:18] HWE, Cloud Archive, snapd and things that underwent deb-to-snap transitions [16:18] HWE, Cloud Archive, snapd and things that underwent deb-to-snap transitions, packages that are so mission critical we can't update those without a full migration type task, etc. [16:18] (Python comes to mind here...) [16:18] yep [16:18] ack [16:18] it would probably be easier to add to the list as people request pkgs as mapreri is suggesting [16:18] (certain python3 *packages* which are just modules packaged up could be different, but I mean core python version etc.) [16:19] agreed. [16:19] I'd also blacklist compilers at large perhaps? [16:19] mapreri: agreed [16:19] PHP and Web scripting language versions as well [16:19] "interpreters" [16:19] (Server Team would balk at that if we tried ti push updated PHP to an older release, without them handling it) [16:19] mapreri: yep. [16:20] so we're all agreed to in principle having a list of excluded packages, that we update on an ad-hoc basis as a team? [16:20] BASICALLY< when we first get started, I want a known "This stuff will not be accepted", which we'll update a specific list going forward as a team [16:20] interpreters, core packages, stuff in Cloud archive, snapd, kernel, deb-to-snap packages, etc. would be automatically excluded to begin with. [16:20] (includes compilers) [16:20] so that we don't get innundated with requests for things that we wouldn't accept anyways [16:20] (sponsored or otherwise) [16:21] i suggest we move the specific discussion of what's on the list to ML discussion, as i suspect it'll take time [16:21] yes, we all seem in agreement on this. [16:21] yup [16:21] agreed we move specific discussion to the ML just wanted to make sure we had a basic thing of "this base category is a no-go" to start. [16:22] rather than point at specifics specifically [16:22] that's easily just a list in the wiki, let us subscribe to the wiki to make sure nobody mess with it, done. [16:22] #agreed maintain a list of excluded packages, to be updated on ad-hoc basis and/or updated from mailing list discussion [16:22] AGREED: maintain a list of excluded packages, to be updated on ad-hoc basis and/or updated from mailing list discussion [16:22] yep definitely, should just go into the wiki page [16:22] ddstreet: I think it would be best if you lead the discussion based on your agenda :) [16:22] ok [16:22] one more thing in my dossier then i'll be silent [16:22] lemme pull up the email [16:23] sure go for it [16:24] the security component is one thing I want to make sure we agree on: Neither the Backporters team nor the Security Team will be responsible for security updates and patches to Backported programs. Like security updates in Universe packages, it is up to the uploader (or sponsored individual) to make sure teh backported package receives relevant security patches and drive them to land in the backports queue for the package. [16:24] or similar wording, however we word it we make sure it's not our obligation nor Security obligation for items in -backports [16:24] (there will be exceptions I think in certain cases but generally speaking) [16:24] that's it on my radar for concerns/thoughts [16:25] I think both me and ddstreet are on the same page, according to the mail :) [16:25] just making sure ;) [16:25] +1 and i think we should also clarify to potential users of the package that neither our team nor the security team will monitor or enforce that the package requestor actually keeps it up to date [16:25] but [16:26] ddstreet: there may be exceptions if a specific team drives the backport [16:26] but at that point that Team would be monitoring it [16:26] (but yes in general principle I agree ddstreet) [16:26] we write clearly to users to not expect anything. otoh we write clearly to developers that we team expect them to do good and provide them. [16:26] #agreed ubuntu backporters team is not responsible for future security updates to packages, nor is the security team, the package requestor (and/or their sponsor) should expect to maintain it [16:26] AGREED: ubuntu backporters team is not responsible for future security updates to packages, nor is the security team, the package requestor (and/or their sponsor) should expect to maintain it [16:26] mapreri: agreed. [16:27] ok let me get to the agenda items from the email thread [16:27] #topic how the community requests backports [16:27] we can expect that a given team or developer driving a package in would know this, but we do need to write it clearly for users to see "There is no guarantees of stuff here" [16:28] ddstreet: -1 on 'community' requests in general, they have to do the work to get it sponsored for a backport upload, or a developer has to take that task, we should not just allow general 'requests' for backports. [16:28] my 2 cents (this was mentioned before in the email) [16:28] (but not by me) [16:28] +1 on updating the docs, and tooling, to reflect this [16:29] agreed, +1 on updating docs and tooling [16:29] ack. Though I'm fine if community write to the ML saying "I'd like this bpo, could somebody pretty please provide it", without expecting the service :) [16:29] mapreri: that's a given. [16:29] but probably best to just not talk about "requests" [16:29] but i think that should go to -devel-discuss [16:29] yeah i agree ML requests for help are fine [16:29] because at that point if they're *requesting* someone to backport it, then it needs to go to a point where a dev has to actually be interested [16:29] agreed on ML requests as well [16:29] just as long as they don't expect our team to do it [16:29] just my 2 cents it shouldn't be sent with the expectation of being done/responded to [16:30] there was such request in July fyi [16:30] to backporters? [16:30] https://lists.ubuntu.com/archives/ubuntu-backports/2021-July/021758.html [16:30] i think we should update our wiki page to clearly state the 'requestbackport' tool is deprecated, and also we should remove the tool from ubuntu-dev-tools package, to avoid confusion [16:30] ddstreet: agreed [16:31] I'd be for replacing it with a stub that print() a message and url to the wiki though [16:31] rather than removing it right away [16:31] i'm actually OK with that as well [16:31] do a transitional removal - replace the code with a warning [16:31] like we did for bitcoin when it was blacklisted/removed [16:31] s/bitcoin/bitcoin and bitcoind/ [16:31] ack, deprecation/stub is likely better [16:32] i also think we should reply to the July request and indicate that we are redesigning Backports and to check back once we've published updated processes and documentation [16:32] or at least wait until we have that stuff decided/published and then reply [16:32] they also filed a bug, so that can happen together with when we'll handle (somehow) all the open bugs [16:33] #action update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same [16:33] ACTION: update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same [16:33] either of you want to take an action to reply to the previous ML requests and/or bugs? [16:33] i can take it as administrative work otherwise [16:34] #action ddstreet reply to previous ML requests and open backport request bugs indicating change in process [16:34] ACTION: ddstreet reply to previous ML requests and open backport request bugs indicating change in process [16:34] i can take it, but not do it these few days [16:35] as you prefer [16:35] sure feel free to do it, i probably would not get to it for a couple weeks :) [16:35] well then, whoever starts first [16:35] i'll leave the action on me but not actually do anything for it [16:35] yep [16:36] ok i think we're cleared up on item #1, of how people initiate backports, right? [16:36] ye [16:37] i think we should have an action to clean up the wiki page with the new process steps, either of you want to take that? [16:37] ddstreet: if we have no objection to me updating the tooling i can handle tooling rejiggering for leaving requestbackport to just print the message [16:37] perfect go for it [16:38] atm I'd prefer to leave at least the first round of wiki cleanup to others [16:38] ok i'll take the first round of wiki updates [16:38] #action teward update tooling, requestbackport [16:38] ACTION: teward update tooling, requestbackport [16:38] #action ddstreet update wiki docs with new process [16:38] ACTION: ddstreet update wiki docs with new process [16:38] ddstreet: you can take it for the previous requests, but we could mass close all the old requests as "The Backports process has undergone radical changes and as such existing requests are being cancelled for resubmission under the new process" [16:38] just as a suggestion ;) [16:39] remind me which repo has the tooling? [16:39] ubuntu-dev-tools [16:39] been a while since i double checked (three upgrades in place XD) [16:39] thanks [16:39] #topic review of tooling, requestbackport and backportpackage [16:39] i think we covered requestbackport already [16:40] teward: in case you are going to open a MR for u-d-t, I promise to be quick to review it :P [16:40] i guess one of us should just review the code for backportpackage, teward you want to do that review to see if anything needs changing there? [16:40] mapreri: yep. we may need to push some updates to retroactive releases if it's released as a package in the repos though [16:40] ddstreet: yeah i'll handle that [16:40] #action teward review backportpackage tool [16:40] ACTION: teward review backportpackage tool [16:41] to my knowledge it's fine as it is, i still use it to backport packages even for PPAs when I do it, it's a fast way to snag from devel or SOURCERELEASE and prep for TARGETRELEASE regardless of if it's the main repos or not xD [16:41] (I just change it to not use -backports before upload to PPAs) [16:41] #topic what releases are allowed/required to backport into [16:42] *forks ubuntu-dev-tools to his account on LP to begin with* [16:42] ddstreet: i suggest LTS only, because interim releases only have 9 months of coverage. [16:42] as was stated in the email chain [16:42] teward: yeah, I can handle the SRUs later on myself [16:42] there may be exceptions where we have to accept for an interim release, again in edge cases [16:43] but in general I'd say to the LTSes only, not to interim releases [16:43] and not to LTSes that have entered ESM [16:43] so sounds like we agree on backports to interim releases are *allowed* on a case-by-case basis, but not required, right? [16:43] ddstreet: i would say 'yes' [16:43] #agreed backports to interim releases are allowed on case-by-case basis, but not required [16:43] AGREED: backports to interim releases are allowed on case-by-case basis, but not required [16:44] generally speaking the backport target should be an LTS release that has not entered ESM or EOL yet, in my opinion, with case by case bases for interim releases [16:44] I'd say that many dev tools are fine to have in interim releases [16:44] like, debhelper, pbuilder, u-d-t, devscripts, sbuild, …? [16:44] yep dev tools will likely be the most common thing in interim releases [16:44] me being involved in 3 out of the 5 above means I'm quite biased :) [16:45] yep [16:45] should we start a ML thread on dev tools that we may want to proactively put into -backports? [16:45] i think so, yes. [16:45] or rather, proactively approve you mean, because it's still not on *us* to make sure they're all backported [16:45] I'm happy to take the task of doing the first 4 of the above btw. [16:45] because, at the very least, I'd like to have them for my own use (!) [16:46] sure, though for the tooling it's quite possible one of us would actually be doing the work of uploading the tools [16:46] agreed [16:46] mapreri: if you also take sbuild I'll send you some beer [16:46] I regularly use sbuild in my test build envs and I like that being up to date xD [16:46] #action mapreri start ML discussion for list of dev tools to proactively put into -backports [16:46] ACTION: mapreri start ML discussion for list of dev tools to proactively put into -backports [16:46] all five of those stated are good candidates [16:46] but we'll move to ML for that [16:46] I don't use sbuild, so I can't really test it decently. but I'm sure plenty of people will throw me darts if I break it so I'll know very quickly heh [16:47] mapreri: if you can prep it and PPA it I can test [16:47] i gave you the action to start the ML discussion mapreri :) [16:47] sure (to both) [16:47] and of course, I don't think any tool has to be pre-discussed, it should also be fine just to upload something as long as another team member is the reviewer [16:48] this was more like pre-allowing things into interim releases [16:48] yeah [16:48] ok for this topic, we also should clarify the LTS->LTS and LTS->interim upgrades as briefly discussed in the ML [16:49] i think mapreri and i are in agreement on this [16:49] teward you as well? [16:49] agreed [16:49] ok let me try to capture it as agreed statement [16:49] no concerns there. [16:49] one thing we aren't sure on is [16:50] what to support: LTS+bpo → LTS², or LTS+bpo → LTS²+bpo ? [16:50] * ddstreet has thunderstorm outside fyi, hopefully i won't lose power [16:50] mapreri: as in source + destination? [16:51] and LTS^2 as in, "Previous LTS"? [16:51] as in supported upgrade path [16:51] oh [16:51] which also means which source to take from I suppose, yes [16:51] i think we can handle those slightly differently [16:51] but here's my thoughts [16:51] any later release can be a source even an interim to a given LTS's backports repo. [16:52] i.e. Impish -> CurrentlySupportedLTSes [16:52] but if you skip over an LTS it has to be supported in that other LTS as well [16:52] as for upgrade path, we should disable backports entirely, and whatever's in TargetRelease should be force-installed to supersede backports [16:52] right. but I want to be sure that whatever you backport is going to be upgradable to 22.04 then even if taken from impish (which should be the case) [16:52] because backports are NOT guaranteed to upgrade properly [16:52] that's what i just indicated here. [16:53] as my second point/suggestion [16:53] I don't want that [16:53] force-installing to supersede backports sounds like something wasn't done properly [16:54] why can't we guarantee proper upgrade paths? [16:54] mapreri: define the scope of "We" [16:54] I believe part of the check we need to do before approval is to make sure that the versioning is right. and we are going to consider a bug if an upgrade fail, bug that's going to be assigned to the last uploader. [16:55] that i agree, provided that the 'last uploader' (not the sponsor) is the one who handles fixing it [16:55] and yes, verifying versioning is right is critical for any approvals [16:55] so, why do you say "because backports are NOT guaranteed to upgrade properly" ? [16:56] we are not going to be responsible in the same way AA is not responsible for regular upgrade failures, are they [16:56] mapreri: well if you tried to upgrade my computer to Impish even if you could, Wireshark backported is 'newer' than the version in Impish right now on my system, and that means Wireshark could break [16:56] that's what i want to make sure [16:56] that it's not on the Backporters team to *fix* a broken package [16:56] that brings one other question: [16:56] ah yes, the only upgrade path starting from an LTS+bpo system is the next LTS [16:56] how do we guarantee the upgrade path if OriginalUploader has gone missing or has no more interest. [16:57] (short of removing the package from -backports which doesn't solve the problem) [16:57] I guess it "falls on the community" like for all the other packages in the archive? [16:57] i'm actually OK with that. [16:58] we're specifically talking about version numbers here, right? [16:58] more or less [16:58] more or less yess [16:58] more or less yes [16:58] blah i can't type to save my butt >.> [16:59] i think at the point of reviewing the backport, we can see if the LTS-backports version is < next-LTS version (both next-LTS-updates and next-LTS-backports) [16:59] i think that should be a hard rule [16:59] yes, we agreed on it [16:59] agreed [16:59] as long as that is a hard rule that should rule out edge cases. [17:00] and we are not going to support upgrades from LTS to interim [17:00] agreed, not for backports. [17:00] (which the current bpo rule support, btw) [17:00] works for me [17:00] right, if someone upgrades into an interim, it's undefined if their -backports version would remain or be replaced [17:00] but we should agree in only one of [17:00] "(both next-LTS-updates and next-LTS-backports)" [17:01] I mean [17:01] well next-LTS-backports should *always* be > next-LTS-updates [17:01] right? [17:02] so LTS-backports should, by rule, be < next-LTS-updates [17:03] so it means that backports can't span 2 LTSs? for example, backporting something from 22.04 all the way to 18.04. is it possible, or no? and if it is, we force people to *also* upload to 20.04-bpo? [17:03] for comparison, what the UCA archive does is just take the newer release package version and append '~cloud0' to force the version to be 'under' the version it's taken from [17:04] technically speaking I think for our purposes if we do a backport we need to include the target release codename/number [17:04] similar to how we have SRUs or updates that bump version numbers currently in all releases, we add on the version number in the version string [17:04] no i think backporting to multiple LTS should be ok, it should just follow similar versioning for srus, like if version 1.2.3 is backported to 18 and 20, then use versions '1.2.3~18.04.1' and '1.2.3~20.04.1' or something [17:04] yep [17:04] as teward said [17:04] yeah that way we can have the same thing in multiple releases, following SRU Versioning Behavior [17:05] that way if a later version shows up it'd still be superseded [17:05] we could probably require specific version formatting for backports [17:05] agreed. [17:05] mapreri sound ok? [17:05] right, so then the supported upgrade path is LTS+bpo → LTS²+bpo, not LTS² (ex. bpo). fine, let's write it down properly in the doc [17:05] so users are expected to *not* disable the bpo pocket from their sources. [17:06] i think it's ok either way for them to, isn't it? [17:06] if we allow backports from 2 LTSs away, it might not be ok for them. [17:07] even if it's not from LTSs away, just from the interim after the next lts [17:07] like bpo from impish to bionic, we mandate also a bpo to focal to preserve the upgrade path, and users of bionic+bpo needs to have focal+bpo to be able to upgrade. [17:08] first part i agree with, bpo to focal before or along with bpo to bionic [17:09] but if they upgrade b->f, and they had version 1.2.3~18.04.1 in b, and f has version 1.2.2, they'll keep version 1.2.3~18.04.1 even if they disable -backports right? [17:09] i supposed if there are changing dependencies/libs that might break if they don't upgrade to 1.2.3~20.04.1 [17:09] then they'll find themself with, if they are lucky, an out-of-repo local package. if they unlucky some Breaks will prevent them from fully upgrading. [17:10] neither of which is a proper system to have in my books [17:10] ok so we should require continuing to use -backports then, across release upgrades [17:10] i'm fine with that [17:11] cool [17:11] teward: are you fine too? [17:11] sorry my boss called. [17:11] i'm fine with that [17:12] #agreed LTS->LTS upgrades must be supported, and -backports should remain enabled/used [17:12] AGREED: LTS->LTS upgrades must be supported, and -backports should remain enabled/used [17:12] regarding the version string. are we going to keep using the same namespace as SRUs and sec updates like I believe in the past? [17:12] mapreri: i think we would have to, to avoid archive collisions, unless we intentionally want to update default policy to supersede backports, which sounds bads. [17:12] s/bads/like it'd cause more harm than good/ [17:13] I'm mostly used to debian, where backports use ~bpoX+Y, whilst SRUs ~debX+Y [17:13] we COULD use ~bpo-X.Y.Z if we wanted to be distinct [17:13] but we have to be careful we don't collide [17:13] which sorts nicely for them. if would for us as well, but honestly besides being nice to distinguish the source of the package with only one glance, there is no much benefit ime [17:13] i'm fine with requiring ~bpo version suffix [17:14] ddstreet: while also still providing the target version in the string in case the backport goes to two releases [17:14] (i.e. both current LTSes) [17:14] so we'd still have the bpo suffix but would stil be able to obey the versioning policy we already have used [17:14] so for example, if bionic had version 1.0.0 and focal had 1.2.3, a backport from f-> would be 1.2.3~bpo1 right? [17:15] or something like that? [17:15] i think that works fine [17:15] I'd hardcode the target release tbh [17:15] mmm, now that i think about it [17:15] we should hardcode the target release in the string too [17:15] right so 1.2.3~bpo18.04.1 [17:15] in some form, like ~bpo18.04.1 ? [17:15] ok yep [17:15] so ~bpo18.04.1 would be suitable [17:16] and must be present even if we're not sending to other releases. [17:16] also, backporting version 1.2.3-2ubuntu20.04.1 to bionic, how would that go? [17:16] (i.e., backporting from focal-updates) [17:16] wouldn't that just be ~bpo18.04.1 at the end of that then? [17:16] that could be confusing but it's a relevant question [17:16] that's also in my mind, I'm double checking with you :) [17:17] we might have to sit on that and think a bit, thoughts ddstreet ? [17:17] (launchpad doesn't have length restrictions in the version string right?) [17:17] (I'm running on the end of the 1 hour meeting and work needs me for a call) [17:17] #agreed backported package versions must use suffix ~bpo along with target release version and .1, or as refined in ML discussion and stated in wiki docs [17:17] AGREED: backported package versions must use suffix ~bpo along with target release version and .1, or as refined in ML discussion and stated in wiki docs [17:17] yeah let's defer the specifics of it [17:17] agreed, defer specifics for now [17:18] we should write a table with all cases like https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [17:18] agreed, once we get there. it won't all be decided in a single meeting [17:18] yes definitely [17:18] ok let's see if we can get thru the last 2 topics quickly, we're going long [17:18] #topic security updates [17:19] I think we already covered it above? [17:19] i think we covered this; the requestor/uploader is responsible for this [17:19] yep [17:19] #topic cleaning up wiki docs [17:19] i think we covered this [17:19] all the old 'enabling backports' stuff needs to be removed [17:19] and we'll update the wiki with the new process [17:20] oh and the last topic sorry [17:20] #topic restrictions on eligible packages [17:20] i think we covered this [17:20] and moved the details of it to the ML [17:20] right? [17:20] pretty much yes [17:20] i think we need distinct ML threads to follow up :3 [17:21] yep [17:21] ok i think we made it thru all the topics [17:21] how does one edit help.u.c btw? trying to log in myself gives a gateway timeout [17:22] i think only people on the doc team can edit it? [17:23] https://wiki.ubuntu.com/DocumentationTeam [17:23] https://launchpad.net/~ubuntu-community-wiki-editors so these? [17:23] 3 people? [17:24] oh, that's "editorial rights" which is the superpowers [17:24] For information on contributing see the Ubuntu Documentation Team wiki page. <-- so yeah refer to the Documentation Team's wiki for things? [17:24] and for proper contacts [17:24] (in the footer of help.u.c) [17:24] yep i think https://wiki.ubuntu.com/DocumentationTeam/Organization [17:24] for the various teams, looks like they have a few [17:24] https://wiki.ubuntu.com/DocumentationTeam/Contact has the contact mechanisms right now to use [17:25] they have a general mailing list we can use too and let them handle delegation to the proper subteam [17:25] so it's probably https://launchpad.net/~ubuntu-doc-contributors looking at the descriptions mh [17:26]