== Meeting information == * #ubuntu-meeting: Technical Board meeting, started by teward, 26 Aug at 19:01 — 19:57 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-08-26-19.01.log.html == Meeting summary == === Action review === Discussion started by teward at 19:02. * '''mwhudson to catch up on the previous riscv64 "official status" discussion and then drive it forward as needed''' (teward, 19:02) * ''LINK:'' https://paste.ubuntu.com/p/Jc4WgqRCNM/ (mwhudson, 19:03) * summary: 1. the flag is cosmetic only 2. it's up to us to decide what it means 3. the release team is in favour of setting it for riscv (teward, 19:05) * 4. the only reason not to set it is that security updates in some situations might be delayed (teward, 19:05) * 5. mdeslaur (security team) is ok with it being set despite that (teward, 19:05) * ''VOTE:'' Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." (Carried) (teward, 19:10) * ''VOTE:'' Actual vote: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." (Carried) (teward, 19:11) * ''ACTION:'' rbasak to follow up on ML thread regarding riscv64 'official' status / TB definition of what the 'official' designation/flag means. (teward, 19:14) * ''AGREED:'' The "Official" flag for riscv64 applies for Questing release and forward (teward, 19:18) * ''ACTION:'' rbasak to follow up in ML thread on "official" flag and riscv64 official status (teward, 19:19) * ''ACTION:'' mwhudson to handle RT ticket to IS to set riscv64 status as official for Questing onward (teward, 19:21) * '''teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC''' (teward, 19:22) * ''ACTION:'' teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) (teward, 19:22) * '''teward to write up a proposal for how the move away from the wiki will work''' (teward, 19:22) * ''ACTION:'' teward to write up a proposal for how the move away from the wiki will work (carried over) (teward, 19:22) * '''seb128 to contact release team about official status of riscv64''' (teward, 19:23) * '''seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations''' (teward, 19:23) * ''ACTION:'' seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations (teward, 19:23) === utkarsh2102 - FFe for new packages (mwhudson) === Discussion started by teward at 19:23. * ''LINK:'' https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages (utkarsh2102, 19:25) * ''AGREED:'' TB agrees that the Release Team has the purview to adjust the definition of Feature Freeze and any such FF Exception rules accordingly, and TB does not need to define a policy or intervene unless directly escalated to. (teward, 19:34) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by teward at 19:34. === Check up on community bugs and techboard bugs (standing item) === Discussion started by teward at 19:36. === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by teward at 19:38. === AOB === Discussion started by teward at 19:41. === what are the rules about what can go into multiverse (mwhudson) === Discussion started by teward at 19:42. * ''LINK:'' https://git.launchpad.net/ubuntu/+source/ubuntu-policy/tree/policy.sgml#n607 is the original policy and status quo, I think (rbasak, 19:42) === "what is a flavour" and installers (mwhudson) === Discussion started by teward at 19:49. * ''LINK:'' https://wiki.ubuntu.com/RecognizedFlavors (rbasak, 19:51) * ''LINK:'' https://wiki.ubuntu.com/RecognizedFlavors/AddingNew (rbasak, 19:51) * ''LINK:'' https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess (rbasak, 19:51) === AOB (again) === Discussion started by teward at 19:55. == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-08-26-19.01.log.html#40|Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team."]] * Motion carried (For: 0, Against: 0, Abstained: 0) * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-08-26-19.01.log.html#55|Actual vote: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team."]] * Motion carried (For: 3, Against: 0, Abstained: 0) * Voters: rbasak, mwhudson, teward == Action items, by person == * mwhudson * mwhudson to handle RT ticket to IS to set riscv64 status as official for Questing onward * rbasak * rbasak to follow up on ML thread regarding riscv64 'official' status / TB definition of what the 'official' designation/flag means. * rbasak to follow up in ML thread on "official" flag and riscv64 official status * teward * teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC (carried over) * teward to write up a proposal for how the move away from the wiki will work (carried over) * **UNASSIGNED** * seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations == People present (lines said) == * teward (150) * mwhudson (67) * rbasak (59) * utkarsh2102 (25) * meetingology (23) == Full log == 19:01 #startmeeting Technical Board 19:01 Meeting started at 19:01:47 UTC. The chair is teward. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:01 Available commands: action, commands, idea, info, link, nick 19:02 let's start with our usual 19:02 #topic Action review 19:02 #subtopic mwhudson to catch up on the previous riscv64 "official status" discussion and then drive it forward as needed 19:02 oh right yes i have some notes on this 19:03 ... 2fa ... 19:03 *sips coffee while we wait* 19:03 https://paste.ubuntu.com/p/Jc4WgqRCNM/ 19:03 so there was a bit of back and forth on the mailing list in april and may and we talked about it at a meeting in may 19:04 it sounds like currently the interpretation is that it's just a cosmetic flag 19:04 i think the only part that remains up for discussion is this: what do we, the TB, define that flag to mean? 19:04 in the end the summary is aiui: 1. the flag is cosmetic only 2. it's up to us to decide what it means 3. the release team is in favour of setting it for riscv 19:05 4. the only reason not to set it is that security updates in some situations might be delayed 19:05 #info summary: 1. the flag is cosmetic only 2. it's up to us to decide what it means 3. the release team is in favour of setting it for riscv 19:05 I think it should mean: the release team considers the quality of support to meet both user and developer expectations 19:05 5. mdeslaur (security team) is ok with it being set despite that 19:05 #info 4. the only reason not to set it is that security updates in some situations might be delayed 19:05 #info 5. mdeslaur (security team) is ok with it being set despite that 19:06 (as well as their own expectations) 19:06 rbasak: if I put my "User Experience" hat on, then I as a user would expect that security updates being delayed, either as due to the nature of the architecture or otherwise, would be a concern. 19:06 that's taking off my ITSec and other hats for that analysis 19:06 teward: sure, but I think that decision should be made between the release team and the security team 19:07 one piece of data i don't have is how often security updates for risc-v are *actually* delayed 19:07 ack. I'm in favor of this for riscv64 **so long as** the Release / Security teams post a notice that "Updates take longer for the riscv64 architecture as a side effect of the nature of the architecture - despite this, it is considered an 'official' architecture" or something to this effect 19:07 just fyi, i'm here if you need anything o/ 19:07 where "Updates" means Security or otherwise 19:07 utkarsh2102: hi! 19:08 utkarsh2102: you can go get me more coffee. :P (just kidding but yuo said you're here for 'anything' so xD) 19:08 (couldn't help but be a jokester there for a moment) 19:08 but i think if the release team and security team are happy with setting the flag i am too 19:08 hehe 19:08 lets see if I remember my 'vote' syntax... 19:08 and yes, release team is +1. 19:08 So what I'm trying to do here is leave it for the release team both for now and for the future for any other future arches 19:09 I'd like the only guidance for the release team to be as I suggested above 19:09 (from the TB, that is) 19:09 rbasak: right i guess the TB should vote on the general policy, not riscv specifically 19:09 #vote Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:09 Please vote on: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:09 Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') 19:09 oops i didn't mean to prepend #vote 19:09 #cancelvote 19:09 fek i forget my syntax 19:10 Regardless, sure, I'm fine with that 19:10 Thank you 19:10 #endvote 19:10 Voting ended on: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:10 Votes for: 0, Votes against: 0, Abstentions: 0 19:10 Motion carried 19:10 lol 19:10 mwhudson: any objection to that wording being the one we vote on? (ignore that last vote) 19:10 i too think the wording is fine 19:11 #vote Actual vote: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:11 Please vote on: Actual vote: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:11 Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') 19:11 +1 19:11 +1 received from rbasak 19:11 +1 19:11 +1 received from mwhudson 19:11 +1 19:11 +1 received from teward 19:11 #endvote 19:11 Voting ended on: Actual vote: Define 'official' arch flag as: "The release team considers the quality of support to meet both user and developer expectations, in agreement with the Security team." 19:11 Votes for: 3, Votes against: 0, Abstentions: 0 19:11 Motion carried 19:11 with that, then we don't need to vote on this for riscv64, if the Release Team and Security Team agree on it as they seem to do, then the Release Team can mark riscv64 as an official arch 19:11 I still suggest there is a notice placed on the wiki, etc. for arches that it may have update delays due to the nature of the builders / arch 19:12 any disagreement with that? 19:12 You want to suggest that to the release team? Sure :) 19:12 (as mdeslaur suggested in the may 20th discussion from logs) 19:12 no. i wonder who has the perms to change it :) 19:12 (probably launchpad.Admin) 19:12 For the change itself, utkarsh2102 already +1ed it on behalf of the release team, so I can see if the TB can change it 19:13 rbasak: want me to assign the action item to you then? I was going to action item myself to relay our decision officially to the Release Team and include our suggested guidance wrt posting a note on the wiki 19:13 or we can just have utkarsh2102 relay since they're here xD 19:14 Sure we should probably update the ML thread anyway 19:14 yes, sure, consider it done 19:14 but would be nice to post an update on the thread 19:14 exactly what rbasak said! 19:14 #action rbasak to follow up on ML thread regarding riscv64 'official' status / TB definition of what the 'official' designation/flag means. 19:14 * meetingology rbasak to follow up on ML thread regarding riscv64 'official' status / TB definition of what the 'official' designation/flag means. 19:14 there is also a bug 19:14 mwhudson: do we have that for the record, or was it in your paste and I just missed it? 19:14 Oh, one more thing 19:14 ah there it is 19:14 This is per-series I think 19:15 So we're doing this for Questing only, are we? 19:15 i agree, that status would only take keffect for Questing+ 19:15 not retroactive 19:15 rbasak: yes from me 19:15 (changing the flag takes a launchpad admin, i.e. IS) 19:16 rbasak: I assume that we would do this for questing, and then it'd apply going forward until such time we remove it? 19:16 s/we/Release Team and Sec Team/ 19:17 (if i can remember how the launchpad source works anyway) 19:18 teward: yes, official is propagated forward? 19:18 that's what i wanted to make sure of 19:18 for when I do this 19:18 er -? 19:18 #agreed The "Official" flag for riscv64 applies for Questing release and forward 19:18 AGREED: The "Official" flag for riscv64 applies for Questing release and forward 19:18 i.e. not retroactive 19:19 (yes it's an item that works to add notes in the logs) 19:19 woo we can strike an action off the list! 19:19 #action rbasak to follow up in ML thread on "official" flag and riscv64 official status 19:19 * meetingology rbasak to follow up in ML thread on "official" flag and riscv64 official status 19:19 well it adds its own item but yep. 19:19 anything else on this or should I move to the next item? 19:20 Unauthorized: HTTP Error 401: Unauthorized 19:20 b"(, 'official', 'launchpad.Admin')" 19:20 So indeed, this needs an IS ticket 19:20 utkarsh2102: do you want to file the RT for this? 19:20 teward: next item please sir 19:20 Maybe mwhudson could arrange that, please? It's probably easier for them for the request to be from a Canonical employee 19:21 rbasak: sure 19:21 I'll reply to the ML still 19:21 yes, someone can, just reply to the thread and i'll take care of it if no one else does 19:21 i guess that can be an action for next time ... 19:21 #action mwhudson to handle RT ticket to IS to set riscv64 status as official for Questing onward 19:21 * meetingology mwhudson to handle RT ticket to IS to set riscv64 status as official for Questing onward 19:21 i have an important agenda item which is a bit time sensitive - "FFe for new packages (mwhudson)" 19:21 one item gone, three more in its place xD 19:21 FTR 19:21 das=lp.load('https://api.launchpad.net/devel/ubuntu/questing/riscv64') 19:21 das.official = True 19:21 das.lp_save() 19:21 ...should be all that's needed 19:21 we're not even done with our action item reviews. i can get through these fast 19:22 yes, please, that'd be great, thank you! 19:22 #subtopic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC 19:22 #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:22 * 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:22 #subtopic teward to write up a proposal for how the move away from the wiki will work 19:22 #action teward to write up a proposal for how the move away from the wiki will work (carried over) 19:22 * meetingology teward to write up a proposal for how the move away from the wiki will work (carried over) 19:22 i assume i don't need to do anything about seb's assigned item to contact Release about official status since mwhudson did that 19:23 #subtopic seb128 to contact release team about official status of riscv64 19:23 #note see above discussion on the mwhudson assigned item 19:23 oh i didn't realize that was an action too 19:23 #subtopic seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:23 yes, consider it done 19:23 they aren't here so carrying it over 19:23 #action seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:23 * meetingology seb128 to continue working with AA and Release teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:23 #topic utkarsh2102 - FFe for new packages (mwhudson) 19:24 utkarsh2102: do you want to explain this here? 19:24 sure 19:24 mwhudson: you mean before I ask what i would consider a fairly obvious question? :P 19:25 utkarsh2102: go ahead 19:25 so in the past we had a rule which said NEW packages don't require FFE 19:25 https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages 19:25 but we've had a bit of abuse in the past 19:26 to clarify, you mean src:NEW correct? (I know the wiki says it but i want it clarified for the notes here) 19:26 so to fix it for one and all and maintain some consistency and increase stability, Release team would like to just make FFe also apply to NEW packages 19:26 src:NEW bin:NEW, both 19:27 I discussed this with the Archive Admins 19:27 in the Archive Admin sync 19:27 utkarsh2102: ok because the wiki says "new source packages" not "new source and binary packages" 19:27 hence my clarification request 19:27 :) 19:27 and all of them seemed to agree and said it'd be a quick "yes" but also discussed that TB should be making the final decision 19:27 so that brings us here 19:27 IMHO, this is fine, and is within the remit of the Release Team to decide and change the appropriate freeze requirements, process, documentation, etc, as they feel appropriate. 19:28 (so, IMHO, not a TB decision unless esclated, but by default a direct release team decision) 19:28 i think on reflection i agree with rbasak 19:28 as long as y'all agree with it and have no objection, i'd like to make it a thing and announce it on ubuntu-devel@ 19:28 the point of the feature freeze process is to ensure we, you know, get a release out 19:28 Or IOW one of the essential points of having the release team is to decide such matters :) 19:29 and of course, it'd be effective immediately 19:29 i have one thing i want to point out though that I think is still relevant 19:29 the release team has responsibility for that so they get to decide what FF actually means 19:29 and this is related to the Chaos(TM) that was encountered last release wtih... issues... that came up at a higher board and were wide reaching 19:29 I think Release Team etc still ahs to be careful with *seeded* packages 19:29 yes^ 19:29 or major major things like Qt transitions during freezes 19:30 because IIRC there were some Qt changes, etc. pushed that broke a **lot of things** and it took MAJOR man hours to fix in multiple flavors 19:30 so anything that could have major wide impact or would be seeded and affect the spun ISOs should be given extra scrutiny 19:30 other than that, I agree the Release Team has the purview to define what FF means. 19:30 i think one of the meta-points is that FF is enforced socially and that if someone just ignores the rules there's nothing technical in place to prevent them 19:30 indeed 19:31 i agree, there's no technical enforcement. 19:31 like the situation being discussed here involved FF violations already, and i'm not sure that the changes around NEW would really make a difference (except that it would have given the AAs social license to just reject them all, so maybe that is a good change) 19:32 While we're on the subject of new packages 19:32 oh boy what can of worms did we open. (FYI I have a 20:00 UTC hardstop) 19:32 There have been a few cases in the past year or so where I've come across a new package after the fact, eg. when processing an SRU, and pushed back on why it exists in the first place 19:33 teward: me too 19:33 To that end, I'd like for new packages to require some equivalent of ITP, so at least intent to have a new package is shared socially, rather than it being between a sponsor and an AA only (and I suspect AAs don't consider suitability for Ubuntu during a new review anyway) 19:33 teward: can we shuffle the order of my items so we talk about multiverse first 19:33 okeydoke, so i see no objections. i'll proceed with announcing it on -devel tomorrow and let y'all go back to the other items in the agenda. thank you! o/ 19:34 utkarsh2102: bye, go to bed!! 19:34 hehe, thanky, leaving now.. 19:34 #agreed TB agrees that the Release Team has the purview to adjust the definition of Feature Freeze and any such FF Exception rules accordingly, and TB does not need to define a policy or intervene unless directly escalated to. 19:34 AGREED: TB agrees that the Release Team has the purview to adjust the definition of Feature Freeze and any such FF Exception rules accordingly, and TB does not need to define a policy or intervene unless directly escalated to. 19:34 yay back to the agenda xD 19:34 #topic Scan the mailing list archive for anything we missed (standing item) 19:35 no new mails 19:35 I didn't see anything that we didn't already ahve action items for (like this one) 19:35 #note No new ML activity requiring follow-up 19:35 (no mail in august at all?) 19:35 mwhudson: i wouldn't be surprised if it's because of the ongoing mail problems. 19:35 there's a LOT of breakage in @*.ubuntu.com addresses lately due to the movements of main domain, etc. to forwardemail for mail handling, etc. 19:35 oh there is the project documentation thing, did that not get through moderation? 19:35 mwhudson: oh, didn't it? *checks mod panel* 19:36 It got discussed in ubuntu-devel@ instead 19:36 ah 19:36 ah ubuntu-devel 19:36 (by my request) 19:36 so still no new TB mails to worry about then. :D 19:36 #topic Check up on community bugs and techboard bugs (standing item) 19:36 I don't see any open community bugs, and no new tech board bugs. 19:37 and anyway robie replied there and i am interested in robert's reply (he is on leave currently i think) 19:37 feel free to tell me if i'm wrong. 19:37 teward: agreed on bugs, we can close the riscv one but that's been covered already 19:37 *soon 19:37 yep i'll just add a note to 'look above' xD 19:37 #note No open community bugs 19:37 #note No new techboard bugs 19:38 #note Bug 2109678 RE: RISCV official status, see this meeting's other topics and decisions. 19:38 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 19:38 my turn to chair i think 19:38 next is you mwhudson, with rbasak as backup, if i'm reading the list right 19:39 wfm 19:39 rbasak: any objections? 19:39 Did you skip the other agenda items on purpose? 19:39 chairing> sure that's fine 19:39 rbasak: no? 19:39 mwhudson: i didn't skip anything did I? 19:40 no, you are following the order on the agenda afaict 19:40 i am yes 19:40 following from https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-08-12-19.06.html 19:40 Oh right, sorry 19:40 OK 19:40 we had an interrupt between action review and scan ml because utkarsh2102 wanted to bring up a few things 19:40 :D 19:40 I always just assumed that "select a chair" would be left for last, after AOB :) 19:40 #note Next chair will be mwhudson, with rbasak as backup. 19:41 rbasak: just following the order from the last meeting :) 19:41 #topic AOB 19:41 anything else? 19:41 teward: now you are skipping things! :) 19:41 i had two extra things on the agenda 19:41 oh wait 19:42 ye my bad 19:42 i saw it now :p 19:42 one is: what are the actual rules for putting things into multiverse? i can't find any docs beyond "things not meeting the license requirements for universe" 19:42 *requires more coffee* 19:42 #topic what are the rules about what can go into multiverse (mwhudson) 19:42 https://git.launchpad.net/ubuntu/+source/ubuntu-policy/tree/policy.sgml#n607 is the original policy and status quo, I think 19:42 but there are some things we required, like it has to be freely redistributable (cos it's mirrored) 19:42 rbasak: ah i hadn't managed to find that 19:42 i think nthat policy as mentioned there is the original and still active policy 19:43 because it was always my understanding that "multiverse" would be "source unavailable but otherwise meets our license policies" 19:43 As above, I would like to see new packages announced, at least, so that if there isn't consensus, we'll find out _before_ upload. 19:44 rbasak: i agree, it'd be nice to see that done somewhere. 19:44 rbasak: yeah we don't require an ITP bug but i definitely prefer to have a needs-packaging bug when doing NEW review 19:44 is there a rendered copy of the ubuntu-policy anywhere? :/ 19:44 The thing I want is an announcement to ubuntu-devel@ (or Discourse when we move) 19:44 mwhudson: not any more 19:45 rbasak: oh hm that's a more interesting idea :) 19:45 i agree with such an announcement if 'multiverse' is the target, etc., whether to the ML or Discourse when we get there. 19:45 rbasak: so information about a new ubuntu-only packages should be broadcast in some sense, is that what you mean? 19:45 mwhudson: right 19:46 or do you mean in general for new ubuntu-only packages that don't originate from Debian? 19:46 ah there we go. 19:46 i'm slow :| 19:46 In our current process, I'd like for AAs to enforce that, since that's the only place we can ensure that it happens. But the rule should be that developers should announce. 19:47 Even for universe, FWIW. Anything that isn't a sync from Debian. 19:47 this seems like a separate topic :) want to put it on the agenda for next time? 19:47 It is, but I have too many other things to drive at the moment :-/ 19:47 (so I'm not inclined to drive this right now) 19:47 ok 19:47 If someone else would like to take it up, please do :) 19:48 #note Future action item: require a notification to either ubuntu-devel@ or Discourse when we're there for new Ubuntu-only packages regardless of target pocket. 19:48 i'll leave it as a note for us to follow up on 19:48 unless anyone objects. 19:49 yeah sounds good 19:49 next then 19:49 #topic "what is a flavour" and installers (mwhudson) 19:49 this reminds me of something that was copied to the CC a long while back, about Desktop Team making an overarching decision to push 'all flavors' to a specific installer 19:49 here i can't quite remember what i was asking for 19:49 but i'll let mwhudson explain 19:50 teward: yeah that is part of it. again though i think it was mostly a question of documentation 19:50 mwhudson: well if you remember you can put it up on the agenda with a subnote about what it was about xD 19:51 but i know part of it that came to the CC's level that I wanted to eventually follow up with you guys on was how those overarching "It affects everything" decisions are made and how that goes against current overarching governance (to my knowledge) 19:51 We have some documentation for this 19:51 https://wiki.ubuntu.com/RecognizedFlavors 19:51 i feel like the desktop team / vp of ubuntu engineering saying what installer a flavour uses doesn't really sit with how things are supposed to work 19:51 https://wiki.ubuntu.com/RecognizedFlavors/AddingNew 19:51 https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess 19:51 On "what installer a flavour uses", from my perspective, that was a request, not a mandate. 19:52 and also if flavours are causing trouble we should be more aggressive about not having them be part of a release 19:52 rbasak: it was certainly interpreted by other flavors as a mandate 19:52 (but this is a release team conversation really, per other discussions) 19:52 i remember a flurry of emails that the CC was on about that. 19:52 but i haven't seen any forceful mvement by Desktop Team / VP of Engineering 19:52 since then. 19:52 teward: had it been escalated to the TB, I would have taken the position that it wasn't a mandate unless the TB decided it was. The TB was never asked. 19:52 (and wonder if Mark had something to do with that when all the outcry reached the CC list) 19:53 rbasak: then that leads me to another item that I want to bring up 19:53 one that I should probably loop the Canonical Community Team into on that 19:53 Going directly to the CC was not helpful then, I don't think. 19:53 i think it's just dropped of the top of mind list but who knows. i am not inclined to try to stir it up again 19:54 mwhudson: rbasak: the only item i could bring up on that note is one about enforcement (at all Canonical levels) of the TB being the overarching decider of such major swooping "Everything gets affected by this decision" policy 19:54 anyway i will read the documentation rbasak linked to and propose something for next time if i think anything is needed 19:54 but i'll bring it up as an item for next meeting 19:54 teward: put it this way. Anyone can ask. If an Ubuntu developer doesn't want to do something they're asked, then they should try and seek consensus, and failing that, escalate to the TB if they need a decision. That situation was no different. 19:54 since i have less than 6 minutes now before I have a mandatory meeting with big boss CEO man who signs my paycheck 19:55 rbasak: i will note this was back in the Simon era of 'problems', and it was that and other problems that led to... problems... that the CC had to resolve 19:55 but i don't disagree 19:55 i even said this should be sent to the TB 19:55 but That Person didn't listen 19:55 (this was before I was TB) 19:55 anyways i'll raise THAT particular topic of mine later for next meeting 19:55 #topic AOB (again) 19:56 anything else in our last 3-4 minutes? 19:56 nothing from here. i need to prise a child out of bed in time for school :-p 19:56 The TB was never asked> well, not by the flavours anyway. 19:56 hah enjoy that chaos mwhudson. And if all else fails, don't forget to get the flamer. not the regular flamer, the heavy flamer. :P (WH40K reference) 19:57 rbasak: anything else for today's meeting? 19:57 Nothing else from me thanks 19:57 then... 19:57 thanks for coming everyone, until next time! 19:57 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)