19:01 <seb128> #startmeeting Technical Board
19:01 <meetingology> Meeting started at 19:01:04 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:01 <meetingology> Available commands: action, commands, idea, info, link, nick
19:01 <seb128> #topic Action Review
19:02 <seb128> ups
19:02 <seb128> #topic Apologies
19:02 <seb128> I don't see any on the list/wiki
19:02 <seb128> Lukasz doesn't seem to be online though
19:03 <seb128> anyway, let's move one
19:03 * vorlon waves
19:03 <seb128> #topic Action Review
19:03 * seb128 amurray to follow up with backporters team on Mattia's draft charter proposal
19:03 <seb128> amurray, did you get a reply since the previous meeting?
19:03 <amurray> No - I've sent two emails to the backporters team asking them to ack mattia's proposal but had no response still
19:04 <seb128> :-/
19:04 <rbasak> :-(
19:04 <rbasak> At the last meeting I said this:
19:04 <rbasak> It'd be nice to see a conclusion on this. I wonder if it would be appropriate to set a deadline at some point, and if no reply then we just use the current draft and call it done. I wouldn't mind it being long eg. months, but it'd be nice to have _some_ end point.
19:04 <seb128> I'm +1 with that
19:04 <rbasak> We've already adjusted the draft to their suggestion, dropping what I had originally proposed.
19:05 <vorlon> also +1
19:05 <rbasak> Could we agree that this draft becomes final at some future date now, and encourage the backporters team to engage with us if they disagree?
19:05 <amurray> I agree - how about I send one more follow-up later today and stipulate that if we get no response within another 2 weeks (that would be over 1 month since my original email asking for their ack) then this will become final
19:05 <rbasak> eg. two months from today, so 30 July.
19:05 <rbasak> Sure.
19:06 <vorlon> I think that should be the default.  We want the involved teams to be on board with what we rule, but if they're not going to engage, it's the TB who has the authority here
19:06 <rbasak> I'm easy on the actual date as long as we set one :)
19:06 <seb128> I was going to suggest start of July, seems similar timeframe
19:06 <rbasak> Sounds like we're all on the same page, so as amurray is driving I suggest he sets the date as he feels appropriate.
19:06 <seb128> +1
19:07 <amurray> sure - I prefer going with say 2 weeks to avoid this dragging on much longer
19:07 <rbasak> Sure
19:08 <seb128> so June 13 ?
19:08 <rbasak> FWIW, we should also work with some of the other teams to establish some similar documentation. I'm not trying to single out the backporters team here! In the past few years, questions have arisen on the scope of the DMB's role, as well as AAs.
19:09 <amurray> I suggest June 12th - that way it falls just before the next TB meeting
19:09 <rbasak> +1
19:10 <rbasak> Though, to be clear, I don't think it should take a further TB meeting to agree. We're agreeing it now :)
19:10 <rbasak> (but I welcome further discussion at a TB meeting should it arise)
19:10 <amurray> indeed - but this way at that meeting we have a clear outcome with any luck
19:11 <seb128> #agreed  amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final
19:11 <meetingology> AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final
19:11 <vorlon> also means that if there is any feedback given on the current draft we can quickly ratify those changes
19:12 <rbasak> seb128: o/
19:12 <seb128> k, let's move on?
19:12 <seb128> rbasak, yes?
19:12 <rbasak> Minor point: "if we get no response before" -> that sounds like if they respond, then it won't become final.
19:12 <seb128> how do I edit an agreed? :p
19:13 <rbasak> But I think we just agreed to make it final regardless, on 12 June, unless the TB (and only the TB) decide otherwise before that date.
19:13 <rbasak> You can use #undo
19:13 <seb128> #undo
19:13 <meetingology> Removing item from minutes: AGREED
19:13 <rbasak> Then #agreed something else
19:13 <seb128> thanks
19:14 <seb128> #agreed  amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise
19:14 <meetingology> AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise
19:15 <seb128> better?
19:15 <rbasak> Sure
19:15 <rbasak> Thanks
19:15 <seb128> thanks!
19:15 <seb128> moving on
19:15 * seb128 seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
19:15 <rbasak> I'll discuss the status of the draft in a bit.
19:15 <rbasak> But we're a bit blocked on this now :-/
19:16 <seb128> sorry, I've still been struggling with finding time for those items but rbasak started editing which pushed me to go back to it now
19:16 * seb128 seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
19:16 <seb128> similar
19:16 * seb128 rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
19:16 <rbasak> Carry this please - I've been focused on the other thing
19:16 * seb128 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
19:17 <rbasak> Carry again I guess, as he's not here
19:17 <seb128> Lukasz is not around today so that's another carry over
19:17 <seb128> #topic Scan the mailing list archive for anything we missed (standing item)
19:17 <rbasak> I see some emails from amurray :-P
19:17 <seb128> nothing recent on the list
19:17 <seb128> lol
19:17 <seb128> #topic Check up on community bugs and techboard bugs
19:18 <rbasak> Oh, did we lose the progress item on the third party repository requirements doc in general? I'd like to discuss that please.
19:18 <amurray> same
19:19 <seb128> rbasak, I was expecting that it come as an AOB since we don't have a specific item on the agenda for it
19:19 <rbasak> ack
19:19 <seb128> but yes we should add it back as an action
19:19 <seb128> #info No new community bug activity
19:19 <seb128> #topic Select a chair for the next meeting
19:20 <seb128> next would be vorlon and if we follow the ordering on the launchpad page Lukasz as a backup
19:21 <seb128> #info vorlon will chair next, with sil2100 as backup
19:21 * vorlon nods
19:21 <seb128> #topic third party repository requirements status update
19:21 <seb128> rbasak, ^
19:22 <rbasak> I have been working on the doc and I think it's ready. Apart from the appendices and the wording of the "build on all architectures exception" for the desktop packages that I think, we agree we need.
19:22 <vorlon> fwiw I have another topic for AOB after this
19:22 <rbasak> Next, I'd like to publish this for wider feedback.
19:22 <rbasak> Before I do that, could the TB please review the main body of the document and check you're happy with it?
19:22 <rbasak> Perhaps we could give all TB members an opportunity to do that before our next meeting?
19:22 <vorlon> sounds good to me
19:22 <amurray> rbasak: so I noticed there is nothing in the document regarding testability- ie. how do we integrate a seeded snap with britney?
19:23 <rbasak> And unless there are any further comments from the TB, I'll present that as the TB's draft position, pending further feedback.
19:23 <rbasak> amurray: I'm not sure I follow
19:24 <amurray> do we want to stipulate that a seeded snap must be able to be tested / have some tests that can be run to ensure it is "stable" before being released?
19:24 <rbasak> I think we should definitely do those things. But I'm not sure it should be within the scope of this doc - just as we leave the specifics of how to test debs up to Ubuntu developers.
19:25 <rbasak> For example a package can be a deb in the Ubuntu archive with no tests whatsoever - that's currently permitted, even if it's not best practice.
19:25 <seb128> well we have a MIR process, it sort of opens the question of it should apply to snaps that we want seeded
19:25 <rbasak> Currently the MIR team may decide to permit something in main without tests though, without involvement of the TB.
19:26 <rbasak> So in my mind, for a seeded snap, we're leaving that kind of decision to the Ubuntu developer making the change (in the seed, presumably).
19:26 <rbasak> It's a good question though.
19:27 <amurray> I don't want to be too specific here - but I do want to make sure that we can maintain quality for any third party packages and I see testing as a big part of that
19:27 <rbasak> Do you think we should require something? And if so, would we require this for debs as well?
19:27 <rbasak> amurray: I see your concern addressed by "Proposed requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release" already
19:27 <rbasak> And the paragraph that says "the precise meaning of "maintain", is enforced by trust only"
19:28 <rbasak> IOW - we agree that this is important, but we aren't dictating the specifics
19:28 <vorlon> agreed w/ rbasak on this
19:28 <seb128> but should a pre-installed snap get a +1 from the MIR team?
19:29 <vorlon> I like that idea but think we should discuss it with the MIR team first to make sure they're comfortable taking on that duty
19:30 <amurray> for debs we have britney and proposed-migration that enforces a level of quality on SRUs (assuming there are dep8 tests etc) by doing automated testing - if cups becomes a snap, how do we make sure it doesn't regress on updates in future releases? a lot of stuff depends on cups so I see this as important (as a topical example)
19:30 <rbasak> I have no objection to a process requirement to get a review from some appropriate team
19:30 <rbasak> But whether that's the TB, the MIR team, or some new kind of snap-MIR team, is an open question I think.
19:31 <rbasak> Another option might be to start softer - by requiring such changes to be announced eg. to ubuntu-devel@ and be done before eg. feature freeze. That would allow the TB to object, but without the friction of a team requiring an approval.
19:32 <rbasak> Or indeed to give some notice before doing it
19:32 <rbasak> (or committing to doing it)
19:33 <rbasak> amurray: would that address your concern with your cups example?
19:33 <amurray> yes I think that would work
19:34 <amurray> thanks
19:34 <rbasak> So I'm open to any of the above. I would add it as a snap-specific policy requirement in the document (so into appendix C)
19:34 <rbasak> Which of those options should I take?
19:35 <rbasak> Personally I think I'd favour "soft, with notice" if that works for everyone?
19:35 <amurray> +1
19:36 <seb128> +1
19:36 <vorlon> +1
19:37 <rbasak> I'll write that up then. Thanks!
19:37 <amurray> thank you :)
19:37 <rbasak> So, to summarise, homework for the TB: you have until the next meeting to study the doc and raise any other concerns you may have at the next meeting.
19:38 <rbasak> And I'll write up the "snap MIR" process (just notice) requirement into appendix C.
19:38 <rbasak> Any other comments on this topic for today?
19:38 <vorlon> none from me
19:39 <seb128> #agreed the TB members have until the next meeting to review the third party repository requirements document and raise concerns
19:39 <meetingology> AGREED: the TB members have until the next meeting to review the third party repository requirements document and raise concerns
19:39 <seb128> #topic AOB
19:39 <seb128> vorlon, ?
19:40 <vorlon> last meeting we talked about the question of core teams governance
19:40 <vorlon> I had just sent an email to the private thread, which I understood folks had the action to review and reply to?
19:40 <vorlon> I haven't seen any responses yet :)
19:40 <rbasak> Oh, right
19:41 <rbasak> IIRC, we said we'd make it public today?
19:41 <seb128> yes, in fact I wanted to mention that, it's another of those action items I failed at acting on
19:41 <vorlon> going back to meeting log to see what we said
19:41 <seb128> would people be ok to postpone until the next meeting?
19:42 <vorlon> https://irclogs.ubuntu.com/2023/05/16/%23ubuntu-meeting.html#t19:10
19:42 <seb128> Lukasz hasn't been around/commented on it
19:42 <rbasak> Sure. The thread hasn't had any activity recently. Perhaps we could agree that all further discussion on that topic can be expected to be public?
19:42 <vorlon> weeks were given and no objections were raised, so maybe "replay the thread but publicly" is the correct next action here?
19:42 <rbasak> +1
19:42 <seb128> wfm
19:42 <amurray> +1
19:43 <vorlon> in which case I guess it would be an action for seb128 to kick it off? :)
19:43 <vorlon> if I correctly understand what is meant by "replay"
19:43 <rbasak> That was my wording IIRC, and yes I think you do.
19:44 <seb128> #agreed seb128 to resend 'core teams governance' email to the public techboard list
19:44 <meetingology> AGREED: seb128 to resend 'core teams governance' email to the public techboard list
19:44 <rbasak> Because if seb128 posts it, then I can provide basically the same reply I did privately, and then the public will be able to follow my position/opinion on it.
19:44 <seb128> #undo
19:44 <meetingology> Removing item from minutes: AGREED
19:44 <seb128> #agreed seb128 to resend the 'core teams governance' email to the public techboard list
19:44 <meetingology> AGREED: seb128 to resend the 'core teams governance' email to the public techboard list
19:44 <seb128> any other AOB?
19:45 <amurray> nothing from me
19:45 <vorlon> nor me
19:45 <rbasak> None from me.
19:45 <seb128> ok, it's a wrap then, thanks everyone!
19:45 <rbasak> Thank you all for a productive meeting!
19:45 <seb128> #endmeeting