#ubuntu-meeting-2 2014-11-04
<dsmythies> I do not see pmatulis. I thought there was supposed to be a docs meeting now. ?
<GunnarHj> Me too
<GunnarHj> A reminder on the list would probably have been wise...
<dsmythies> Is there anybody besides Gunnar and myself here for the doc team meeting?
<dsmythies> GunnarHj - since you and I communicate reguarly via e-mail, and since nobody else is here, let's terminate the meeting.
<GunnarHj> dsmythies: Maybe we could hold it you and me. At least we could clean up the meeting page a bit.
<dsmythies> O.K.
<dsmythies> license item. I am O.K. with. and I do not think it prevents me from having my debug mirror of help.ubuntu.com on my site
<GunnarHj> No problem here either.
<dsmythies> new nagivation for help.ubuntu.com seems stalled.
<GunnarHj> Right.
<GunnarHj> Suppose we can remove the .htaccess action item.
<dsmythies> I am very happy with the current state of .htaccess and robots.txt and, finally the CSE. I think search results are actually useful now.
<dsmythies> Thanks for your hardword on that
<dsmythies> Thanks for your hard work on that
<GunnarHj> Thank you. We did it together. :)
<GunnarHj> There is one thing I thought about as regards the CSE:
<dsmythies> Dustin had wanted to review in "a few days". I was thinking to ask him to review in two months.
<dsmythies> go ahead
<GunnarHj> Ask Ubuntu is typically very dominating among the search results.
<dsmythies> I agree, and have been experimenting trying to get the order different, but haven't figured it out.
<GunnarHj> I think it would be good, if it's possible, to show the "Official" items first.
<dsmythies> ...using my CSEs, just for testing.
<GunnarHj> Ok, you already tried it.
<dsmythies> Lets aks Dustin if he knows how to change the reporting order. I'll double check my tests first.
<GunnarHj> dsmythies: Good idea.
<dsmythies> I agree that ideally we would like "Official" first.
<GunnarHj> The current state of the Google index does not include everything. It seems to take a few more weeks until everything is indexed under "stable".
<GunnarHj> (and we disabled 12.04, 14.04 etc.)
<dsmythies> What about the including wiki review being pushed out to 2 months? I was also thinking to go on list and ask people to try it.
<dsmythies> Yes, the full google database updates will take significant time.
<GunnarHj> What's "the including wiki review"?
<GunnarHj> Aha. Now I understand. :)
<GunnarHj> Sure, why not?
<dsmythies> Dustin had wanted to review the includion of wiki.ubuntu.com after a few days. I was wanting longer.
<GunnarHj> As a side-effect we call people's attention to that rather nifty search tool.
<dsmythies> Yes, exactly. I think people staopped using it because it basically didn't work.
<dsmythies> Now, I think it is very useful.
<GunnarHj> I'm sure Dustin don't mind waiting. But let's ask him.
<GunnarHj> Yes, I think it's very useful too. Should be promoted somehow.
<dsmythies> I do not know how to run IRC meetings, but...
<dsmythies> Action: Doug to re-do CSE order of reporting tests, Then ask for help from Dustin.
<dsmythies> Action: Doug ask Dustin for more time before review
<GunnarHj> That's excellent. :)
<dsmythies> Action: ? go on-list and ask people to try search tool.
<GunnarHj> I can take that one.
<dsmythies> O.K. moving on...
<GunnarHj> Summit?
<dsmythies> Yes. I know nothing about it.
<GunnarHj> Not much to know, I think. The question I wanted to ask if we want to have our own session (as we use to have - "Documentation roundtable" or something)
<dsmythies> I have no strong opinion. We again seem to lacking people helping.
<GunnarHj> Right. Let's pmatulis decide.
<dsmythies> O.K.
<dsmythies> Anything for Desktop?
<GunnarHj> Don't think so. Everything is prepared for vivid. So later on I'm going to post something to the list.
<GunnarHj> Btw, did you talk about the branch naming matter with pmatulis?
<dsmythies> I would like to nail down whatever procedure for the mascot creature icon. Was hoping antdillon would take that one.
<dsmythies> For Serverguide "trunk" series. pmatulis never replied. I'll ping again and then just do it.
<GunnarHj> I can't see why he would mind.
<dsmythies> He is the serverguide driver, so I would like to get his buy-in first. (I wonder if he is away right now)
<GunnarHj> Don't know.
<dsmythies> For help.ubuntu.com: I was going to use this just after release time to do some cleanup. There are files that are not needed and other odd things.
<dsmythies> Also, I think I have somehow messed up the installation guide.
<GunnarHj> Ok.
<GunnarHj> What's the actual state of the installation guide? Is it reasonably up-to-date?
<dsmythies> I don't really know. The thing is that nodoby maintains it. I thought I had found someone willing to take it on, but they bailed.
<GunnarHj> Then I think we should raise the question if we should keep publishing it.
<dsmythies> my last merge proposal, which reflects what was published, is still sitting there.
<dsmythies> The recommandation from both Jermey and Matt was to stop publishing it...
<GunnarHj> Who thought otherwise?
<dsmythies> However, there are links from other docs (the serverguide) that would get broken.
<GunnarHj> Sure, I don't mean we should drop it just like that.
<dsmythies> So, I have kept it. But the action could be to drop it and clean up the resulting dea links.
<dsmythies> I looked at is breifly this last cycle, it might not be so hard.
<GunnarHj> Sounds like a good idea.
<GunnarHj> But OTOH...
<dsmythies> Action: Doug to look into NOT publishing the installation guide in future, and posssibly retroactively to 14.04.
<GunnarHj> Documentation of how to install Ubuntu is very important. Currently I feel we don't have anything really good.
<dsmythies> Note: the package would still exist, but we (the docteam) would be out of it.
<GunnarHj> Ok.
<dsmythies> I agree, but simply don't know what to do. I have tried and tried to get someone to be the driver.
<GunnarHj> But wouldn't it be reasonable that we as a (long term) task tried to make something better?
<GunnarHj> Ok, the usual problem. :(
<GunnarHj> In any case, I agree with the action point. We shouldn't keep publishing something that nobody really maintains.
<dsmythies> Also it was nver converted to the new theme.
<GunnarHj> Probably because Matt and Jeremy wanted to drop it...
<dsmythies> Anything else?
<GunnarHj> Nope, don't think so.
<dsmythies> O.K. then meeting over.
<dsmythies> hmmm... I supoose this isn't going to log properly.
<GunnarHj> No, but I suppose it will be available at http://irclogs.ubuntu.com/ at least?
<dsmythies> Yes, pleia2 got this meeting room added to those web pages.
<GunnarHj> Confirmed. :)
<dsmythies> O.K. Gunnar bye for now.
<GunnarHj> Bye Doug. We'll keep in touch.
#ubuntu-meeting-2 2016-11-08
 * slangasek waves
 * foggalong waves back
 * stgraber waves from Bucharest
 * mdeslaur waves
<infinity> o/
<mdeslaur> ok, let's get started
<mdeslaur> #startmeeting
<meetingology> Meeting started Tue Nov  8 17:01:11 2016 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<mdeslaur> [topic] Apologies
<mdeslaur> none
<mdeslaur> [topic] Action review
<infinity> defer
<mdeslaur> infinity: both?
<infinity> Without looking, yes.  It's been one of those months.
<mdeslaur> ack
<mdeslaur> ACTION: mdeslaur to look into flavour CVE tracking
<mdeslaur> I updated and fixed the tracking scripts
<mdeslaur> results are here: http://people.canonical.com/~ubuntu-security/cve/flavors.html
<mdeslaur> while there still may be improvements and adjustments, I think the action item is completed
<slangasek> nice!
<infinity> mdeslaur: I assume the second link for each flavour includes main?
<infinity> Or includes closed?
<mdeslaur> that's the intention, but some main packages are showing up in the first link
<mdeslaur> I need to fix that
<infinity> Well, it's probably a good enough state to move to a second step of pointing the flavour folks at it, so they can start shouldering some responsibility there.
<slangasek> mdeslaur: feature request: summary counts on the top-level page :)
<mdeslaur> infinity: ok, let me see if I can quickly fix the main issue and then we(I) can send out an email
<mdeslaur> slangasek: ack
<mdeslaur> [topic] budgie-remix/ubuntu budgie: package-set maintainer application -fossfreedom
<slangasek> fossfreedom: hi there
<mdeslaur> so...doesn't that a DMB topic?
<fossfreedom> Hi !
<mdeslaur> hi fossfreedom!
<mdeslaur> hi HEXcube
<slangasek> for the packageset, yes, that's rightly a DMB topic
<HEXcube> Hi
<mdeslaur> right
<slangasek> fossfreedom, HEXcube: for the packageset topic, can we redirect you to https://wiki.ubuntu.com/DeveloperMembershipBoard ?
<fossfreedom> ok thanks.  will read etc.
<mdeslaur> [topic] budgie-remix/ubuntu official community flavour application - fossfreedom
<slangasek> creating the packageset itself should be non-controversial, provided the TB gives its +1 to the second topic
<mdeslaur> fossfreedom: so, can you give us the status on getting all your packages in the archive?
<slangasek> [LINK] https://lists.ubuntu.com/archives/technical-board/2016-October/002261.html
<fossfreedom> ok - all packages are now in zesty ... except one which requires a version number update.  I've resubmitted that and awaiting a review
<slangasek> I was pleased to see a number of these packages go into the archive before 16.10 released
<fossfreedom> can I say thanks to jeremy bica and daniel holbach for helping here
<slangasek> fossfreedom: what is the remaining package, and where have you submitted it for review?  (not a blocker for us approving you, but I would like to help make sure it's on track)
<fossfreedom> let me give you the link...
<fossfreedom> https://bugs.launchpad.net/ubuntu/+bug/1594596
<fossfreedom> "arc-firefox-theme" -
<slangasek> thanks
<slangasek> you seem to be doing all the right things to get integrated as an official flavor
<infinity> Are there preliminary seeds and metapackages?
<slangasek> there are some technical integration points that need to be followed through on ^^ to be truly official
<slangasek> the fact that searching wiki.ubuntu.com for 'official flavo[u]rs' returns no results seems like a bug
<slangasek> anyone else know if we have a wiki page somewhere documenting the requirements?
<infinity> Not sure if we do, or if it just comes up as people try to integrate. :P
<stgraber> I thought we did
<slangasek> I thought we did also
<mdeslaur> I only know of this: https://wiki.ubuntu.com/RecognizedFlavors
<stgraber> was going to link to that one
<slangasek> aha!
<stgraber> that's the one I remembered
<mdeslaur> seems like it has what we're looking for
<slangasek> thanks, adding some redirects
<infinity> Yeah.  That's what their presentation referenced as well, I'd say.
<infinity> It doesn't have gritty technical details like seeds/metas, though.
<slangasek> ah right, this was the chicken and egg thing where TB had to approve it first ;)
<infinity> Just higher level commitment and staffing type things.
<slangasek> infinity: yeah, that's buried under "release team agrees to help do the work"
<slangasek> so
<infinity> And, indeed, I don't expect them to have it all ready before approval, just to have looked at how it works and know what they're getting into.
<slangasek> I feel a strong urge to bikeshed the process documented on that page
<infinity> I'm shocked.
<slangasek> but in the meantime, I don't think it should block us from blessing budgie
<slangasek> others?
<slangasek> infinity: ;)
<infinity> I find it hard to have opinions about flavors until I've worked with them for 6-12 months.  Can we write a process document for firing them? ;)
<mdeslaur> Does anyone have any thing else they would like to ask them before we vote?
<infinity> But their presentation seems to address what the wiki's looking for.
<infinity> The only nit would be the "upload rights" thing, which seems to be a bit of a question mark.
<stgraber> infinity: you can write that process and then try it with Edubuntu :)
<infinity> Since creating a package set doesn't do much without someone to give rights to.
<slangasek> infinity: right - should we require the DMB review first?
<mdeslaur> we can make the approval conditional on it
<infinity> Yeah, that.
<infinity> But unless there's a long history of sponsored uploads, etc, it's not exactly a slam-dunk when someone comes along and says "I want upload rights to a bunch of packages".
<infinity> (Maybe there is a history, I haven't been watching)
<mdeslaur> ok, so DMB review first?
<infinity> Anyhow, I'd be fine with approving the flavour, conditional on approval of uploaders, and a solid time commitment from the lead that they'll be able to work with the cdimage/release folks to get integrated with seedy things and the like.
<slangasek> I agree with infinity
<infinity> I don't think punting them to the DMB without a decision here is helpful, it'll just end up in a loop.
<mdeslaur> ok, let's vote for a conditional approval
<slangasek> I don't want us to bounce them back and forth between committee meetings for months at a time
<infinity> Feel free to copy/waste my above vomit as the vote question. :P
<mdeslaur> [VOTE] Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
<meetingology> Please vote on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
<meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
<slangasek> +1
<meetingology> +1 received from slangasek
<mdeslaur> +1
<meetingology> +1 received from mdeslaur
<infinity> I'll try to make the appropriate DMB meeting to provide some continuity to the discussion.
<infinity> +1
<meetingology> +1 received from infinity
<stgraber> +1
<meetingology> +1 received from stgraber
<mdeslaur> [ENDVOTE]
<meetingology> Voting ended on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
<meetingology> Votes for:4 Votes against:0 Abstentions:0
<meetingology> Motion carried
<mdeslaur> yay, congrats!
<infinity> Err, s/budgie-remix/ubuntu-budgie/
<infinity> But yeah.
<mdeslaur> oh, woops :P
<infinity> Or budgebuntu, or whatever.
<fossfreedom> all - many thanks on behalf of the team - Ubuntu Budgie!
<infinity> I think they stated a preference for Ubuntu Budgie, though. :)
<slangasek> fossfreedom: welcome :)
<foggalong> Thank you!
<slangasek> (ubudgtu)
<HEXcube> Yeah, Ubuntu Budgie!
<Udara> Thank you very much !
<foggalong> It'll always be Bubuntu in my heart
<HEXcube> Thanx a lot! ð
<mdeslaur> [topic] drop the powerpc port
<mdeslaur> infinity: you'll need to buy a new workstation
<infinity> :P
<slangasek> oh man was that the holdup?
<mdeslaur> yep, our sole remaining user
<slangasek> we can take up a collection
<infinity> Yeah, not true. :P
<doko> well, he still can put them into heating mode without security updates ...
<mdeslaur> hehe
<infinity> While I do have some PPC kit here at my feet, I'm not the sole user.
<infinity> I had someone asking me this morning if we were dropping the port due to Debian's announcement.
<infinity> I said I didn't think we had plans to.
<infinity> Then I read doko's agenda point. :P
<slangasek> well, it's been a discussion point before now
<slangasek> I don't expect this to be decided by the TB in this meeting
<doko> if you want a new toy, do x32 ;)
<infinity> Ick.
<slangasek> but I do think we ought to help guide the discussion
<infinity> So, long term, I think we should aim to drop *all* 32-bit ports.
<infinity> For reasons too long to list.
<slangasek> I understand that the question will also be raised on the ubuntu-server list
<infinity> But short term, PPC is the most obvious candidate to drop, if we feel we should drop something.
<slangasek> yes, and there've been discussions about winding down i386 also
<slangasek> so it's not as if we're picking on powerpc disproportionately :)
<mdeslaur> I feel like this depends on how many people step up to volunteer maintaining it
<infinity> From a maintenance perspective, it's not a huge burden.  The problems are generally in leaf compilers (fpc!) that most users don't actually care about.
<infinity> ie: we could just not care about those issues, and it wouldn't actually matter.
<doko> define "step up" ...
<mdeslaur> well, commit :P
<infinity> Define "maintain" is the better question.
<slangasek> I contest the claim that it's not a huge burden; there's a diffuse cost that is invisible to those who care about the arch, and which has never been measured
<doko> I don't want to end up with people claiming, without doing. and that's the case for powerpc for a long time
<mdeslaur> I do believe the burden will become greater if Debian isn't doing it anymore
<slangasek> infinity: packages that FTBFS and stall proposed-migration can't just be ignored.  There are generally some arch specific for each !x86 arch at any given moment, and it costs attention to fix these
<infinity> doko: The implication there is either that something's very broken, or that you've been fixing all the bugs.  Are either of those true?
<slangasek> would we be ok with a policy by the AA team to unconditionally remove powerpc binaries whenever they're seen to hold up migrations?
<infinity> slangasek: Yes, this is true.  And sometimes it's PPC-specific.  Rarely, but sometimes.
<infinity> slangasek: If removals aren't done haphazardly in a way that bumps the uninstallability count, sure.
<slangasek> ok
<doko> I don't agree about the "sometimes". everybody has to look at migrations, ftbfs, etc ...
<slangasek> mdeslaur: I can take an action with my AA hat to draft a proposed policy around this to ubuntu-release, as a first step
<mdeslaur> ok
<doko> look at mono for xenial, look at openjdk failures, continue that list
<doko> who is still using that?
<doko> taht port?
<mdeslaur> [ACTION] slangasek to draft a proposed AA policy to ubuntu-release about removing powerpc binaries that hold up migrations
<meetingology> ACTION: slangasek to draft a proposed AA policy to ubuntu-release about removing powerpc binaries that hold up migrations
<mdeslaur> we can revisit this once we have a list of powerpc binaries that have been removed
<doko> so when gcc and binutils stop building, can we remove these from the archive then?
<mdeslaur> if nobody fixed them, the choice will be easy
<infinity> doko: Short of your making them not build, is that going to happen?
<doko> infinity: well, look at the gcc-snapshot ftbfs during the past ... it costs time to look at those, prepare test cases, forward them
<doko> who else is doing this work?
<slangasek> fwiw there are 22 packages stalled in zesty-proposed at the moment due to powerpc-specific build failures
<slangasek> (plus a smattering of 32-bit build failures, and big-endian build failures)
<mdeslaur> ouch, that's a lot
<slangasek> mdeslaur: not compared to the total -proposed count of 775; but that's another story
<infinity> A large chunk of those are all in the same package set.
<mdeslaur> sure, but it means _someone_ has to fix 22 packages currently, and that will only get worse
<infinity> And dep-wait.
<doko> for openjdk-9, powerpc will be the only port still needing the zero vm. who will maintain that?
<infinity> doko: openjdk-9 appears to be broken on armhf too.
<slangasek> mdeslaur: well, it ebbs and flows.  I don't expect it to increase much in the near term, and indeed we do already remove binaries to unblock migration when it's clear no one's fixing them
<doko> sure, but that one has a hotspot port now. oracle open sourced it
<mdeslaur> I don't feel comfortable deciding today whether we should remove it or not without it being proposed somewhere and seeing objections
<slangasek> doko: "who else is doing the work" - I'm not sure this question is the right way around.  powerpc is a community port; do you feel an obligation to do this work yourself, and if so, why?
<doko> slangasek: I can't finish my work if I ignore powerpc issues which hinder migration and ftbfs
<infinity> slangasek: So, looking at your analysis, I see a bunch of 32-bit, a few big-endian, a few ppc* (ie: both ports), and so far two powerpc-only (though with chain reactions, like kodi*)
 * doko wonders why powerpc ports are doing that analysis only now ...
<doko> slangasek: please could you point out who is "powerpc community"?
<slangasek> doko: but you shouldn't have to carry water for the powerpc community; and the powerpc community shouldn't have to track status in 100 different places to know what might be blocking you.  shouldn't there be an escalation path for letting a community port's community know about blocking issues, with deadlines for dropping if they don't fix?
<infinity> (I would argue that gcc-snapshot doesn't belong on a list of packages that need to be fixed urgently to avoid port death)
<slangasek> infinity: sure, in that case I think the real deadline is "when it stops being snapshot"
<doko> no, but then it makes death easier when going to the next compiler version
<infinity> Except that the stable release process includes porters testing and sorting issues.
<infinity> The daily snapshot process doesn't.
<infinity> (Maybe it should, but I don't control gcc upstream)
<doko> powerpc isn't neith a primary nor secondary GCC release architecture
<infinity> The port maintainers still test, submit results, and fix issues.
<mdeslaur> doko: so ignore ftbfs on powerpc, and ask an AA to unblock migrations
<mdeslaur> and when it bitrots to the point where it doesn't make sense anymore, we'll kill it
<slangasek> doko: but I agree with infinity's point here - failures in gcc-snapshot, or failures of packages to build /with/ gcc-snapshot, are not a measure of the health of a port
<doko> infinity: who is "port maintainers"?
<infinity> I don't recall who the gcc powerpc port maintainer is right now.
<slangasek> mdeslaur: that still puts a burden on the broader team, which we don't currently measure
<infinity> I assume someone IBMish.
<doko> no, not that much interested anymore
<mdeslaur> slangasek: to unblock migrations?
<slangasek> doko: I do think that you should treat snapshot-related failures as something to signal to the powerpc community, but not take responsibility for fixing yourself (unless you want to)
<slangasek> mdeslaur: yes
<mdeslaur> can we get an arch disabled from migration blockages?
<slangasek> mdeslaur: 1) someone has to notice the migration is blocked, 2) an AA has to remove binary packages, recursively
<slangasek> we can, but that's equivalent to saying the port doesn't matter
<infinity> mdeslaur: Yes, but that does more harm than good.
<doko> slangasek: no, I'm not going to present every issue on a silver tablet to the powerpc porters, and the powerpc porters aren't doing that themself
<slangasek> infinity: well, depending on who's measuring the harm and the good. it certainly does save AA time ;)
<infinity> slangasek: The way britney's implemented, it does far more harm than good. :P
<infinity> (Even to !ppc)
<mdeslaur> infinity: if the powerpc community steps up and starts fixing packages, we can always revert
<doko> so please can we first define: who are powerpc users?  who are powerpc porters (together with a track of work being done)?
<slangasek> doko: ok, if pointing out snapshot problems to the powerpc porters is itself burdensome, then what is the way that they can subscribe to be notified of the failures?
<doko> slangasek: watch ftbfs, excuses on a daily basis, fix issues
<slangasek> doko: that's something completely different from gcc-snapshot
<slangasek> which was what I was asking about
<infinity> "on a daily basis" is an unrealistic thing to ask anyone to do, even if it was their job.
<doko> slangasek: I don't see this as different. why single out one package?
<infinity> I suspect xnox doesn't check excuses for s390x issues every day either.
<slangasek> doko: I thought you were talking about test rebuilds using gcc-snapshot, not just build failures /of/ gcc-snapshot.  The latter doesn't seem like it's anything that should be blocking you, gcc-snapshot isn't exactly release-critical for Ubuntu
<doko> then do it twice a week, weekly is not enough. because then other developers will invest time to fix issues. and these are not powerpc porters
<mdeslaur> ok, I don't think we're going to decide on this issue today
<doko> slangasek: so to which porters should issues be reported?
<doko> we are trying to keep a port without knowing why we are doing it
<slangasek> I agree that there's an issue here, that a community port imposes a burden on the rest of the developer community that is ill-defined and not measured.  It's also difficult to fix it so that the burden does lie with those who feel ownership of the port
<slangasek> because we don't actually have subscription mechanisms for things like build failures on an arch
<doko> feeling ownership is not enough
<slangasek> of course it isn't
<slangasek> but I'm pointing out that there's a practical challenge to getting those who do feel ownership to shoulder the burden
<mdeslaur> well, we do need to see if anybody actually does feel ownership in the first place
<mdeslaur> I suspect not
<slangasek> infinity: do you?
<slangasek> AIUI there's difference of opinion on how much it's costing us to keep it, but general agreement that we should move towards deprecating 32-bit archs
<infinity> I do.  BenC does.  Not sure who else "feels ownership" and has the skills to do anything about it.
<doko> when was BenC's last upload to the archive?
<infinity> (There's a longer list of people who care about the port but probably can't fix hard issues, like flexiondotorg)
<infinity> doko: Probably somewhere around the time Canonical refused to accept money from his company. :P
<slangasek> infinity: is there a point of contact for the powerpc community?
<slangasek> up to now I've used ubuntu-server as a proxy on the grounds that ubuntu-server was the principal flavor being produced
<infinity> slangasek: Not really.  The two flavours that produce PPC images have users, and Ubuntu server does, but there's no ubuntu-ppc community where people hang out.
<slangasek> infinity: ok, I posit that if you feel ownership of the port and don't want us to drop it, that's something that needs fixed - there needs to be a clear escalation path to powerpc porters
<infinity> (Well, there's #ubuntu-powerpc, but that's pretty much Canonical and IBM and it's toolchain back-and-fort for both ppc* ports, not wider "community")
<slangasek> (email escalation path, not IRC :)
<doko> that is 64bit only
<infinity> doko: That's not true, even if you see it that way.
<doko> well, I'm asking there for help, and sometimes but not always get help
<slangasek> infinity: do you want to take the action to stand up an ubuntu-powerpc mailing list and notify relevant folks, so that we can see how this would work out in practice?
<infinity> slangasek: The latter before the former, I think, but yes.
<doko> so for now, I only see one powerpc porter, and one powerpc user (although that might be one company)
<infinity> slangasek: I'll round people up and see if there's a group to rally.
<slangasek> mdeslaur: ^^ action and gavel us out? :-)
<infinity> Very large gavel please.
<doko> slangasek: timeline for that?
<slangasek> I think we ought to make sure the list is in place in two weeks' time (i.e. before next TB meeting)
<mdeslaur> [ACTION] Infinity to gather up powerpc community before next TB meeting
<meetingology> ACTION: Infinity to gather up powerpc community before next TB meeting
<slangasek> trivial to do it as a launchpad list
<mdeslaur> [topic] Mailing list archive
<mdeslaur> none
<mdeslaur> [topic] Community bugs
<mdeslaur> none
<mdeslaur> [topic] Next chair
<slangasek> I believe I'm in the hot seat
<slangasek> stgraber as backup
<infinity> Looks like you then steffie, yes.
<slangasek> yes?
<mdeslaur> slangasek with stgraber as backup
<stgraber> sounds good
<mdeslaur> anybody have any other topics before I end this thing?
<mdeslaur> too late
<mdeslaur> #endmeeting
<meetingology> Meeting ended Tue Nov  8 18:15:19 2016 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-11-08-17.01.moin.txt
<slangasek> hahaha
<mdeslaur> go forth and watch disaster on tv
<infinity> Every meeting should end with "too late".
<mdeslaur> hehe
<infinity> And yes, I was mentioning earlier that this is the first time my TV will be used to watch broadcast TV.
<mdeslaur> I know, right? live tv, how retro.
<infinity> I've never watched the collapse of a nation live before.
<mdeslaur> thanks everyone
#ubuntu-meeting-2 2017-11-07
<infinity> o/
<mdeslaur> hi!
<infinity> Looking at the last month of history, I think kees might have forsaken us.
<infinity> (Though, looking at that month, it would seem I have too)
 * stgraber waves
<mdeslaur> heh, I was about to say the same thing :)
<mdeslaur> ok, looks like kees is MIA, so I'll do the meeting
<mdeslaur> #startmeeting
<meetingology> Meeting started Tue Nov  7 20:02:09 2017 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<mdeslaur> [topic] Apologies
<mdeslaur> nobody every apologizes anymore, snif!
<mdeslaur> [topic] Action review
<infinity> mdeslaur: I'm sorry.
<mdeslaur> heh
<mdeslaur> infinity: "ACTION: infinity to ask maas team to prepare SRU exception policy Ã  la CurtinUpdates"
<mdeslaur> what's the status on that?
<mdeslaur> and the other one: "ACTION: infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing (ETA: 16.04.3 release) "
<infinity> MaaS Exception: I've lost context on this and need to double back and see if this is in their court our mine (well, the SRU team's) at this point (ie: are they ready for review).
<infinity> support-status: This appears to be doing the right thing for 18.04.  If people concur that this is true, the same set of rules has been retroactively applied to 16.04 as well, but it requires a re-publish to take effect (which I still need to test on dogfood for potential gotchas)
<mdeslaur> infinity: I'll take a look and will let you know
<slangasek> https://wiki.ubuntu.com/MAASUpdates exists currently
<slangasek> fwiw
<slangasek> but is not linked/approved
<infinity> slangasek: Yeah, I know it exists, the last time I asked them about it, they said it was still a WIP.  Unless that was the second-last time I asked, and the last time they asked for a review, and I frogot about that. :P
<slangasek> k
<mdeslaur> slangasek: "ACTION: slangasek to investigate getting tagged ubuntu-community bugs automatically forwarded to technical-board, and if not feasible, fall back to DMB sending signed emails to list for ACL requests "
<slangasek> still on my todo, backburnered
<slangasek> currently the DMB has been sending emails, so I don't think this is blocking anything
<slangasek> (if someone disagrees I'll juggle priorities)
<mdeslaur> ok
<mdeslaur> looks like nothing else on the agenda this week
<mdeslaur> [topic] Mailing list archive
<mdeslaur> nothing new except for some spammy spam spam
<infinity> Spam!
<mdeslaur> [topic] Community bugs
<mdeslaur> no new bugs
<mdeslaur> [topic] Next chair
<mdeslaur> slangasek, with stgraber as backup
<slangasek> ok
<mdeslaur> [topic] AOB
<infinity> Letting kees off the hook? :P
<mdeslaur> I can write his name there forever, but if he never shows up...
<infinity> Well, AOB, someone should ping kees.
 * slangasek pencils in to chair the next TB meeting from kees's front lawn
<mdeslaur> hehe
<infinity> Oh right, someone lives very close to him.
<infinity> *someone*
<mdeslaur> I'll ask him what's up
<infinity> And hangs out with him occasionally.
<mdeslaur> Does anybody have anything else they would like to discuss?
<slangasek> (with a boom box?  who can predict)
<infinity> slangasek: Neither of your wives would appreciate the outcome of that.
<infinity> mdeslaur: I suspect we're done. :P
<slangasek> heh
<mdeslaur> #endmeeting
<meetingology> Meeting ended Tue Nov  7 20:10:18 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2017/ubuntu-meeting-2.2017-11-07-20.02.moin.txt
<mdeslaur> thanks everyone
<slangasek> thanks, folks
<mdeslaur> absentees forgo the cake
