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