19:01 <teward> #startmeeting Technical Board
19:01 <meetingology> Meeting started at 19:01:47 UTC.  The chair is teward.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:01 <meetingology> Available commands: action, commands, idea, info, link, nick
19:02 <teward> let's start with our usual
19:02 <teward> #topic Action review
19:02 <teward> #subtopic mwhudson to catch up on the previous riscv64 "official status" discussion and then drive it forward as needed
19:02 <mwhudson> oh right yes i have some notes on this
19:03 <mwhudson> ... 2fa ...
19:03 <teward> *sips coffee while we wait*
19:03 <mwhudson> https://paste.ubuntu.com/p/Jc4WgqRCNM/
19:03 <mwhudson> 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 <teward> it sounds like currently the interpretation is that it's just a cosmetic flag
19:04 <teward> i think the only part that remains up for discussion is this: what do we, the TB, define that flag to mean?
19:04 <mwhudson> 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 <mwhudson> 4. the only reason not to set it is that security updates in some situations might be delayed
19:05 <teward> #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 <rbasak> I think it should mean: the release team considers the quality of support to meet both user and developer expectations
19:05 <mwhudson> 5. mdeslaur (security team) is ok with it being set despite that
19:05 <teward> #info 4. the only reason not to set it is that security updates in some situations might be delayed
19:05 <teward> #info 5. mdeslaur (security team) is ok with it being set despite that
19:06 <rbasak> (as well as their own expectations)
19:06 <teward> 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 <teward> that's taking off my ITSec and other hats for that analysis
19:06 <rbasak> teward: sure, but I think that decision should be made between the release team and the security team
19:07 <mwhudson> one piece of data i don't have is how often security updates for risc-v are *actually* delayed
19:07 <teward> 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 <utkarsh2102> just fyi, i'm here if you need anything o/
19:07 <teward> where "Updates" means Security or otherwise
19:07 <rbasak> utkarsh2102: hi!
19:08 <teward> utkarsh2102: you can go get me more coffee.  :P  (just kidding but yuo said you're here for 'anything' so xD)
19:08 <teward> (couldn't help but be a jokester there for a moment)
19:08 <mwhudson> but i think if the release team and security team are happy with setting the flag i am too
19:08 <utkarsh2102> hehe
19:08 <teward> lets see if I remember my 'vote' syntax...
19:08 <utkarsh2102> and yes, release team is +1.
19:08 <rbasak> 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 <rbasak> I'd like the only guidance for the release team to be as I suggested above
19:09 <rbasak> (from the TB, that is)
19:09 <mwhudson> rbasak: right i guess the TB should vote on the general policy, not riscv specifically
19:09 <teward> #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 <meetingology> 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 <meetingology> 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 <teward> oops i didn't mean to prepend #vote
19:09 <teward> #cancelvote
19:09 <teward> fek i forget my syntax
19:10 <rbasak> Regardless, sure, I'm fine with that
19:10 <rbasak> Thank you
19:10 <teward> #endvote
19:10 <meetingology> 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 <meetingology> Votes for: 0, Votes against: 0, Abstentions: 0
19:10 <meetingology> Motion carried
19:10 <mwhudson> lol
19:10 <teward> mwhudson: any objection to that wording being the one we vote on?  (ignore that last vote)
19:10 <mwhudson> i too think the wording is fine
19:11 <teward> #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 <meetingology> 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 <meetingology> 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 <rbasak> +1
19:11 <meetingology> +1 received from rbasak
19:11 <mwhudson> +1
19:11 <meetingology> +1 received from mwhudson
19:11 <teward> +1
19:11 <meetingology> +1 received from teward
19:11 <teward> #endvote
19:11 <meetingology> 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 <meetingology> Votes for: 3, Votes against: 0, Abstentions: 0
19:11 <meetingology> Motion carried
19:11 <teward> 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 <teward> 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 <teward> any disagreement with that?
19:12 <rbasak> You want to suggest that to the release team? Sure :)
19:12 <teward> (as mdeslaur suggested in the may 20th discussion from logs)
19:12 <mwhudson> no. i wonder who has the perms to change it :)
19:12 <mwhudson> (probably launchpad.Admin)
19:12 <rbasak> 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 <teward> 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 <teward> or we can just have utkarsh2102 relay since they're here xD
19:14 <rbasak> Sure we should probably update the ML thread anyway
19:14 <utkarsh2102> yes, sure, consider it done
19:14 <utkarsh2102> but would be nice to post an update on the thread
19:14 <utkarsh2102> exactly what rbasak said!
19:14 <teward> #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 <mwhudson> there is also a bug
19:14 <teward> mwhudson: do we have that for the record, or was it in your paste and I just missed it?
19:14 <rbasak> Oh, one more thing
19:14 <teward> ah there it is
19:14 <rbasak> This is per-series I think
19:15 <rbasak> So we're doing this for Questing only, are we?
19:15 <teward> i agree, that status would only take keffect for Questing+
19:15 <teward> not retroactive
19:15 <mwhudson> rbasak: yes from me
19:15 <mwhudson> (changing the flag takes a launchpad admin, i.e. IS)
19:16 <teward> 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 <teward> s/we/Release Team and Sec Team/
19:17 <mwhudson> (if i can remember how the launchpad source works anyway)
19:18 <mwhudson> teward: yes, official is propagated forward?
19:18 <teward> that's what i wanted to make sure of
19:18 <teward> for when I do this
19:18 <mwhudson> er -?
19:18 <teward> #agreed The "Official" flag for riscv64 applies for Questing release and forward
19:18 <meetingology> AGREED: The "Official" flag for riscv64 applies for Questing release and forward
19:18 <teward> i.e. not retroactive
19:19 <teward> (yes it's an item that works to add notes in the logs)
19:19 <mwhudson> woo we can strike an action off the list!
19:19 <teward> #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 <teward> well it adds its own item but yep.
19:19 <teward> anything else on this or should I move to the next item?
19:20 <rbasak> Unauthorized: HTTP Error 401: Unauthorized
19:20 <rbasak> b"(<DistroArchSeries object>, 'official', 'launchpad.Admin')"
19:20 <rbasak> So indeed, this needs an IS ticket
19:20 <mwhudson> utkarsh2102: do you want to file the RT for this?
19:20 <mwhudson> teward: next item please sir
19:20 <rbasak> Maybe mwhudson could arrange that, please? It's probably easier for them for the request to be from a Canonical employee
19:21 <mwhudson> rbasak: sure
19:21 <rbasak> I'll reply to the ML still
19:21 <utkarsh2102> yes, someone can, just reply to the thread and i'll take care of it if no one else does
19:21 <mwhudson> i guess that can be an action for next time ...
19:21 <teward> #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 <utkarsh2102> i have an important agenda item which is a bit time sensitive - "FFe for new packages (mwhudson)"
19:21 <teward> one item gone, three more in its place xD
19:21 <rbasak> FTR
19:21 <rbasak> das=lp.load('https://api.launchpad.net/devel/ubuntu/questing/riscv64')
19:21 <rbasak> das.official = True
19:21 <rbasak> das.lp_save()
19:21 <rbasak> ...should be all that's needed
19:21 <teward> we're not even done with our action item reviews.  i can get through these fast
19:22 <utkarsh2102> yes, please, that'd be great, thank you!
19:22 <teward> #subtopic teward to follow up with "who can vote" and documentation at https://ubuntu.com/community/governance/technical-board with the CC
19:22 <teward> #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 <teward> #subtopic teward to write up a proposal for how the move away from the wiki will work
19:22 <teward> #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 <teward> 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 <teward> #subtopic seb128 to contact release team about official status of riscv64
19:23 <teward> #note see above discussion on the mwhudson assigned item
19:23 <mwhudson> oh i didn't realize that was an action too
19:23 <teward> #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 <mwhudson> yes, consider it done
19:23 <teward> they aren't here so carrying it over
19:23 <teward> #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 <teward> #topic utkarsh2102 - FFe for new packages (mwhudson)
19:24 <mwhudson> utkarsh2102: do you want to explain this here?
19:24 <utkarsh2102> sure
19:24 <teward> mwhudson: you mean before I ask what i would consider a fairly obvious question?  :P
19:25 <teward> utkarsh2102: go ahead
19:25 <utkarsh2102> so in the past we had a rule which said NEW packages don't require FFE
19:25 <utkarsh2102> https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
19:25 <utkarsh2102> but we've had a bit of abuse in the past
19:26 <teward> to clarify, you mean src:NEW correct? (I know the wiki says it but i want it clarified for the notes here)
19:26 <utkarsh2102> 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 <utkarsh2102> src:NEW bin:NEW, both
19:27 <utkarsh2102> I discussed this with the Archive Admins
19:27 <utkarsh2102> in the Archive Admin sync
19:27 <teward> utkarsh2102: ok because the wiki says "new source packages" not "new source and binary packages"
19:27 <teward> hence my clarification request
19:27 <teward> :)
19:27 <utkarsh2102> 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 <utkarsh2102> so that brings us here
19:27 <rbasak> 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 <rbasak> (so, IMHO, not a TB decision unless esclated, but by default a direct release team decision)
19:28 <mwhudson> i think on reflection i agree with rbasak
19:28 <utkarsh2102> 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 <mwhudson> the point of the feature freeze process is to ensure we, you know, get a release out
19:28 <rbasak> Or IOW one of the essential points of having the release team is to decide such matters :)
19:29 <utkarsh2102> and of course, it'd be effective immediately
19:29 <teward> i have one thing i want to point out though that I think is still relevant
19:29 <mwhudson> the release team has responsibility for that so they get to decide what FF actually means
19:29 <teward> 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 <teward> I think Release Team etc still ahs to be careful with *seeded* packages
19:29 <utkarsh2102> yes^
19:29 <teward> or major major things like Qt transitions during freezes
19:30 <teward> 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 <teward> so anything that could have major wide impact or would be seeded and affect the spun ISOs should be given extra scrutiny
19:30 <teward> other than that, I agree the Release Team has the purview to define what FF means.
19:30 <mwhudson> 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 <utkarsh2102> indeed
19:31 <teward> i agree, there's no technical enforcement.
19:31 <mwhudson> 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 <rbasak> While we're on the subject of new packages
19:32 <teward> oh boy what can of worms did we open.  (FYI I have a 20:00 UTC hardstop)
19:32 <rbasak> 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 <mwhudson> teward: me too
19:33 <rbasak> 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 <mwhudson> teward: can we shuffle the order of my items so we talk about multiverse first
19:33 <utkarsh2102> 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 <mwhudson> utkarsh2102: bye, go to bed!!
19:34 <utkarsh2102> hehe, thanky, leaving now..
19:34 <teward> #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 <meetingology> 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 <teward> yay back to the agenda xD
19:34 <teward> #topic Scan the mailing list archive for anything we missed (standing item)
19:35 <mwhudson> no new mails
19:35 <teward> I didn't see anything that we didn't already ahve action items for (like this one)
19:35 <teward> #note No new ML activity requiring follow-up
19:35 <mwhudson> (no mail in august at all?)
19:35 <teward> mwhudson: i wouldn't be surprised if it's because of the ongoing mail problems.
19:35 <teward> 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 <mwhudson> oh there is the project documentation thing, did that not get through moderation?
19:35 <teward> mwhudson: oh, didn't it?  *checks mod panel*
19:36 <rbasak> It got discussed in ubuntu-devel@ instead
19:36 <teward> ah
19:36 <mwhudson> ah ubuntu-devel
19:36 <rbasak> (by my request)
19:36 <teward> so still no new TB mails to worry about then.  :D
19:36 <teward> #topic Check up on community bugs and techboard bugs (standing item)
19:36 <teward> I don't see any open community bugs, and no new tech board bugs.
19:37 <mwhudson> and anyway robie replied there and i am interested in robert's reply (he is on leave currently i think)
19:37 <teward> feel free to tell me if i'm wrong.
19:37 <mwhudson> teward: agreed on bugs, we can close the riscv one but that's been covered already
19:37 <mwhudson> *soon
19:37 <teward> yep i'll just add a note to 'look above' xD
19:37 <teward> #note No open community bugs
19:37 <teward> #note No new techboard bugs
19:38 <teward> #note Bug 2109678 RE: RISCV official status, see this meeting's other topics and decisions.
19:38 <teward> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:38 <mwhudson> my turn to chair i think
19:38 <teward> next is you mwhudson, with rbasak as backup, if i'm reading the list right
19:39 <mwhudson> wfm
19:39 <teward> rbasak: any objections?
19:39 <rbasak> Did you skip the other agenda items on purpose?
19:39 <rbasak> chairing> sure that's fine
19:39 <teward> rbasak: no?
19:39 <teward> mwhudson: i didn't skip anything did I?
19:40 <mwhudson> no, you are following the order on the agenda afaict
19:40 <teward> i am yes
19:40 <teward> following from https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-08-12-19.06.html
19:40 <rbasak> Oh right, sorry
19:40 <rbasak> OK
19:40 <teward> we had an interrupt between action review and scan ml because utkarsh2102 wanted to bring up a few things
19:40 <teward> :D
19:40 <rbasak> I always just assumed that "select a chair" would be left for last, after AOB :)
19:40 <teward> #note Next chair will be mwhudson, with rbasak as backup.
19:41 <teward> rbasak: just following the order from the last meeting :)
19:41 <teward> #topic AOB
19:41 <teward> anything else?
19:41 <mwhudson> teward: now you are skipping things! :)
19:41 <mwhudson> i had two extra things on the agenda
19:41 <teward> oh wait
19:42 <teward> ye my bad
19:42 <teward> i saw it now :p
19:42 <mwhudson> 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 <teward> *requires more coffee*
19:42 <teward> #topic what are the rules about what can go into multiverse (mwhudson)
19:42 <rbasak> https://git.launchpad.net/ubuntu/+source/ubuntu-policy/tree/policy.sgml#n607 is the original policy and status quo, I think
19:42 <mwhudson> but there are some things we required, like it has to be freely redistributable (cos it's mirrored)
19:42 <mwhudson> rbasak: ah i hadn't managed to find that
19:42 <teward> i think nthat policy as mentioned there is the original and still active policy
19:43 <teward> because it was always my understanding that "multiverse" would be "source unavailable but otherwise meets our license policies"
19:43 <rbasak> 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 <teward> rbasak: i agree, it'd be nice to see that done somewhere.
19:44 <mwhudson> 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 <mwhudson> is there a rendered copy of the ubuntu-policy anywhere? :/
19:44 <rbasak> The thing I want is an announcement to ubuntu-devel@ (or Discourse when we move)
19:44 <rbasak> mwhudson: not any more
19:45 <mwhudson> rbasak: oh hm that's a more interesting idea :)
19:45 <teward> i agree with such an announcement if 'multiverse' is the target, etc., whether to the ML or Discourse when we get there.
19:45 <mwhudson> rbasak: so information about a new ubuntu-only packages should be broadcast in some sense, is that what you mean?
19:45 <rbasak> mwhudson: right
19:46 <teward> or do you mean in general for new ubuntu-only packages that don't originate from Debian?
19:46 <teward> ah there we go.
19:46 <teward> i'm slow :|
19:46 <rbasak> 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 <rbasak> Even for universe, FWIW. Anything that isn't a sync from Debian.
19:47 <mwhudson> this seems like a separate topic :) want to put it on the agenda for next time?
19:47 <rbasak> It is, but I have too many other things to drive at the moment :-/
19:47 <rbasak> (so I'm not inclined to drive this right now)
19:47 <mwhudson> ok
19:47 <rbasak> If someone else would like to take it up, please do :)
19:48 <teward> #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 <teward> i'll leave it as a note for us to follow up on
19:48 <teward> unless anyone objects.
19:49 <mwhudson> yeah sounds good
19:49 <teward> next then
19:49 <teward> #topic "what is a flavour" and installers (mwhudson)
19:49 <teward> 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 <mwhudson> here i can't quite remember what i was asking for
19:49 <teward> but i'll let mwhudson explain
19:50 <mwhudson> teward: yeah that is part of it. again though i think it was mostly a question of documentation
19:50 <teward> mwhudson: well if you remember you can put it up on the agenda with a subnote about what it was about xD
19:51 <teward> 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 <rbasak> We have some documentation for this
19:51 <rbasak> https://wiki.ubuntu.com/RecognizedFlavors
19:51 <mwhudson> 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 <rbasak> https://wiki.ubuntu.com/RecognizedFlavors/AddingNew
19:51 <rbasak> https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess
19:51 <rbasak> On "what installer a flavour uses", from my perspective, that was a request, not a mandate.
19:52 <mwhudson> and also if flavours are causing trouble we should be more aggressive about not having them be part of a release
19:52 <teward> rbasak: it was certainly interpreted by other flavors as a mandate
19:52 <mwhudson> (but this is a release team conversation really, per other discussions)
19:52 <teward> i remember a flurry of emails that the CC was on about that.
19:52 <teward> but i haven't seen any forceful mvement by Desktop Team / VP of Engineering
19:52 <teward> since then.
19:52 <rbasak> 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 <teward> (and wonder if Mark had something to do with that when all the outcry reached the CC list)
19:53 <teward> rbasak: then that leads me to another item that I want to bring up
19:53 <teward> one that I should probably loop the Canonical Community Team into on that
19:53 <rbasak> Going directly to the CC was not helpful then, I don't think.
19:53 <mwhudson> 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 <teward> 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 <mwhudson> anyway i will read the documentation rbasak linked to and propose something for next time if i think anything is needed
19:54 <teward> but i'll bring it up as an item for next meeting
19:54 <rbasak> 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 <teward> 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 <teward> 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 <teward> but i don't disagree
19:55 <teward> i even said this should be sent to the TB
19:55 <teward> but That Person didn't listen
19:55 <teward> (this was before I was TB)
19:55 <teward> anyways i'll raise THAT particular topic of mine later for next meeting
19:55 <teward> #topic AOB (again)
19:56 <teward> anything else in our last 3-4 minutes?
19:56 <mwhudson> nothing from here. i need to prise a child out of bed in time for school :-p
19:56 <rbasak> The TB was never asked> well, not by the flavours anyway.
19:56 <teward> 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 <teward> rbasak: anything else for today's meeting?
19:57 <rbasak> Nothing else from me thanks
19:57 <teward> then...
19:57 <teward> thanks for coming everyone, until next time!
19:57 <teward> #endmeeting