=== cpaelzer__ is now known as cpaelzer === mIk3_09 is now known as mIk3_08 === didrocks999 is now known as didrocks [15:28] o/ [15:28] Happy Tuesday cpaelzer! [15:29] to all of you as well :-) [15:29] didrocks: doko: ddstreet: jamespage_: sarnold: pre-ping for MIR meeting [15:30] o/ [15:30] #startmeeting Weekly Main Inclusion Requests status [15:30] cpaelzer: Error: Can't start another meeting, one is in progress [15:30] good morning [15:30] hmm it tells me another meeting wasn't finished [15:30] * cpaelzer checks logs ... [15:30] #endmeeting [15:30] rats [15:31] nhaines: any chance you're around and can #endmeeting? [15:31] only works for the owers I guess [15:32] o/ [15:32] #chair sarnold [15:32] yeah all that would have to be in the control channel [15:32] by former owner [15:33] we have "[00:35] #endmeeting" but it seems it has not stopped [15:33] o/ [15:33] didrocks: doko: ddstreet: jamespage_: sarnold: does one of you mind if we go on (and fill their logs instead of ours) ? [15:33] +1 === jamespage_ is now known as jamespage [15:33] go [15:33] might as well keep going [15:33] +1 [15:34] yep [15:34] #topic current component mismatches [15:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [15:34] not too mcuh new in this one [15:34] doko has set https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137 back to New [15:34] Launchpad bug 1895137 in rpi-eeprom (Ubuntu) "[MIR] rpi-eeprom; raspberrypi-userland" [Undecided,In progress] [15:34] doko: on whom is this waiting now? [15:35] you requested a bunch of things in https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137/comments/13 [15:35] us. fixes were uploaded without updating the report [15:35] I'll look at this [15:35] ok, so you'll do a re-review [15:35] I'll assign it then to reflect that state [15:36] of the rest I wanted to mention octavia [15:36] https://bugs.launchpad.net/ubuntu/+source/octavia/+bug/1888309 [15:36] Launchpad bug 1888309 in octavia (Ubuntu) "[MIR] octavia" [High,New] [15:36] jamespage: this is on security atm - is this strictly needed this cycle to have things complete and working? [15:36] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice [15:37] ah teward had the power, thanks [15:37] cpaelzer: anyone with a member cloak can +o here [15:37] #startmeeting Weekly Main Inclusion Requests status [15:37] cpaelzer: Error: Can't start another meeting, one is in progress [15:37] and endmeeting [15:37] cpaelzer: well it would be nice [15:37] um... [15:37] it's broke o.O [15:37] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice [15:37] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice [15:37] o.O [15:37] teward: nice try, but doesn't work :-) [15:37] #startmeeting Weekly Main Inclusion Requests status [15:37] teward: Error: Can't start another meeting, one is in progress [15:37] i'll report to -irc and get meetingology punted [15:37] sarnold: well then - how about any ETA forecast ? [15:37] so that jamespage can plan accordingly [15:38] sarnold: you can reply to that later [15:38] while we wait on you asking the crystal ball [15:38] let us go to the more busy [15:38] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [15:38] abseil is now ready to be reviewed and this is my next task [15:38] thanks didrocks [15:39] backuppc the server & security teams have agreed that this sadly won't be completed in time for hirsute [15:39] so it will stay on 3.x and then complete in hopefulyl early 21.10 [15:39] thereby it will stay in this view for a while [15:40] other than that the one new (for me) thing is mtd-utils -> iniparser [15:40] does that package mean anything to anyone here? [15:41] cpaelzer: doko said he was going to take it in the last meeting [15:42] yes, it's addressed in foundations [15:42] it has no bug yet [15:42] doko: would you later create a stub and assign it to whoever in foundations is on it? [15:43] I'll consider silence to be "yes" :-) [15:43] going on ... [15:43] there's also a https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1907284 [15:43] Launchpad bug 1907284 in u-boot-menu (Ubuntu) "[MIR] u-boot-menu" [Undecided,New] [15:43] but it may be missing something, the white circle suggests there's no bug yet [15:43] indeed sarnold [15:43] that isn't new, it lacks the team subscriber [15:44] without that it means "the reporter didn't shove it to us for review" [15:44] but I guess that xnox didn't want to hold it back - as it otherwise looks ready [15:44] I'll add the subscription for it to show up [15:44] done [15:44] I think :) ~ubuntu-mir ? [15:44] thanks [15:44] yes that works [15:45] any volunteers for a review ? [15:45] well it will come in the next section [15:45] let us check if we have more there [15:45] #topic New MIRs [15:45] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [15:46] the first (rpi-eeprom) was copy&pasta - fixed [15:46] then we have left two [15:46] https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1907284 [15:46] Launchpad bug 1907284 in u-boot-menu (Ubuntu) "[MIR] u-boot-menu" [Undecided,New] [15:46] as we just discussed [15:46] and [15:46] https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1794219 [15:46] Launchpad bug 1794219 in OEM Priority Project "[MIR] ledmon" [Medium,New] [15:47] I have doen LEDmon in the past, might even be my first one [15:47] my updates look so bad ... [15:47] I'll re-review that one [15:47] hehe :) [15:47] anyone volunteering for u-boot-menu ? [15:48] * cpaelzer fetches a dice ... [15:48] really no one wants to, don't tell me everyone is busy - I know [15:48] i can take it [15:48] awesome [15:48] didrocks: also got one above [15:48] so we get a fair spread it seems [15:48] thanks ddstreet [15:49] ok, the list is empty now [15:49] next topic [15:49] #topic Incomplete bugs / questions [15:49] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir [15:49] we talked about needrestart last time [15:50] new in this list is flashrom [15:50] https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/1912371 [15:50] Launchpad bug 1912371 in flashrom (Ubuntu) "[MIR] flashrom" [Undecided,Incomplete] [15:50] On that I have already pinged mclemenceau [15:50] If they want to own it they will update the bug accordingly [15:50] if not someone has to make dependencies to disappear [15:50] no action for the MIR team yet [15:50] #topic Any other business? [15:51] 10 minutes left, so what is up ? [15:51] nothing for me [15:51] anything MIR'ish or not worth to share/discuss right now? [15:51] * cpaelzer is out of topics and hot to re-enter some debugging [15:51] we might experiment with Wayland by default on the desktop. The latter is already in main, but we might have utilities entring main due to that [15:52] but let’s see [15:52] entering* [15:53] nothing for me [15:53] didrocks: for 21.04 or 21.10 ? [15:54] for 21.04 [15:55] uh, wow [15:55] good to be aware of [15:55] thankd didrocks [15:55] nothing else it seems [15:55] thank you everyone [15:55] wow :) [15:55] and see you next weeks with all the reviews we assigned being done [15:55] thanks cpaelzer, all :) [15:55] thanks cpaelzer, everyone :) [15:55] fake #endmeeting [15:56] the channel still waits to be freed by the current owner [15:56] nhaines: sorry, it appears the bot is unhappy, probably it doesn't matter.. [15:56] sarnold: nhaines: bot is unhappy, i've poked -ops-team and -irc about it [15:56] someone has to punt the bot [17:24] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice [17:24] jose: we did that [17:24] i did like 3 times won't let us start anew [17:24] #startmeeting [17:24] jose: Error: Can't start another meeting, one is in progress [17:24] see? [17:24] hence: punt it [17:32] #startmeeting [17:32] Meeting started at 17:32:01 UTC. The chair is jose. Information about MeetBot at https://wiki.ubuntu.com/meetingology [17:32] Available commands: action, commands, idea, info, link, nick [17:32] blah blah [17:32] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice [17:32] Meeting ended at 17:32:08 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-01-26-17.32.moin.txt [17:32] teward: see? it behaves [17:32] well you DID punt it :P [17:32] now it behaves [17:32] *points at the join/parts log* [17:32] jose: thanks for kicking it. [17:32] np :) [19:55] o/ [19:55] Oh, -2 [19:59] o/ [19:59] o/ [19:59] #startmeeting Ubuntu Technical Board [19:59] Meeting started at 19:59:52 UTC. The chair is cyphermox. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:59] Available commands: action, commands, idea, info, link, nick === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Technical Board Meeting | Current topic: [20:00] o/ [20:00] #chair cyphermox rbasak [20:00] Current chairs: cyphermox, rbasak [20:00] #topic Apologies === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Technical Board Meeting | Current topic: Apologies [20:00] (none, as far as I know) [20:00] who's there today? [20:00] me [20:00] I think we're quorate? [20:01] o/ [20:01] yup [20:01] ok, moving along [20:01] #topic Action review === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Technical Board Meeting | Current topic: Action review [20:01] #subtopic ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. [20:02] *crickets* [20:02] lol [20:02] carry? [20:02] yeah, carry [20:02] zug zug [20:02] #subtopic ACTION: formal ratification of third party seeded snap security policy, depends on: [20:03] #subtopic ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [20:03] vorlon: ? [20:04] This is regarding the seeded snaps, right? [20:04] doesn't look like he's here [20:04] sil2100: yeah, I think so [20:05] just giving him some time to respond, since he did chime in in #ubuntu-meeting-2 earlier [20:06] oh! didn't notice [20:06] cyphermox: sorry - yes, still carry over [20:06] and well, many action items are his, too [20:06] ack! [20:06] #subtopic ACTION: vorlon to reply to seeded snap upload permissions question on list [20:06] same? [20:06] basically no movement on any of mine since the last meeting [20:06] ah, ok [20:07] (there was a Canonical midcycle roadmap sprint in the middle) [20:07] #subtopic ACTION: xnox to start a draft summarizing the OEM archive portion of the meeting which vorlon, infinity, and mdeslaur will review, edit, and ratify before we move on to figuring out the next step ([2/3 subquorum required if one of us slacks, to avoid holding up the process]) [20:07] ack. [20:07] *lurks TB meeting* [20:07] vorlon: do you know about xnox's? [20:07] uh, what did we determine last meeting? were there any updates to this? since at least the reviewer portion is no longer accurate [20:07] same for me, apologies, I was supposed to ping him about that [20:08] oh, right, sorry [20:08] the last action items are just that [20:08] #subtopic ACTION: mdeslaur to follow up with xnox about OEM archive documentation [20:08] #subtopic ACTION: mdeslaur to follow up on xnox's track clarification post to the list from 2020-08-12 [20:08] carrying those as well then [20:08] carry forward both of mine, yes, thanks [20:08] should we reassign some things? would that help? [20:08] oh if anyone wants one of mine, feel free to steal it ;) [20:09] likewise ;) [20:09] haha [20:09] Would be nice to have that documented, since the only thing for this we have right now is https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM [20:10] I can follow up with Dimitri if needed [20:10] So you can re-assign it to me, my first TB task! yay [20:10] sil2100: thanks, I'd appreciate it [20:10] ok [20:11] #action sil2100 to follow up with xnox about OEM archive documentation [20:11] ACTION: sil2100 to follow up with xnox about OEM archive documentation [20:11] carrying the rest, I'll clean up the wiki [20:11] #topic Other agenda items [20:11] There were none on the Agenda wiki page... === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Technical Board Meeting | Current topic: Other agenda items [20:12] at least, as of half an hour ago when I prepared for the meeting [20:12] #topic Pending mailing list items === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Technical Board Meeting | Current topic: Pending mailing list items [20:12] I don't know that any were definitely missed; but in case: [20:12] #subtopic Proposal for exception to existing fwupd SRU policy [20:12] I don't think that request has been addressed yet. [20:12] I haven't had a chance to digest that one yet fwiw, sorry [20:12] did anyone respond on this one from Mario? [20:12] ok [20:13] I'm inclined to consider that as standard hardware enablement? [20:13] Though I think maybe it's one for the SRU team, not the TB? [20:13] (at first blush, I am unenthusiastic about it) [20:13] There didn't seem to be anything in that request not already covered by the TB's HWE delegation to the SRU team. [20:13] (from memory) [20:13] aye [20:13] rbasak: ah; I thought it went to the TB because you referred it there from the SRU team? [20:14] No that was Thunderbird [20:14] oh ok [20:14] (that request involved deliberately breaking some packages, so I didn't think it fitted into the scope of the existing delegation) [20:15] to me, fwupd point the first seems like HWE [20:15] does someone want to respond and kick it back to the SRU team then? [20:15] and fwupd point second sounds a lot like a standard SRU bugfix [20:15] I'll respond [20:16] (fwiw, my concern about a blanket exception for fwupd is that this is a userspace daemon, not just code changes that directly related to hardware enablement, and there could be compatibility concerns) [20:16] sure [20:16] so you're going as letting the SRU team decide just this one, and then we think more about a stnading exception? [20:16] Wearing my SRU hat, I'm not sure I buy the reason given for needing major upstream version bumps though. The justification seems to be a solution presupposing the problem. [20:17] I can't say I disagree with that, the method of doing the firmware updates via EFI wouldn't be subject to changing much [20:17] The SRU team would grant a standing exception still though? [20:18] if we're saying this is in the domain of the current SRU team delegation, how about we just respond on the list with the redirect and let the SRU team sort it out [20:18] Since it's within the SRU team's remit to decide on a case-by-case basis. We (SRU team) reintroduced the "exception list" for consistency within ourselves only. [20:18] +1 [20:18] #action cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. [20:18] ACTION: cyphermox to respond to Mario's SRU exception request, this is handed back to the SRU team. [20:18] that sounds right? [20:18] +1 [20:18] #subtopic Updating thunderbird from 68 to 78 in focal [20:19] rbasak: you want to tell us more about the current state of this, as you've been most involved in the thread? [20:19] I had some comments to make on that one regarding the specific rationale why replacing packages with dummy packages would/wouldn't be ok, but I have no concerns about the conclusion [20:19] so the two packages are tinyjsd and jsunit, which AFAIK existed solely to be able to build enigmail [20:21] I guess the remaining thing to decide is what to do with tinyjsd and jsunit then, yes? i.e. if those should be turned to dummy packages? [20:21] I believe the appropriate resolution has been agreed. We're just waiting on uploads. [20:21] they don't currently work with firefox anymore, and they won't work with the newer thunderbird. I believe the new basically empty enigmail package no longer needs them either. [20:21] I believe they're being turned into dummy packages - that was mdeslaur's proposal, and nobody objected. [20:22] ok [20:22] I will still want to write things down on the list, but in case we want to ratify this during the meeting, my thought process is: 1) the thunderbird upgrade is reasonable and necessary for supportability reasons; 2) the reverse-dependencies would at best become uninstallable after the upgrade of thunderbird so having them converted to dummy packages doesn't have further negative impact on users, [20:22] and does facilitate unattended upgrades; 3) if a user wants to keep these revdeps installed for some reason they would have to downgrade or pin thunderbird and if they're doing that anyway they can do the same for the revdep packages [20:24] yes, I'm in agreement [20:24] +1 [20:24] +1 [20:24] +1 [20:24] #agreed vorlon's thoughts on thunderbird process [20:24] AGREED: vorlon's thoughts on thunderbird process [20:25] I like Robie's proposition to make sure to document this somewhere [20:25] yup [20:25] #subtopic Use of the TB mailing list [20:25] was there anything left to discuss on that one? [20:25] *raises hand with CC hat on* [20:25] teward: hi! [20:26] For my understanding, I'd like the TB to specifically determine the intent of the use of the TB list, and in turn if necessary update the description documentation on it to indicate it's a public or private list. [20:26] Given the recent... I'll call it 'chaos'... with the change of rights, viewability, etc. by Jose on this, I'd like to make a note that the TB should make a decision on this, and accordignyl update the description to indicate whether it's public or member-only/internal-only [20:27] I think what we're missing now is basically updating the "About technical-board" section for the ML to make sure things are clear [20:27] just a minor thing but I'd like to bring that up since you indicated "use of the mailing list" and I"ve had ${TONS_OF_STUFF} to not track the discussion outside of me bringing it up to the CC ;) [20:27] Oh [20:27] cyphermox: then as soon as that's updated, I won't have a reason to complain :0 [20:27] I did have a proposal for basically that that remains outstanding on the list. [20:28] ok [20:28] https://lists.ubuntu.com/archives/technical-board/2021-January/002532.html [20:28] AIUI no members of the tb are still administrators of the mailing list and cannot update the description? [20:28] +1 on rbasak's proposal [20:28] vorlon: CC has admin [20:28] I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? [20:28] you choose wording, we'll toss it up [20:28] teward: ok [20:28] (I was in it yesterday in 'read only' mode, you can consider me PoC for this one) [20:28] (if you need a dedicated PoC) [20:29] ("read only" meaning I was looking @ settings but not tweaking ;) ) [20:29] rbasak: your proposal for the ML was straight up agreeing to the wording, correct? [20:29] cyphermox: correct [20:29] Just the wording change, which also means that nothing else changes. [20:30] I'm +1 on your wording. [20:30] +1 [20:31] +1 [20:31] Thanks! [20:31] vorlon: that brings another question you guys can handle internally, or bring up for CC to mull over: does TB *want* list admin, while keeping CC as a fallback admin in case we run into another case of TB Not Being Admins (i.e. what we had before we went through IS and such to give CC admin) [20:31] Action to teward then please? [20:31] #agreed Make use of rbasak's copy suggestion for updating the mailing list's "About" section. [20:31] AGREED: Make use of rbasak's copy suggestion for updating the mailing list's "About" section. [20:31] #action teward / community council to update TB mailing list "About" section with agreed upon wording [20:31] ACTION: teward / community council to update TB mailing list "About" section with agreed upon wording [20:31] Thank you! [20:31] ahah, I was just typing that [20:32] cyphermox: i was already ahead of you ;) [20:32] sorry :) [20:32] (i know i'm not chair and asserted it with op but xD) [20:32] Interesting to know that works [20:32] teward: I don't feel like it's likely we'd need admin all that much [20:32] since we do have moderation [20:32] cyphermox: ack, works for me, less people with the admin password the better [20:32] I'm happy with it as is. We can change things if something comes up. [20:32] (in terms of security) [20:32] teward: I expect TB should handle the list moderation internally, and that's the only administrative function I've ever needed to touch in N years [20:33] vorlon: that's what I'd expect [20:33] I would just not like the CC making config changes without consulting the TB :) [20:33] Before we continue, I have one question above on the Thunderbird exception please [20:33] #agreed TB does not need admin access to the ML at this point in time [20:33] AGREED: TB does not need admin access to the ML at this point in time [20:33] rbasak: yes, I just wanted to conclude one topic at a time [20:33] Sure [20:33] #subtopic Back on thunderbird [20:33] vorlon: that's a given as well, we wouldn't touch anything unless either ERR:CRITICAL or ERR:TBConsulted [20:34] So from above, for clarity [20:34] rbasak: you were asking about whether we'd require the write-up? [20:34] I like Robie's proposition to make sure to document this somewhere> Should we require this then, in approving the Thunderbird request? [20:34] Right [20:34] I would like a bit of a cultural shift in Ubuntu in this regard. [20:34] Of everyone doing a better job of writing up user-impacting changes. [20:35] what form would that take though? [20:35] things are often documented by way of mailing list, for better or for worse :) [20:35] I don't really mind what form, as long as it's a noise-free single summarised and linkable explanation. [20:35] I wouldn't want to mandate anything specific either, really. [20:36] I think this is just that think that probably belongs to devel or devel-announce? [20:36] Yeah, one or both even [20:36] But for example if it's a decision scattered amongst multiple bug comments or an ML thread, then when confusion arises in the wider community, I can't resolve it with a single authoritative link that community members can be expected to read [20:36] indeed [20:37] also, release notes [20:37] Well, release notes are fine when we're doing point-releases or releases [20:37] So I want to push as little as necessary, and just say what I want to make better, rather than dictate how it is to be done [20:37] But for changes in stable series before a release is happening - we don't have a good place for that right now [20:37] as a community member (not my CC hat!) I would agree with better Release Notes and such [20:37] for ongoing SRU changes I'm not sure that's necessary unless there's some form of Major Breaking Change not handled in the considerations [20:38] So for instance for .2 it makes sense to document it in the release notes [20:38] sil2100: that arguably should show up in Changes doc for a stable release; but in the meantime a mailing list suffices [20:38] But inbetween .2 and .3, it's a bit confisuing if we put it there before release [20:38] I see we're in full agreement [20:38] The release notes for .2, written up before the change hits -updates, would be fine by me, because it meets my requirements - an authoritative summary that can be linked to. [20:38] well, the Changes/ Release notes could still just point to the mailing list post [20:38] So would a -devel or -devel-announce ML post [20:39] Pointing to an ML post would be fine by me, providing there's a noise-free summary there, and not a noisy thread to read through [20:39] "XYZ changed, causes FGH to be broken, see for full rationale" [20:39] nah [20:40] does -devel / -devel-announce post sound fine for everyone to document this, and who will respond on the thread? [20:41] (I'm +1) [20:41] A question for everyone first. Do you want to mandate a specific method? Because I don't. [20:41] nah, I'd just recommend it as part of "please write documentation for this change" [20:41] Maybe mandating a specific method wouldn't be the best thing, but recommending sending an e-mail to devel/devel-announce would be nice [20:41] Recommend instead of mandate is good. [20:42] Since it's then easier to get all the interesting stuff from single place to put on the release notes [20:42] So is everyone suggesting recommendations here, and not a mandate? [20:42] MUST document, MAY use established mailing lists -devel or -devel-announce [20:42] +1 [20:43] +1 [20:43] apologies for using RFC parlance [20:43] The clarity is good :) [20:44] mdeslaur, vorlon ? [20:44] 0 [20:44] ok [20:44]