19:01 <mwhudson> #startmeeting Technical Board Meeting
19:01 <meetingology> Meeting started at 19:01:54 UTC.  The chair is mwhudson.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:01 <meetingology> Available commands: action, commands, idea, info, link, nick
19:02 <mwhudson> #topic Action review
19:02 <mwhudson> #subtopic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over)
19:02 <teward> Carry over
19:02 <mwhudson> (is it even worth having this on the action review list still?)
19:02 <teward> No its not
19:03 <teward> Mqybe keep it on the list of items we don't regularly review but keep tabs on from time to time
19:03 <mwhudson> ok. how do we backburner it, make a techboard bug or something?
19:03 <rbasak> We'll need it resolved before the next TB election though
19:03 <rbasak> It's a CC matter really
19:04 <teward> Yeah and i'll prod the CC again about it
19:04 <mwhudson> so i guess just drop it from the agenda and it will reappear when the CC has done their bit?
19:04 <teward> Yeah
19:04 <mwhudson> ok
19:05 <mwhudson> #Action review all to spend some time looking at https://github.com/ubuntu/ubuntu-project-docs/pull/446
19:05 * meetingology review all to spend some time looking at https://github.com/ubuntu/ubuntu-project-docs/pull/446
19:05 <mwhudson> i have not done this, sorry
19:05 <rbasak> I fear that the next TB election will be delayed by this kind of thing :-/
19:05 <rbasak> I don't have any alternative suggestions though.
19:05 <mwhudson> rbasak: we have about 9 months until then?
19:05 <rbasak> Yep
19:06 <mwhudson> given the lack of other topics, i was going to propose that we spend the time we gain from a short meeting looking at this PR but ...
19:07 <seb128> mwhudson, teward didn't update the wiki after the last meeting, you want to check the actions from https://irclogs.ubuntu.com/2026/04/07/%23ubuntu-meeting.html rather. We did discuss the policy PR while you were not there
19:07 <seb128> though there is follow up
19:07 <seb128> I replied on the PR with the outcome from the previous meeting
19:07 <mwhudson> ah the action is "ACTION: seb128 to discuss with Simon and Robert on the PR and outside of the PR on the way the TB wants to move forward with this proposal."
19:08 <seb128> Robert and Simon replied to our arguments so I think we can discuss again next steps
19:08 <seb128> so maybe if you didn't read their reply yet take a few minutes to do so?
19:08 <mwhudson> ok
19:09 <rbasak> I did read it but let me check my opinion against what is actually written rather than relying on memory :)
19:11 <rbasak> IMHO, we discussed the same pros and cons in our previous meeting that Robert and Simon responded with. I don't see new arguments or information that we didn't already consider.
19:11 <rbasak> It's certainly subjective as to how to proceed, but I think we already did decide.
19:11 <rbasak> And while I'm open to changing my mind, I don't see anything in those comments that I didn't consider before.
19:12 <rbasak> I'm still open to delegating the review task to someone else I would consider qualified, which is essentially a "senior" core dev. There are plenty around, but AIUI none of them are available.
19:13 <rbasak> I think that means we have nobody to review this PR, and the only way we have to go forward is to use the method previously agreed that will not require such a big review at once.
19:13 <rbasak> Robert is from my perspective asking to proceed without review, not even by someone qualified delegated by the TB. I don't think that's OK from a governance perspective.
19:14 <rbasak> I would also note that while I would like it improved, the policy docs in the package where they are right now are not causing a problem, so I'm not worried if it gets left as it is for a while.
19:15 <rbasak> Therefore, why do we need to risk proceeding without review?
19:15 <seb128> well, one proposal he has is to merge in a staging and move parts out of staging as they get reviewed
19:15 <seb128> where staging is no published
19:15 <seb128> not
19:15 <mwhudson> i don't have a problem i think with dumping a translation of the sgml into restructured text into the repo into the unpublished staging area and then going from there
19:15 <seb128> so technically it mean we could review commit by commit comparing to what has been merged
19:16 <seb128> and move pages/sections one by one
19:16 <rbasak> I think we discussed that last time, didn't we? It would work, in the sense that if we make it clear that the staging isn't agreed to be policy, then I don't mind what goes on in there. However, that just moves the problem to having a big chunk of review to move from staging to "official", but we'd be making the problem even bigger over time. If we do not have the capacity to review it today, how
19:16 <mwhudson> debian-policy upstream is restructured text as well now isn't it? (or is it markdown?)
19:16 <rbasak> are we going to have the capacity to review the even bigger chunk in the future, especially when it's in a state that is harder to review because the connection from the original approved policy package will have been lost?
19:17 <seb128> I don't really see what makes what they propose harder to review
19:18 <seb128> we would still need to split the current package delta in rich history
19:18 <rbasak> The git-ubuntu logical delta method would mean that I only need to review a delta and a small piece of text that carrie it forward.
19:18 <rbasak> Oh, OK.
19:19 <seb128> as I see it we would still do the git-ubuntu rich history split
19:19 <rbasak> So I'm going to see a PR at a time, one per logical delta, after we've reviewed the logical delta to be accurate?
19:19 <seb128> that was my alternative proposal
19:19 <rbasak> Then that's fine, but in that case I'll be completely ignoring the staging in my reviews. I'll care only to review the commit from the logical delta against the text that is being proposed to land in "official". In that case, what difference does it make whether we land this PR into some staging place or not?
19:19 <seb128> we merge in staging, still split the package in rich history and each commit match a page that is PRed to be moved out of staging to be published
19:20 <seb128> I don't really see the difference either, but Robert and Simon seems to care
19:20 <mwhudson> i think this makes sense
19:20 <seb128> maybe because they feel like the work they did until this point is not waster somehow
19:20 <seb128> ?
19:20 <seb128> wasted
19:21 <rbasak> From my POV then, "staging" and Simon's personal branch would be identical. I won't be paying attention to either. Neither will reflect any official position or endorsed by Ubuntu in any way.
19:21 <seb128> correct
19:21 <rbasak> The docs team are welcome to do that with or without the TB's agreement, IMHO.
19:21 <seb128> we would still review one section at the time compared to the rich history when moving them to the published section
19:21 <seb128> ok
19:22 <seb128> well, we have the Canonical sprints coming, so we can have a in person discussion there
19:22 <rbasak> So I'm fine with this, but I don't think it's the TB's role to agree to it, either.
19:22 <seb128> but I want to make sure to understand the other board members position before
19:22 <rbasak> (formally, I mean)
19:22 <seb128> ack
19:22 <seb128> mwhudson, teward: opinions?
19:22 <rbasak> Informally, sure, we want to make progress, and we can signal that this is fine if they want to do it that way.
19:23 <rbasak> Although IMHO, since I'll be ignoring that branch in future reviews anyway, I want to be clear that I don't think it's useful!
19:23 <seb128> ok, then I suggest that I keep an action item to talk with them and I will come back with an update next time
19:23 <rbasak> Though I very much favour those doing the work to decide how they want to do it, so they're free to do it on that basis :)
19:23 <seb128> (for sprint reasons I'm going to miss the next meeting BTW so that will be for the one after)
19:24 <mwhudson> do we need to give robert and simon some hints to come up with a plan that we would be happy with?
19:24 <teward> See i am on the fence
19:25 <mwhudson> i definitely do want to see the ubuntu policy on docs.ubuntu.com with content the TB can stand behind
19:25 <teward> Especially since Robie is right, staging and 'their branch' are identical.
19:25 <teward> It doesnt let us see the difference between original and what's been 'updated' as easily
19:25 <mwhudson> i have some opinions about how we represent the differences between ubuntu and debian policy as well
19:25 <teward> So I'm sort of split on opinion here.
19:26 <mwhudson> i think landing the policy into staging probably does make it easier to work on this incrementally
19:27 <mwhudson> noone is ever going to be able to review a PR that seeks to get the whole policy text approved in one shot
19:27 <mwhudson> it's almost like we need staging/staging, a series of PRs to move things to staging/approved and then a final one to move everything to somewhere that gets published
19:27 <seb128> well, the suggestion we came up in the previous meeting was to split in rich history and start from scratch submit one commit at the time
19:28 <mwhudson> ah i see
19:28 <seb128> also not trying to merge the Debian policy
19:28 <seb128> but just state "it is the Debian policy, that you can read there, with those changes on top"
19:29 <teward> Right but it seems to me that suggestion wasnt accepted or understood when we went back about this
19:29 <teward> Essentially what they are asking isnt what we suggested
19:29 <teward> And leaves us at the same problem.
19:29 <seb128> no, I think they invested enough in the current PR that they have difficulties to drop it, which I can understand
19:29 <teward> Whether in 'staging' or not
19:29 <mwhudson> maybe we should defer everything until robert and seb and simon and i can meet in person
19:30 <seb128> right, let's have an higher bandwith discussion in person at the sprint
19:30 <mwhudson> robert and simon and i will be in the same room for a week so this shouldn't be hard to make happen
19:30 <seb128> so let's carry over, try to come to an agreement there and follow up at the next(-next-)meeting
19:31 <teward> +1
19:32 <mwhudson> #action seb128 and mwhudson to talk to docs team at sprint, follow up at 2026-05-19 meeting
19:32 * meetingology seb128 and mwhudson to talk to docs team at sprint, follow up at 2026-05-19 meeting
19:32 <seb128> ok, great, let's move on then :)
19:32 <mwhudson> #topic Scan the mailing list archive for anything we missed (standing item)
19:32 <rbasak> FWIW, I find that a bit frustrating
19:32 <rbasak> It's a 3000 line diff.
19:33 <rbasak> I don't think we've misled them here. It's just normal in our ecosystem to not be able to get such a PR through, ever, unless you're already an experienced contributor to a project.
19:33 <rbasak> That's a lesson everybody new to our ecosystem has to learn.
19:33 <rbasak> I appreciate the difficulty, but I'm not inclined to bend on that basis :-/
19:34 <mwhudson> i think this is where i discover i have been unsubscribed from the list i think
19:34 <rbasak> (but I did say that a private non-endorsed branch is fine since we don't control such a thing)
19:34 <seb128> rbasak, I think I agree with that yes
19:36 <mwhudson> is there anything to follow up on bug 2147049 ?
19:36 <mwhudson> or the snapd sru exception (which is now a github PR i think?)
19:37 <rbasak> The snapd SRU exception PR has been revised since we last discussed it. I need to study the changes.
19:37 <mwhudson> https://github.com/ubuntu/ubuntu-project-docs/pull/542
19:37 <teward> the nux issue is already being handled, we already agreed that we can 'handwave' for 26.04 and fix for 26.10.  there's some issues with the git branches, etc. that's the real problem there but i think other sponsors were working on that
19:37 <teward> so nothing more for us wrt nux
19:37 <mwhudson> teward: ack
19:37 <teward> it's in sponsors hands at this point
19:38 <mwhudson> for the snapd exception, i should add an action to discuss this next time?
19:38 <seb128> I think so
19:38 <teward> (and again wrt nux, I did inform Release Team that it shouldn't block a Unity release for 26.04, given our agreement on 'way forward' as the TB)
19:38 <rbasak> "handwave" isn't language I recognise, but sure :)
19:38 <rbasak> mwhudson: +1
19:39 <mwhudson> #action review revised snapd SRU exception proposal https://github.com/ubuntu/ubuntu-project-docs/pull/542
19:39 * meetingology review revised snapd SRU exception proposal https://github.com/ubuntu/ubuntu-project-docs/pull/542
19:39 <teward> rbasak: it's a colloquialism to say "we'll let this slide for 26.04 to let it release but we won't accept this case in future so it has to be fixed in 26.10)
19:39 <teward> "handwave" as "let through" (in a case of say a line of people)
19:39 <teward> but i digress
19:39 <teward> *reups coffee*
19:39 <mwhudson> #topic Check up on community bugs and techboard bugs (standing item)
19:40 <mwhudson> no activity here
19:40 <mwhudson> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:40 <teward> with most of the TB at the sprint, should we skip next meeting or no?
19:40 <mwhudson> i guess as seb and i are unavailable next time we skip the one that would be on the 5th
19:41 <mwhudson> (i think i will be on a plane, in fact)
19:41 <teward> oh good because the 5th i wouldn't be here for anyways, i'll be in court that day
19:41 <teward> and that I *cannot* avoid >.>
19:41 <mwhudson> ok ro robie can talk to himself if he likes but next meeting is on 19th may
19:42 <rbasak> ack
19:42 <teward> ack
19:42 <seb128> +1
19:42 <mwhudson> chair should be, um, rbasak with seb as backup?
19:42 <rbasak> ack
19:43 <mwhudson> #topic AOB
19:43 <mwhudson> i have nothing
19:44 <seb128> nothing from me
19:44 <seb128> and ack as the chair backup
19:44 <mwhudson> rbasak, teward: any business?
19:44 <teward> nope
19:45 <rbasak> None from me.
19:45 <rbasak> Sorry I was just checking my calendar for 19 May
19:45 <mwhudson> cool thanks
19:45 <rbasak> It should be fine
19:45 <mwhudson> #endmeeting