20:00 <amurray> #startmeeting Ubuntu Technical Board
20:00 <meetingology> Meeting started at 20:00:57 UTC.  The chair is amurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
20:00 <meetingology> Available commands: action, commands, idea, info, link, nick
20:01 <seb128> hey
20:01 <amurray> #topic Apologies
20:02 <amurray> sil2100 emailed earlier to say he couldn't make it, but everyone else is here :)
20:02 <amurray> #topic Action review
20:02 * amurray (everyone) review the Ubuntu Backports Team Charter for ratification
20:03 <seb128> I sent an email about that on the list since I'm a bit confused by what we need to review exactly?
20:03 <rbasak> Maybe I can try to explain my perspective now
20:03 <seb128> please
20:04 <rbasak> It's been brought up in a few different places that it would be helpful to have better documentation about exactly what is delegated by TB to other teams.
20:04 <rbasak> The DMB, release and archive teams' "undocumented delegations" have been been brought up in the past couple of years for separate reasons.
20:05 <rbasak> When we resurrected the backporters team, I thought it'd be helpful to have a similar text, and I suggested that in the original resurrection thread on ubuntu-devel@
20:05 <rbasak> Well, the text. Not specifically that it should be formalised at I thought that premature at the time.
20:05 <rbasak> In time, I suggested this to the backporters team, and it turned out that they were working on some similar text.
20:06 <rbasak> But their (specifically ddstreet's) idea of what that should be differed from mine.
20:07 <rbasak> They wanted to have text to define what I consider to be their "internal" operations. IMHO, the details of how they do things should be up to them, and the TB should leave teams to "get on with it" with minimal interference. Therefore, that stuff does not need to be and should not be ratified by the TB.
20:07 <rbasak> So the backporters team made that page empty, and moved their internal operations documentation elsewhere.
20:07 <rbasak> But, I still think it would be useful to have some text that defines the team's responsibilities to the rest of the project. I think my original text is still appropriate for that.
20:08 <rbasak> ddstreet disagreed in a TB thread. I'll find the link shortly.
20:08 <rbasak> So that's the current status.
20:08 <seb128> so where is your original text? and is that we need to review or does someone (who?) need to turn that into a proper document first?
20:08 <rbasak> #link https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html
20:08 <amurray> Is it a requirement for the backporters team to have a charter at all for them to function?
20:09 <rbasak> Here's the original text: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html
20:09 <rbasak> Here's where I proposed that text to the backporters team: https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html
20:10 <rbasak> amurray: I got the impression that they preferred to have one, but I think what they wanted was IMHO more an internal thing and not a TB matter. I believe they're proceeding with their own internal documentation instead.
20:11 <amurray> fwiw I think that your proposed text looks quite reasonable - I recall there was some objection to things like "making sure that all requests receive an appropriate answer in a reasonable amount of time" - but I can't really understand why
20:11 <rbasak> The reason I want it is because I think it's a useful thing to have for all teams, and it's been an issue on a few different occasions that there isn't some text to refer to.
20:12 <rbasak> I'd like for us to make progress in that direction, and because the backporters team resurrection was quite recent, I had that in mind and wrote it at the time, and in the original thread everyone seemed to agree with the text as I'd written it.
20:13 <amurray> rbasak: to allow this to try and make some headway, how would you feel if we proposed to them your text from above but without the few bits that they objected to ("reasonable amount of time" etc)?
20:15 <rbasak> Sure. I'm not sure how to do that without removing the text entirely. I'm disappointed that they seemed unable to make any kind of counterproposal or propose any edits to my text. But if we can make progress that way, then sure. I'm not precious about my precise text. But...
20:15 <rbasak> ...most of what I wrote there were specifically about what failed with the backporters team previously which led to the need for it to be resurrected.
20:15 <rbasak> Like reviews were piling up and not being done in a reasonable amount of time - hence that bit of my text.
20:16 <seb128> one issue is that a such statement isn't really helping in resolving the issue if that's due to lack of manpower
20:17 <rbasak> And some people who happened to have suitable privilege were then bypassing the previous backports review process, which I think is really bad procedurally because I don't want to see any part of the archive becoming de-facto exclusive like that.
20:17 <seb128> you can't really force a volunteers' based team to commit to be able to be responsive
20:18 <rbasak> seb128: sure. but if they don't have the manpower and that means they can't meet their responsibilties, then the matter *should* be escalated to the TB to decide what needs to be done about it, and so it's entirely appropriate to identify that they aren't meeting their responsiblities. So it's right to have that in the text.
20:19 <rbasak> But yes, as volunteers, we can't hold them to it, and I am definitely not seeking to blame individuals should such a case arise again.
20:20 <rbasak> To take another example, let's say that community-contributed SRUs stopped getting processed entirely.
20:20 <rbasak> In favour of Canonical-priority SRUs only, with the SRU team currently happening to be entirely Canonical-staffed.
20:20 <rbasak> That would be a matter for the TB to intervene in, IMHO.
20:21 <rbasak> So it would be right for the TB to say that the SRU team has that responsibility.
20:21 <amurray> rbasak: sure but even if does get escalated to the TB, I am not sure there is a lot we can do about it - we are unlikely to be able to find more volunteers to get more resources for the team
20:21 <rbasak> Even though the SRU team is currently staffed entirely by Canonical-employee "volunteers" as far as the Ubuntu project is concerned.
20:21 <seb128> right, explained like that it makes sense to me
20:22 <rbasak> amurray: sure. Then it'd go back to my original thread, where I proposed to acknowledge that and officially sunset the backports pocket.
20:22 <seb128> but do we need that written down for the TB to be able to exercice that right anyway?
20:22 <rbasak> With hindsight, I think it would have helped.
20:22 <seb128> I think that's a project level expectation that the TB take action to fix any of the non working teams
20:22 <rbasak> In the case of the backports pocket, there were multiple previous posts to ubuntu-devel@ and it dragged on for years.
20:23 <seb128> well it would have been in the power of anyone to bring the topic to the TB
20:23 <rbasak> Had the text been there presently, I think there would have been far less friction in a TB escalation and intervention much earlier.
20:24 <seb128> right, it could help to make people more entitled to raise up the issue to the TB
20:24 <rbasak> For example, we had people volunteering to do backports review, but the backporters team admins were absent.
20:24 <seb128> not that the lack of such statement would personally stop me, but I see how it might be different for others
20:24 <rbasak> I think it would have been easier for those volunteers to say "look, based on this text the team weren't meeting their responsibilities, and I'm volunteering, so..."
20:25 <seb128> right
20:25 <rbasak> I hope that explains my reasoning.
20:25 <seb128> thanks for the explanation, and I think that seen from that angle it makes sense
20:25 <rbasak> Anyway, I'd appreciate any help in breaking the current impasse.
20:25 <rbasak> But I think it needs other TB members to get involved in that thread.
20:26 <amurray> yep I agree with all your points rbasak but I think we need to find some way forward here - I'll see if I can draft something which is a little less "SLA"-like and send it to the backporters team
20:26 <seb128> I think it would help if you posted the proposal again so we have a logical/recent base to reply to
20:26 <rbasak> amurray: please! I'd appreciate that.
20:26 <seb128> amurray, +1 from me
20:27 <amurray> #action amurray to propose amended Ubuntu Backporters Team Charter
20:27 * meetingology amurray to propose amended Ubuntu Backporters Team Charter
20:27 <rbasak> Thanks!
20:27 * amurray rbasak to finalize third-party seeded snap security policy
20:27 <rbasak> I continue to work on this.
20:27 <rbasak> A couple of requests.
20:28 <rbasak> seb128: could you please help draft an exception to the "must build on all architectures" requirement for snaps in the case of non- desktop support for specific architectures? I think you might best understand what that should look like.
20:28 <seb128> rbasak, yes
20:29 <rbasak> Thanks!
20:29 <seb128> #action seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
20:29 * meetingology seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
20:30 <amurray> thanks
20:30 <rbasak> And second, I'd like some help with writing a description of how snaps work wrt. the store and the Ubuntu-specific tracks, which I'm not sure I fully understand. In this section: https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit#bookmark=id.tbw4pletjt3g
20:30 <seb128> I could help with that as well, unless amurray wants to do it :)
20:31 <rbasak> Thanks. What I mean for example is that for example on 22.04 firefox tracks latest/stable/ubuntu-22.04, and I think that's the mechanism that implements some of the requirements, and we should document how that occurs.
20:31 <rbasak> Meanwhile I'll continue cleaning up the rest of the feedback. I just got stuck on those two so far.
20:31 <amurray> I can try help but having not used branches much before I may not be as knowledgable - but I can certainly try and propose something if needed
20:33 <rbasak> sil2100 might also be able to help with this one, but he's not here right now.
20:34 <seb128> #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
20:34 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
20:34 <amurray> hehe thanks seb (I wasn't sure on who to assign that to)
20:34 <seb128> :)
20:34 <seb128> I will try to own it but will welcome input from you and Lukasz
20:34 <amurray> thank you
20:35 <amurray> rbasak: do we still need a general action in the minutes around the policy as a whole?
20:35 <amurray> or do you want to wait until these two new actions make some headway?
20:36 <rbasak> amurray: I think maybe we should have a general topic for us to discuss any blockers, and just those specific actions for now? We can clean all the others up.
20:37 <amurray> #action rbasak to raise any on-going blockers with third-party seeded snap security policy
20:37 * meetingology rbasak to raise any on-going blockers with third-party seeded snap security policy
20:37 <rbasak> +1 thanks
20:37 * amurray sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
20:37 <amurray> sil2100 is out so lets carry this over
20:37 <amurray> #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
20:37 * meetingology sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
20:37 * amurray rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
20:38 <rbasak> Still pending - carry over please.
20:38 <amurray> #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
20:38 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
20:38 <rbasak> (I expect to carry for a while, until the third party repo requirements block on me less)
20:38 * amurray amurray to figure out next steps to improve TB processes previously discussed - and to figure out what the previous discussion was about
20:39 <amurray> ok so looking back over the history, this was raised by Fallen from the community team - wanting a way for the community to be able to follow long with the longer term work of the TB
20:39 <amurray> it was suggested to use a separate LP project with bugs to track each of the work items
20:40 <amurray> I notice there is already a techboard project on LP, and this has only ever had a single bug reported against it - so I wonder if we could just reuse that - and as far as a process for this...
20:40 <rbasak> Right. IIRC we were all happy with that, but it needed some effort from someone to set up all the details.
20:40 <rbasak> Yeah, and that was mentioned too.
20:40 <amurray> My suggestion would be to have a bug for each longer term item in the agenda - how we decide what meets this "longer term" criteria is uncertain though - but this would give a way for anyone to see what is happening more easily and to subscribe to bugs for the project etc to get notified of new items
20:41 <rbasak> Oh I didn't know about the techboard project actually
20:41 <rbasak> We also have https://bugs.launchpad.net/ubuntu-community/+bugs with the idea that bugs could be assigned to ~techboard. But it turns out not everyone can do that.
20:42 <vorlon> in previous TB meeting I believe we agreed to move to a project to solve the problem of assigning bugs under ubuntu-community
20:42 <vorlon> but the execution was lacking
20:42 <rbasak> I guess we could re-use the techboard project then, rather than create a new one/
20:43 <rbasak> ?
20:43 <amurray> sure, one less hurdle
20:43 <vorlon> that would be nice
20:43 <rbasak> It looks like we own it, so no ACL issues
20:44 <amurray> regarding the question of which items qualify for LP bug tracking, how about we said something like 'if an item is carried over more than twice then a LP bug should be created in the techboard LP project to track this work'?
20:44 <vorlon> +1
20:45 <rbasak> Sure
20:45 <rbasak> Sounds like third party repo requirements needs tracking
20:46 <rbasak> As well as my DMB inactivity expiration policy item
20:46 <amurray> +1
20:47 <seb128> +1
20:47 <amurray> one final detail - should we stipulate that the meeting chair creates these bugs or the owner of the action item?
20:47 <amurray> (perhaps it doesn't matter but I think making the process clear is useful)
20:48 <amurray> I personally prefer saying the meeting chair should, since they will already be updating the agenda wiki page
20:48 <seb128> I would prefer the item owner, that's probably the person understand best the details
20:48 <seb128> sorry :p
20:48 <seb128> +who
20:48 <rbasak> I have no strong opinion.
20:49 <vorlon> seb128's response makes sense to me
20:49 <rbasak> If you wanted, you could make it a separate action item - then the task could be assigned easily at the time.
20:49 <amurray> hehe no worries - I don't feel strongly either way either really I just prefer to have something written down, otherwise its too easier to have things fall through the cracks
20:49 <amurray> rbasak: do you mean a standing action item in the agenda?
20:50 <rbasak> No, I mean add an action like "amurray to create the <x> bug"
20:50 <rbasak> But seb128's answer also works, if everyone's happy with that.
20:50 <rbasak> And would be less admin.
20:50 <amurray> yeah lets go with that
20:50 <amurray> (ie seb128's proposal)
20:51 <amurray> #action rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies
20:51 * meetingology rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies
20:51 <rbasak> ack
20:51 <amurray> thanks
20:52 * amurray vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.
20:52 <vorlon> carry-over, sorry.  I'll try to get that done this week
20:52 <amurray> #action vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.
20:52 * meetingology vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.
20:52 * Eickmeyer is biting at the bit
20:52 * amurray sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.
20:52 <amurray> carry-over
20:53 <amurray> #action sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.
20:53 * meetingology sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.
20:53 * amurray vorlon to request change of the meeting weeks for the TB meeting starting February
20:53 <amurray> I recall we discussed this last time?
20:53 <vorlon> I think this was just pushed so that I wouldn't break the calendar confusingly before today's meeting
20:53 <vorlon> so I'll push the next meeting out a week on the calendar
20:53 <rbasak> +1
20:53 <amurray> thanks
20:54 <amurray> #action vorlon to push the next meeting out a week in the calendar
20:54 * meetingology vorlon to push the next meeting out a week in the calendar
20:54 <vorlon> (done)
20:54 <amurray> oh thanks
20:54 <amurray> #undo
20:54 <meetingology> Removing item from minutes: ACTION
20:54 <amurray> #topic Scan the mailing list archive for anything we missed (standing item)
20:54 <vorlon> this is why we need to get fresh blood on the TB from time to time, I had no idea there was an #undo command :P
20:55 <amurray> :)
20:55 <rbasak> What, you mean you don't read the instructions you get given every time you chair? :-P
20:55 <amurray> the main thing here that I saw was the xubuntu minimal image announcement from vorlon - so other than now being aware of this, does the TB have to officially ack this? I thought it was more an informational thing
20:56 <rbasak> I think we agreed it's just an informational thing.
20:56 <vorlon> I believe the agreement was that this was informational
20:56 <rbasak> Unless an individual TB member has any objection.
20:56 <amurray> nice - sounds like there is no objection :)
20:56 <rbasak> (or someone else escalates one I suppose)
20:56 <rbasak> :)
20:57 <amurray> #topic Check up on community bugs (standing item)
20:57 <amurray> nothing new here
20:57 <rbasak> This standing item might need to change with the new bug system
20:57 <amurray> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
20:57 <rbasak> But that can wait I guess
20:57 <amurray> rbasak: tag you're it :)
20:57 <rbasak> ack
20:57 <amurray> #topic AOB
20:59 <amurray> last call?
20:59 <vorlon> nothing here
20:59 <seb128> nothing from me
20:59 <amurray> no worries
20:59 <rbasak> Nothing from me.
20:59 <amurray> #endmeeting