19:06 #startmeeting Technical Board Meeting 19:06 Meeting started at 19:06:02 UTC. The chair is teward. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:06 Available commands: action, commands, idea, info, link, nick 19:06 #topic Action Review 19:06 #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:06 this is with the CC and they know what they need to do, but #INERTIA and such just means someone needs to do it. So still carry it over. 19:07 #action teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 19:07 * meetingology teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) 19:07 #subtopic all to spend some time looking at https://github.com/ubuntu/ubuntu-project-docs/pull/446 19:08 there hasn't been any movement for 2 weeks plus on the issues mwhudson brought up wiht the content, nor any follow-up to our inquiries *on* that pull request for content that may need changed. 19:08 I wonder whether this is now 'stale' and "needs the submitter to actually do stuff" for its state 19:08 rbasak: seb128: thoughts? 19:09 Sorry I haven't had a chance to look at this. 19:09 It is a big set of changes unfortunately. 19:09 so I think the main point from Robert there is that what is proposed is not any worth than the package we have in the archive which hasn't seen its content uploaded for 15 years 19:09 So is blocked on me finding an hour or two. 19:10 and that it would be better to comment and iterate if we merge and then work on that as a basis 19:10 I don't mind us iterating. 19:10 However I do think that it needs a fine assessment if it's going to be considered a normative source of policy. 19:10 there's a lot in the policy that's proposed that **shouldn't be there** for a first revision/submission 19:10 We should hopefully be able to make progress without that though? 19:11 Or, if we can't, maybe it needs to stay the package for now, or moved over verbatim without editing. 19:11 like Debian specific things that don't apply to Ubuntu among other things that just need someone to go in, select it and hit 'delete' 19:11 Unfortunately I think there are few people qualified to make the subjective edits :-/ 19:11 And reviewing for them when they have been done by somebody not qualified makes it even harder :( 19:12 > My concern is that while the actual content of the Policy is being dealt with in this PR, the onus is on Simon to make modifications. Correcting the Policy content and bringing it up-to-date is not what Simon signed up for 19:12 it sounds to me though they're trying to bypass standard review practices here 19:12 at least as i understand the review requirements for project docs stuff 19:12 I don't think they're trying to bypass anything 19:13 The issue is that it is difficult to change normative policy documents without a great deal of time expended by the people in charge of that policy (ie. us). 19:13 it souinds like rkratky is saying "Just accept this, then change things yourself" rather than "Rely on Simon who submitted this MAKING CHANGES" 19:13 rbasak: what's blocking this is mwhudson and I made some **very specific** change requests that should be applied before this gets accepted IMO and is a blocker for that 19:14 Then we need to rethink the approach IMHO. 19:14 And an outcome of that may be that we conclude that we do not have the capacity to make the change, and the policy needs to stay as a package for now, or be moved verbatim at best. 19:15 rkratky did make this point: 19:15 > My point in suggesting to merge now is that the Policy has -- officially -- been out there and in this outdated state for over 12 years. So, merging this PR wouldn't be a step back in that regard. But it would allow subsequent work on it to be done with the relative comfort of Git(Hub). 19:16 maybe that's sufficient, accept as is and then take the revision hammers to it later 19:16 which is fair in my opinion 19:16 but it WILL require us to deep dive on it then as soon as it's accepted. 19:16 we could merge, mark as draft, and iterate until happy and not undraft until we feel it's ready 19:17 by "mark as draft" you mean mark in the document that it is a work in progress? 19:17 (not the pull req) 19:17 yes, or even don't publish it in the normal location/index it yet 19:18 i don't know enough about the layout of this to know whether we can put it somewhere else or not yet, esp. since the pull request drops it in this specific location. 19:18 but once it's merged at least we can report issues and do MP 19:18 seb128: not undraft until we feel it's ready> I fear that this will result in the diff getting larger and larger from the original, making it increasingly less likely that we would ever consider it ready. 19:18 well we could ask Robert about moving it to another location/see if it can be not put in front on the website for now 19:19 However that opinion isn't intended to block. It is workable as long as we declare it not normative (ie. a draft) as you say. 19:19 rbasak: i don't think they mean drafting the PR / Diff, but mark the *document* as "under construction" and then incrementally fix things with each PR *we* make 19:19 My fear is just that we'd be making the problem harder for ourselves later. 19:19 rbasak: we'll be making the problem harder if we merge and then move it to a section not in standard areas too. 19:19 same problem: we still have diffs to apply, review, etc. in either case 19:19 still will have* 19:20 what would make things harder? and what's the alternative approach? 19:20 seb128: things would get harder as the diff gets larger over time 19:20 rbasak: you mean, *this diff* gets largert over time. 19:20 seb128: because I would want to compare proposed changes against a baseline if reviewing to make the draft no longer a draft. 19:20 we're not talking about adjusting *this* diff 19:21 seb128: and my baseline would be the original packaged policy 19:21 alternative approach> move the docbook XML into GitHub somewhere, perhaps not RTD/Sphinx unless conversion is possible at build time. 19:22 Slowly convert the docbook XML into rst or markdown, one piece at a time, reviewed incrementally 19:22 Eventually it becomes fully Sphinx compatible and can be merged into the main project docs 19:23 I'm not saying this is great, but unless the TB can volunteer a member with literally hours available to spend on this project, I don't really see any other way. 19:23 Or if not TB at least an experienced core dev we can trust and delegate to 19:24 Otherwise, is there a major issue with things staying as they are? 19:25 having a 15 years old policy the archive as only reference you mean? 19:25 I don't see why the age of the policy is a problem. 19:25 If there are specific issues with the policy as-is, they can be updated in the format they are in at the moment. 19:25 because the content is outdated and not matching reality of our archive? 19:26 So file bugs against the package then, and we can address them one by one. This is orthogonal to a format change. 19:26 well my point is that it would be easier to start from current Debian as a package and add back one by one things that are different 19:26 shorter distance than going the other way around 19:26 There is this tendency I somewhat abhor to neglect something for many years and then conflate simple maintenance catch-up with an implied necessity to overhaul everything around it. 19:27 seb128: sure, you can do that if you like. I don't object to that approach, just that it needs to happen step by step. 19:28 Thousands of lines of diff to review is too much. 19:28 but I do think you have a point, that's not trivial work and finding people who have time and knowledge to work on it is going to be difficult :/ 19:29 There's also the question of what value this brings. 19:29 An alternative approach would be to leave it as it is, and address only individual small changes that demonstrate the value of making them, prioritised by the most value first. 19:31 Another approach might be to write a script that converts the docbook to rst, and then we review only the script, and review a PR by running the script ourselves and confirming that we see identical output. 19:31 Then it'd be in rst at least, and it'd be a minimal review from us - hopefully a hundred line script instead of thousands of lines of potentially undesirable policy change. 19:32 so you mean concern is to be able to assert whether the proposed version matches what we currently have? 19:32 your main concern* 19:33 I only care about functional policy changes that are being proposed (especially inadvertently). I want to review those. 19:35 The rest I'm happy to delegate to Canonical's technical authors. However, the subject matter is deep and nuanced, and I don't know of a way to verify that inadvertent policy changes aren't being made without reviewing the changes. 19:35 I'm unsure how to do progress there :-/ 19:36 (or by delegating to an experienced core dev who's been around a while and actually understands the background behind the material they're reviewing) 19:36 it sounds to me 19:36 like maybe rbasak wants a verbatim copy of the XML made in RST so he can side-by-side compare content and make sure it's identical. 19:37 I don't want to have to do that :) 19:37 one other way would be to start from a "Our Policy is coming from Debian" and 1 PR at the time move delta from the existing package / delete it there to the WIP github version 19:37 those would be reviewable 19:37 and then these additional revisions that have been made as part of this massive diff in the PR BEYOND the side by side stuff be done as individual PRs. 19:37 rbasak: either way you want there to be a verbatim copy made for "base comparison purpose" whether you do the compare or not 19:37 at least it seems that way 19:37 and we iterate until we empty the ubuntu-policy package copied version used as a metric 19:38 seb128: so, maybe git-ubuntu merge style, extract all the delta that exists from the Debian package the current Ubuntu package is based on? 19:38 seb128: then transfer that one by one? I'd be OK with that. I wonder how much delta there would be. 19:38 right 19:39 even if it's lot, at least it can be done one piece at the time 19:39 I would expect to confirm that we have all the delta the same way I do that with git-ubuntu today. 19:39 And then we would have a finite set of pieces that could be addressed one by one, perhaps one per PR. 19:39 +1 19:39 +1 19:40 I presume you're imagining that in the final version, we wouldn't carry Debian policy at all? It'd just say "Debian policy applies, except: 1) ...; 2) ...; etc? 19:40 " 19:40 correct 19:40 wfm 19:40 that'd make it a lot easier to read our policy and determine where it diverges from Debian 19:41 if we carry the Debian policy then it becomes and ongoing rebase effort 19:41 s/and/an 19:41 It's worth pointing out that this would mean that Debian policy changes would apply immediately to Ubuntu without review by Ubuntu, but I'm completely fine with this - it's the de facto situation anyway 19:41 same 19:41 rbasak: are there any substantial changes in debian policy that would make that much of an impact? 19:41 Most of the archive flows from Debian anyway 19:41 Probably not. Debian policy is pretty well settled. 19:41 yeah that's what i was thinking 19:42 most things I see are usually minor revisions not major policy changes. 19:42 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 19:42 Upcoming things might be Debian's view on AI, what to do about models with open weights but no training data, etc. 19:42 oops 19:43 rbasak: to be fair, that's something we'd have to consider too, but we can also impose a separate policy statement on that saying "Ubuntu is reviewing Debian's stance and determining whether it fits with Ubuntu as well" or such at such a point 19:43 right 19:43 apply immediately> perhaps we define a delay, such as changes only apply after Debian's policy release into a stable Debian release, and/or only apply to Ubuntu in the cycle following an LTS, or something. But whatever: that's easy to define and/or change later. 19:44 teward: right. Note that thanks to autosync though, Ubuntu's policy can't realistically be narrower than Debian's policy. On this or more traditionally DFSG interpretation, etc. 19:45 granted. 19:45 but again if we DO have a divergence in AI policy, etc. then we can apply changes and document our differences from Debian policy 19:45 as suggested earlier 19:46 i dont' think it'd necessarily be *narrower* than Debian, but since no AI policy exists akin to this yet in Debian (and I'm not subscribed to all threads thanks to their abysmal DMARC support which is NONE), I'm not sure how immediately we need to worry about that 19:46 so the short term decision of "best way forward" applies (that we all seem to have +1'd) 19:47 even today our policy handling wouldn't bring any protection against Debian making a policy change we dislike 19:48 agreed. 19:48 packages updates would still flow from Debian to Ubuntu implementing that policy 19:48 ok, so we seem to agree then 19:49 anyone want to summarize then into one blurb? Or state the action item we need to add on this? My brain's a little bit spinning still for other reasons 19:49 (active security incident i'm working on w/ dayjob) 19:51 hum 19:52 'cause i'm not sure how to word this in such a way we can reply to the merge request while also keeping our intent here. 19:53 Happy to say we decide exact statements on this another day, but we at least owe a reply to the pull request 19:53 so our suggestion would be basically to drop the current proposal, ask someone to review/split the delta carried over Debian-back-then 19:53 state that our policy is Debian + those-changes 19:53 and then bring changesets from the delta split one by one 19:53 which would be each a reviewable PR 19:54 i'm happy with that. rbasak: what about you? 19:54 +1. Also, the delta split should be trivially verifiable (eg. with the usual git-ubuntu workflow) and there should then be a 1:1 mapping from logical commit to subsequent PR. 19:54 I'm happy to have that conversation with Simon/Robert 19:54 rbasak, +1 19:54 (further PRs also OK since we'd be able to change policy at any time with TB review) 19:55 #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:55 * meetingology 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:55 +1 as well there 19:55 thx 19:55 #topic Scan the mailing list archive for anything we missed (standing item) 19:55 i don't see anyh 19:55 any* 19:56 there was some emails I approved this morning 19:56 not anything new anyways, though we did find the `nux` policy violation that happened to glance on my radar 19:56 (and is why it's on the tb mailing list) 19:56 s/glance/appear/ 19:56 well, that one was new to me 19:56 but I didn't have time to read the details 19:58 seb128: rbasak and I had some discussions on that same day I found it, it was discovered as part of a merge request to fix FTBFS in the `nux` package and tests. I think where rbasak and I left off was to 'handwave' this through for the Unity 26.04 release, with a requirement that 26.10 they fix the policy problem 19:58 it was where they ship code that has the Unicode license referred to explicitly in part of it that's used for unicode processing of stuff 19:58 ok, that sounds reasonable to me 19:58 i've been a little overloaded the past week and didn't follow up since though but the original problem was 'this went undiscovered' or was intentionally ignored back when Unity was the go-to 19:59 problem is nobody knows, but the developers in question for Unity flavor have agreed to visit this and see if they can replace the functionality with libicu or simlar 19:59 similar* 19:59 and i think that's why we were OK with that one. 20:00 #subtopic [Bug 2147049] [NEW] [Policy Violations] nux ships non-free components that are not policy-compliant. ... 20:00 #info Identified during core-dev sponsoring by teward with Lintian alerts, components using Unicode license that are 'non-free'. 20:01 #info initial approach proposal from rbasak and teward was to handwave this issue for 26.04 to let Unity 26.04 have a release, on the requirement that 26.10+ would have a fix that removes and replaces the non-free components that `src:nux` depends on 20:01 but i don't think it needs us to necessarily act at the moment if we're in agreement on this to handwave it just for 26.04 as a one time exception on the basis that 26.10+ it gets a more permanent fix 20:02 it only exists in Ubuntu, and not Debian, so we don't have to worry about it 'reinheriting' the problem. 20:02 AIUI, following analysis by various people, it seems unclear that it even _is_ a licensing violation, even though I think we're all agreed that the documentation of the licensing is suboptimal. 20:03 rbasak: and i think the decision was if there IS a policy/license violation then we should handwave it. 20:03 So given it's been there for years and we don't know of a copyright holder who actually cares, and are only detecting it now because of a (relatively) recent lintian change, I see minimal harm in ignoring the issue for now, particularly as we aren't touching this area of the codebase anyway. 20:03 #info Further analysis suggests there might not be a policy or licensing violation in this case 20:04 +1 on that rbasak, i don't see any further harm ignoring it *for now* while things get more deeply investigated or such. 20:04 And then there's enough time next cycle to just rewrite the relevant piece of code which the Unity team have agreed to do anyway 20:04 indeed 20:04 the other thread i see here is the Snapd special case documentation stuff. 20:05 We're out of time :-/ 20:05 yheah 20:05 we are 20:05 hour is never enough time 20:05 #subtopic [Merge] ~ernestl/sru-docs:update-snapd-exceptions--modifications into sru-docs:main 20:05 #info Review next meeting 20:05 ack 20:05 #topic Check up on community bugs and techboard bugs (standing item) 20:06 There's never anything new there heh 20:06 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 20:06 it cycles back to mwhudson if we go in order. 20:06 and robie's backup then at that point 20:06 #topic AOB 20:06 i guess none 20:06 bot from me :-) 20:07 and i got nothing, and rbasak already said 'we are out of time so' 20:07 #endmeeting