16:05 #startmeeting Ubuntu Backporters Team 16:05 Meeting started at 16:05:20 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:05 sure 16:05 Available commands: action, commands, idea, info, link, nick 16:05 let's first go over the previous action items, i think some are done and others we'll continue to carry over 16:05 #topic Action Items 16:06 ddstreet reply to previous ML requests and open backport request bugs indicating change in process 16:06 i didn't, but i think you did this one mapreri ? 16:06 well, the ML at least 16:07 no, I replied to one that came by last week 16:07 not to the old ones 16:07 ok let's carry this over 16:07 #action ddstreet reply to previous ML requests and open backport request bugs indicating change in process (carried over) 16:07 * meetingology ddstreet reply to previous ML requests and open backport request bugs indicating change in process (carried over) 16:07 ddstreet update wiki docs with new process 16:07 i *did* do this, at least with a draft 16:07 (though imho that really should be done after we get this ↑ one first) 16:07 #link https://wiki.ubuntu.com/UbuntuBackports 16:08 that page is still unchanged since 2012 herE? 16:08 yes i agree, we should have a template to respond to the old ML and bugs after we're done with the new process 16:08 really? 16:08 yes 16:08 did you forget to save or something? :O 16:08 i guess try reloading? it shows newer for me 16:09 oh werid... 16:09 yup, also in incognito it's unchanged 16:09 none of my changes show up in the 'info' list... 16:09 (I'm also subscribed to the pages, so it's hard to miss…) 16:10 do you see this at the top: NOTE: This process is undergoing change, the content below may be updated 16:10 yes 16:10 oh 16:10 wait 16:10 u.u 16:10 so i think it does have my changes...they just aren't showing in the 'info' tab for whatever reason 16:11 very weird, maybe there is some bug going on with wiki.u.c 16:12 trying to save a noop change to that page just has the browser hanging 16:12 anyway let's not review all of it now, i just edited it this morning based on our previous discussions...let's leave it for later review and ML or IRC discussion, or next mtg 16:12 assuming, of course, we can figure out how to get the page working ;-) 16:13 ok i'm going to carry over the action, i think there's still editing to be done 16:13 #action ddstreet update wiki docs with new process (carrired over) 16:13 * meetingology ddstreet update wiki docs with new process (carrired over) 16:13 (is the wiki broken?) 16:14 possibly :( 16:14 certainly something weird is happening there 16:14 *lets it spin, will bug IS later* 16:14 mapreri start ML discussion for list of dev tools to proactively put into -backports 16:14 carry this over? 16:14 I'll try to have a read of your wiki changes later tonight and yell at you if I read something weird :) 16:14 ddstreet: nope, I did it earlier :P 16:14 i know there was an action assigned to me, but my brain forgot because injury, so a reminder wouldn't hurt 16:14 great! 16:15 teward update tooling, requestbackport 16:15 so I suppose you could +1 it there, and if it's +1'd copy it over to the wiki 16:15 yep agreed 16:15 ddstreet: ack, i'll need a reminder of what we decided to make it do, but that's because my brain is totally whack 16:15 most of the stuff will be carried over I think 16:16 (we're entering a release cycle so we're all busy) 16:16 s/cycle/period/ 16:16 for requestbackport, i think we agreed to deprecate that and basically just have it print a message saying 'go look at our wiki page and dont use this tool anymore' 16:16 lets carry that over 16:16 #action teward update tooling, requestbackport (carried over) 16:16 * meetingology teward update tooling, requestbackport (carried over) 16:16 check that's easy 16:16 teward review backportpackage tool 16:16 this might be more work, i don't know what this tool does 16:16 carry over as well i assume 16:17 yep 16:17 that one needs to change the changelog version, specifically 16:17 #action teward review backportpackage tool (carried over) 16:17 * meetingology teward review backportpackage tool (carried over) 16:17 oh cool it's a python3 script 16:17 (unassigned) update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same 16:17 teward: yes, ubuntu-dev-tools is all python3 :) 16:18 i think this is done, based on my wiki changes, an in any case i think it's basically part of other action items 16:18 (brb just spiled coffee) 16:18 (unassigned) define details on handling members/leads who are no longer participating (carried over) 16:18 ddstreet: that requires contacting the doc team. at least I think it was referring to help.u.c, wasn't it? 16:19 ah right, ok let's do an action specifically for that page...i actually might be able to edit the help.u.c page directly 16:19 #action ddstreet try to edit help.u.c page https://help.ubuntu.com/community/UbuntuBackports 16:19 * meetingology ddstreet try to edit help.u.c page https://help.ubuntu.com/community/UbuntuBackports 16:20 #action (unassigned) define details on handling members/leads who are no longer participating (carried over) 16:20 * meetingology (unassigned) define details on handling members/leads who are no longer participating (carried over) 16:20 * mapreri tries to auth to help.u.c.... it seems that "ubuntumembers" allow editing of allof that 16:20 define process/procedure for adding new members (carried over) 16:20 #action (unassigned) define process/procedure for adding new members (carried over) 16:20 * meetingology (unassigned) define process/procedure for adding new members (carried over) 16:20 .oO( it even loaded buttons in Italian for some reason, even if my browser preference is english) 16:20 yeah we may all be able to edit the page, though i had trouble with long delays trying to log into help.u.c 16:21 it did take a while of browser loading yes 16:21 ok that's all the previous actions 16:21 #topic discussion 16:21 should I start a ML thread about memberships, or let's keep it to the next irc meeting? 16:22 ML is fine with me for sure 16:22 same 16:22 I created a page, similar to the DMB KB page that has info/references intended for use by team members https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase 16:23 #link https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase 16:23 in that case, I'll get a text that is good enough to go into https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase and propose it 16:23 perfect 16:23 #action mapreri propose text for membership process to add to KB page 16:23 * meetingology mapreri propose text for membership process to add to KB page 16:24 ok i had one detail i wanted to clarify about the process 16:24 which is? 16:25 before, the process was for people to open bugs against a specific backports project, like 'focal-backports': https://launchpad.net/focal-backports 16:25 yeah that's been an annoyance in the past 16:25 do we need to do anything though from a tech perspective to just use standard bugs? 16:25 i'd like to change over to doing something similar to the UCA team, for example in this bug: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1940456 16:26 Launchpad bug 1940456 in ceph (Ubuntu Hirsute) "[SRU] radosgw-admin's diagnostics are confusing if user data exists" [Undecided, New] 16:26 ddstreet: so you'd still like tracking bugs? 16:26 can't people just happily upload without bugs? 16:26 i think so 16:26 request: define UCA 16:26 (brainbleh) 16:26 sorry 16:26 UCA is Ubuntu Cloud Archive 16:26 ah 16:26 mapreri: i think it's going to be a case 16:26 where those who can't upload will need a bug 16:26 essentially, it backports select 'cloudy' packages from later releases to earlier releases 16:27 but those who CAN upload can upload without (but a tracking bug WOULD be nice for historic TIL purposes) 16:27 i think it would still be good to have a bug, just to track the upload, no? 16:27 I'd prefer having the tracking bug yes, but as part of standard bugs not as part of its own package. 16:27 those who can't upload likely need to find a sponsor, so that would follow the normal sponsorship procedure 16:28 mh 16:28 i think if we can keep close to the SRU process, it might make it easier for existing people who are used to that 16:28 I suppose we can 16:28 like, create a bug, add filled out template, prepare upload, then upload 16:28 and the upload should close the bug as well? 16:28 yeah 16:28 do uploads to -backports close bugs in LP? 16:28 i think that will need some tech work though 16:28 because i don't think -backports is tracked for that 16:29 only the main repos 16:29 s/main/standard/ 16:29 i think the ~ubuntu-sru team's tooling closes the bugs, but we could re-use their tooling 16:29 Isn't `queue` the one handling that? 16:29 though I guess we need to double check 16:30 possibly? yeah we need to go thru their tooling to see how it applies to backports 16:30 * mapreri looks at its ubuntu-archive-tool checkout from oct 5th 2020 16:30 happy birthday checkout 16:30 heh 16:30 the issue without having any bug to track uploads is if we have feedback or any questions, there's really no way to do that without a corresponding bug 16:31 well, no easy way that leaves a record 16:31 agreed, a bug for tracking should be needed 16:31 I suppose we can go and do the same as for SRUs (I never had anything to do with UCA, no idea of the workflow there) 16:32 I mean, I'm not thrilled about adding paperwork, but I can be convinced about using tracking bugs for uploads 16:32 also 1 bug for package/base_version? so backporting a given to multiple releases would have a single bug targeted? 16:32 we can revisit the need for a bug if it becomes clear there are cases where it's not needed 16:33 * mapreri looks at his `bzr pull` that lead to a THIS_REPOSITORY_HAS_BEEN_MOVED_TO_GIT 16:33 yeah, a single bug would cover backporting into multiple releases, with each release as a 'target' 16:34 so similar to this UCA bug: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1940456 16:34 Launchpad bug 1940456 in ceph (Ubuntu Hirsute) "[SRU] radosgw-admin's diagnostics are confusing if user data exists" [Undecided, New] 16:34 i envision instead of having 'affects' of 'Ubuntu Cloud Archive', it would have 'affects' of 'Ubuntu Backports' 16:34 why is it UCA but has [SRU] ? 16:34 and then it would have sub-tabs of each release to backport to 16:35 that particular bug is *also* a SRU 16:35 mh, how does this work 16:35 for us, it wouldn't have the 'affects' of 'ceph (Ubuntu)' 16:35 oh, so you mean bugs against the "ubuntu backports" project, instead of packages? 16:35 right, for SRUs, the bugs are against e.g. 'ceph (Ubuntu)' 16:36 for us, it would be against 'Ubuntu Backports', similar to how it's against 'Ubuntu Cloud Archive' 16:36 i'm a little confused, wouldn't that complexify the process? 16:36 Is there any benefit in having bugs filed against another project? 16:36 i don't really think so 16:36 UCA is a unique thing 16:36 yeah 16:36 backports is just the same basically as a standard SRU bug except targeting -backports 16:36 i think what we are going to do it very similar to UCA 16:36 also, for us views like https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs ought to be enough 16:36 It really shouldn't be 16:36 if we're going to redo the process I'd rather do a special Backports item but NOT a special project 16:37 i agree with mapreri here 16:37 packages uploaded to backports are expected to be the same of what is already in the archive 16:37 ddstreet: so, file the bug tag [Backports] and sub backporters to it. 16:37 we don't need the extra "assign it to UCA project" extra complexity 16:37 provided we require ubuntu-backporters to be subscribed to all backport bugs 16:37 like, I see this much more similar to SRUs than UCAs 16:37 hmm, i think we're misunderstanding each other 16:37 ddstreet: so you're combining "SRU" and "UCA" and confusing us 16:38 so let's start with the basic definition of any bog-standard SRU bug 16:38 let's start at step 1 - what specific URL do you see people going to when they want to open a backport bug? 16:38 ddstreet: the standard bug filing page for a given package? 16:38 i.e. bugs.launchpad.net/ubuntu/+source/SRCPKGNAME 16:38 and file a bug 16:38 the problem with that is, that will send an email to *everyone* subscribed to that package in ubuntu 16:39 ddstreet: and that's a problem how? They get SRU bugs the same way 16:39 except we'd have [Backports] 16:39 instead of [SRU] 16:39 and then that's for those subscribers awareness (like for SRUs) but not necessarily needing action 16:39 (let's call it [BPO] for pickyness and shortness pls) 16:39 (i'm talking theory not actual execution mapreri) 16:39 well that's certainly one way, but then people would just mark it as 'invalid' 16:39 ddstreet: unless everyone receives other guidance that it's not invalid 16:40 it's a process bug 16:40 since 'ceph (Ubuntu)' (for example) is only valid for SRUs 16:40 ddstreet: then we can't use the tooling to track backports and close bugs 16:40 we are creating a process here, that is used in the official ubuntu project. I don't see anything wrong with adding a process bugs to pacakges. 16:40 ^^ agreed 16:40 ubuntu contributors ought to learn a new teeny bit that bugs titled [BPO] or whatever are something 16:41 ignore current systems, we're creating new processes *based* on existing processes, but are a new process 16:41 ok, but we all agree that at the end once the bug is done, the '(Ubuntu)' targets will all be marked as 'wontfix' or 'invalid' right? 16:41 I also half-expect random ubuntu contributors to be interested in backports-specific bugs tbh 16:41 ddstreet: i'm not sure about that 16:41 because a "Fix Released" means a backport will have landed in -backports 16:41 that would "fix released" wouldn't it? 16:41 ouch 16:41 no, that means the bug/feature is fixed in -updates 16:41 ddstreet: for SRUs 16:41 that's for [SRU] 16:41 but we're creating a separate development process bug 16:41 for Backports 16:42 which means it would have independent definitions (bugsquad can update their documentation) 16:42 is ee 16:42 so you're thinking SPECIFICALLY for SRUs 16:42 this is a brand new process that is for backports 16:42 so 'Fix Committed' means uploaded to -backports, 'Fix Released' means it's built and published 16:42 but in -backports, not -updates 16:43 the problem is that *lots* of people subscribe to these packages and this process is kind of hijacking that 16:43 remember, there's a LOT of special bugs out there too like MIR bugs as well 16:43 which don't follow the standard processes either 16:43 i would expect a lot of complaints about emails 16:43 honestly, if I have to see tracking bugs, I would totally copy-paste from SRU, and just replace the "SRU" string into "BPO" (and a shorter and simpler template…) 16:43 ddstreet: would you prefer we defer to the TB for a suggestion on best approach here? 16:43 or at least query them for their opinion 16:43 you have some high expectations of people reading bug mails in ubuntu IMHO 16:43 well, i do see the benefit of just re-using the existing packages 16:44 (my opinion as a backporters team member carries the additional stigma of anything I say being read with the grain of salt of my other hats) 16:44 I spent the past 10 years groumbling about how nobody answers bugs in ubuntu… 16:44 grumbling 16:44 he lol 16:44 well that's true, emails are largely ignored from bug reports :) 16:44 my opinion is, it's just another dev process bug and MOST people ignore the bugs 16:44 ok i'm convinced then 16:44 hell I have at least 50 emails overnight for -sponsors that I'm ignoring 16:45 (and sponsors gets subbed to pretty much every bug with a patch / debdiff automatically) 16:45 I was in that list when I was an active sponsor, but then I figured it was better to unsub than add a filter... 16:45 so our process will be to open a bug against the specific package in ubuntu, and the subject should have [BPO] 16:45 right? 16:45 following a process and template we will define and document 16:45 correct 16:45 and upload at the same time (if there are no blocking reasons for) 16:45 correct 16:45 right yeah 16:46 #agreed BPO bugs will be opened against package in Ubuntu with subject prefix of [BPO] 16:46 AGREED: BPO bugs will be opened against package in Ubuntu with subject prefix of [BPO] 16:46 ok cool! i'll update the wiki page to reflect that, so ignore what i previously added to the wiki 16:47 that was the only clarification i wanted to talk about here 16:47 happy to sort this out 16:47 i'm actually pretty happy you guys convinced me to do that, it's better than what i was thinking :) 16:47 (and simpler) 16:47 yes 16:47 * mapreri will also be happier once we figure bugs are useless! \o/ 16:47 lol 16:47 lol 16:48 ok i guess one more clarification 16:48 mapreri: and where someone has no upload rights, then it needs -sponsors subbed 16:48 (which will then mean a coredev sponsor will need upload rights) 16:48 in the wiki, i'd stated that people should put a 'template' into the bug, explaining *why* the backport is needed 16:48 along with the test details, etc 16:48 s/upload rights/to upload/ 16:48 teward: or just get his core-dev friend to sign directly..? 16:48 do we think we need that info? 16:48 mapreri: dput wil explode 16:49 ddstreet: basic justification would be fine, as well as confirming that it builds as is in a backport 16:49 I'm not going to bother ~ubuntu-sponsors with all the core-devs I'm in contact with… 16:49 and any extra changes. 16:49 mapreri: well TBH there's overlap with me :P 16:49 ? what about dput? 16:49 so i can always prod the first dozen or so backport bugs :P 16:49 mapreri: well I think if you don't have access it doesn't have your keys in accepted dput 16:49 but i'll double check later 16:49 either case, there's a few ways to get it in 16:49 (irrelevant to the discussion) 16:50 ddstreet: If you request a backport without a basic justification then we run itno the problem of "Will we approve every backport request" 16:50 ddstreet: I agree to what teward said about the template btw. but keep it very simple, no need to be like the SRU one 16:50 if there's a basic reason for the backport even "I want a new version in the older version of Ubuntu" that'd be sufficient 16:50 provided a basic "This builds" confirmation or such 16:50 teward: that said, do you like the justification: "I'd like to run newer X on my own machine"? 16:50 we *really* don't need a complex template here. 16:51 I regularly do such backports in debian for my own benefits u.u 16:51 ack, ok - i kept it similar, but we can change it; i put it into the wiki page, so we cna discuss the details of the template later in ML 16:51 mapreri: well i'm using a very basic example :P 16:51 but yes 16:51 mapreri: but i'd also read that with a grain of salt and point at a PPA if they just want newer but have no intention to keep an eye on it 16:52 ok, let's just hope we 3 have some common sense when it comes to it i suppose 16:52 (so we should probably have a KB entry there that says "While backports gets newer versions into older Ubuntu releases, they do still need to be maintained. If you are just wanting the newer version but have no intention to maintain it from an updates / security perspective, consider building the package in a PPA just for yourself instead." 16:52 or similar) 16:52 lol, someone wanted the latest glibc, nothing wrong with backporting that right? xD 16:52 lol 16:52 ddstreet: that's on the list of "Not happening" that we already mentioned last meeting 16:52 toolchain packages are not allowed for backports 16:53 right, where is the action item about "blacklisted packages"? 16:53 bundled with you rewriting the wiki? 16:53 mapreri: i don't think we came up with the list, or rather, documented it 16:53 ^^ that 16:53 let's action item that specifically 16:53 we spent like 20 minutes on it last time *over* meeting time on that topic alone 'cause i'm a persistent SOB 16:54 #action (unassigned) create list of packages excluded from backporting (carried over) 16:54 * meetingology (unassigned) create list of packages excluded from backporting (carried over) 16:54 ^^ alternatively "list of certain types of packages" 16:54 we should probably do that in the ML, along with the pre-approved list 16:54 because otherwise that's an insane list :P 16:54 I'll see if I can do that, but don't assign to me directly 16:54 we can discuss via ML 16:54 (i mean, starting it) 16:55 changing topic, I reckon none of you tried `queue` from ubuntu-archive-tools right? 16:55 yeah i think we're quite close to getting the process nailed down enough to do most of the discussion over ML 16:55 i have not yet 16:55 either of you tried it yet? 16:55 mapreri: E:NOTIME 16:56 esp given injury last wednesday in the middle of the week 16:56 I seem unable to find a flag to tell me about pockets != release 16:56 which totally fubar'd my weel 16:56 week* 16:56 yeah, i suspect we might need to update or fork some of their tooling for use with backports 16:56 yep 16:56 (I'm gonna go nip out and pick up lunch, anything else to discuss?) 16:56 considering that I'm unable to get the "proposed" pocked either, I suppose it's PEBKAC 16:57 nothing else from me, should we wrap up? 16:57 yeah, let's 16:57 yup 16:57 i assume i should schedule another mtg in 2 weeks? 16:57 please 16:57 yep 16:57 will do 16:57 thanks! 16:57 #endmeeting