=== zukeprime is now known as rayq === kickinz1 is now known as kickinz1|lunch [15:01] mumble seems unhappy [15:01] I was just going to say. [15:01] alas [15:01] * slangasek waves [15:01] works for me [15:01] * barry renames it grumble [15:01] yeah, it's working here [15:01] works here [15:01] bdmurray: rejects password [15:02] Yeah, reject for me too. [15:02] barry: here too [15:02] not working here, bad password it says [15:02] hmm [15:02] Oh, SSO is down. [15:02] yeah [15:02] oh? [15:02] i guess it only hates some of us [15:02] then it just went down [15:03] or some of us already had valid tokens? because I connected after barry said it wasn't working [15:03] slangasek: that could be [15:03] I guess if it's an SSO problem, other chat solutions are also out at the moment ;) [15:03] i'm connecting on a different box [15:04] well, first thing's first [15:04] #startmeeting [15:04] Meeting started Thu Sep 3 15:04:03 2015 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [15:04] Available commands: action commands idea info link nick [15:04] [TOPIC] Lightning round === meetingology changed the topic of #ubuntu-meeting to: Lightning round [15:04] $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx) [15:04] tdaitx doko infinity slangasek robru sil2100 caribou barry pitti bdmurray cyphermox [15:04] hurray! [15:04] Current [15:04] - Fixed FTBFS in bluez-tools (LP: #1489661, Debian #797128); forwarded fix upstream (accepted) [15:04] - Fixed FTBFS in bluez-tools (LP: #1490204, Debian #797356); fowarded fix upstream (accepted) [15:04] - Fixed FTBFS in opencsg (LP: #1490091); no debian backport, debian does not use opengles2 for qt4-x11 [15:04] - Fixed FTBFS in jruby (LP: #1490323) [15:04] - Fixed FTBFS in openscad (LP: #1489992) [15:04] - Updated libjoda-time-java from 2.7 to 2.8.2 (LP: #1491530, Debian #797842) [15:04] Launchpad bug 1489661 in bluez-tools (Ubuntu) "bluez-tools FTBFS on wily-proposed due to AM_LDFLAGS misuse" [Undecided,Fix released] https://launchpad.net/bugs/1489661 [15:04] - Investigating JRuby FTBFS due to failing spec tests (LP: #1491526); seems like many are due to build environment setup (eg. non-existing $HOME); local chroot has 2 failures and 2 errors, lp build has 21 failures and 13 errors [15:04] Debian bug 797128 in bluez-tools "bluez-tools FTBFS on wily-proposed due LDFLAGS misuse" [Important,Fixed] http://bugs.debian.org/797128 [15:04] - Investigating openscad FTBFS on armhf (LP: #1491553, Debian #797816); there are lots of failures in LP and Debian due to conflicting declaration between GL and ES2 (search for "khronos_ssize_t gl3.h"); any reason not to define "khronos_ssize_t" as "ptrdiff_t" instead of "signed long int"? [15:04] Launchpad bug 1490204 in bluez-tools (Ubuntu) "bluez-tools FTBFS on wily-proposed in 64-bit archs due to implicit pointer conversion" [Undecided,Fix released] https://launchpad.net/bugs/1490204 [15:04] - Setting up JCK 7 to run localy for trusty [15:04] Next week [15:05] Debian bug 797356 in bluez-tools "bluez-tools FTBFS in 64-bit archs due to implicit pointer conversion" [Important,Fixed] http://bugs.debian.org/797356 [15:05] - Guarantee that local JCK 7 tests are running fine for trusty, then move those to canonistack [15:05] Launchpad bug 1490091 in opencsg (Ubuntu) "opencsg 1.4.0-1 FTBFS on armhf" [Undecided,Fix released] https://launchpad.net/bugs/1490091 [15:05] - Additional tests for JDK6 TLS 1.1 and JDK7 TLS 1.2 backports, need to reproduce user report as I might have a regression in JDK 7 (LP: #1482924) [15:05] - Setup and use umt schroots, check if that setup is closer to [15:05] Waiting/On hold [15:05] Launchpad bug 1490323 in jruby (Ubuntu) "jruby FTBFS due to missing libjzlib-java dependency" [Undecided,Fix released] https://launchpad.net/bugs/1490323 [15:05] - Reviews by OpenJDK project of the TLS backports for JDK6 and JDK 7 still requires OCA clearance [15:05] (done) [15:05] Launchpad bug 1489992 in openscad (Debian) "openscad ftbfs in wily" [Unknown,New] https://launchpad.net/bugs/1489992 [15:05] Launchpad bug 1491530 in libjoda-time-java (Debian) "Update libjoda-time-java to 2.8.2 to fix timezone" [Unknown,New] https://launchpad.net/bugs/1491530 [15:05] Debian bug 797842 in libjoda-time-java "libjoda-time-java: Update libjoda-time-java to 2.8.2 to fix timezone" [Wishlist,Open] http://bugs.debian.org/797842 [15:05] Launchpad bug 1491526 in jruby (Ubuntu) "jruby FTBFS when running mspec tests" [Undecided,New] https://launchpad.net/bugs/1491526 [15:05] Launchpad bug 1491553 in openscad (Ubuntu) "openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h" [Undecided,New] https://launchpad.net/bugs/1491553 [15:05] Debian bug 797816 in openscad "openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h" [Important,Open] http://bugs.debian.org/797816 [15:05] Launchpad bug 1482924 in openjdk-7 (Ubuntu) "Regressions due to USN-2696-1" [Undecided,New] https://launchpad.net/bugs/1482924 [15:05] - GCC: build for POWER8, two backports for regressions on ARM32 and ppc64el, branch updates, package libstdc++fs.a [15:05] - openjdk-7 update [15:05] - gdal & friends transition [15:05] - boost1.58 transition, removed boost1.55, and old icu [15:05] - again, helped kubuntu with transitions. now all migrated [15:05] - cleared NBS [15:05] - almost cleared update_output.txt [15:05] - tracked down cyclicy dependencies in java packages (gradle, groovy2, stringtemplate4, one more) and asked for manual builds [15:05] - updated java related, which were behind in debian [15:05] - llvm-3.7 final, still ftbfs on i386 and powerpc [15:05] - some python3.5 related fixes [15:05] - integrated some pending openjdk-8 patches [15:05] (done) [15:05] [ Short week, due to illness ] [15:05] - Kernel SRU work [15:05] - NEW reviews [15:05] - General SRU/AA work [15:05] - Infrastructure work [15:05] - Discussions and planning for s390x bootstrap [15:05] - More glibc 2.22 work, expect upload Fri/Mon [15:06] (done) [15:06] * follow through on g++5 transitions, mostly reverting library name changes that Debian has opted not to take [15:06] * code review of ci-train code for new jenkins job security model [15:06] * ramping up for the s390x port [15:06] * working with dannf on getting edk2 buildable for arm64 with gcc5 [15:06] (done) [15:06] robru: [15:06] lp:cupstream2distro [15:06] - set PPA description to show silo configuration [15:06] - include tests in code coverage report, revealing some unused test helpers I've now deleted [15:06] - Define an 'install' target in the makefile which installs needed deps, so that they're no longer defined in 3 different places (s-jenkins -ci and -autolanding jobs, plus charm) [15:06] - Eliminate honor system allowing trainguards to spoof core devs during silo publication [15:06] - better error messages for some failure conditions [15:06] - workaround some lazr/lplib bugs [15:06] - instead of using bot name in debian/changelog, use request creator's name [15:06] lp:bileto [15:06] - add some new API endpoints to ease common use cases [15:06] - merge dashboard into requests page, dropping a ton of redundancy [15:06] - Unify 3 disparate dependency definitions into one central location in the Makefile in trunk. [15:06] - redirect to the newly created request when creating new requests, and dim the submit button when submitting, should alleviate users creating lots of duplicate records [15:06] - initial db migrations, adding some columns and changing some column types as necessary [15:06] - fix URL linkifier regex to not break when URL ends with punctuation [15:07] lp:canonical-mojo-specs [15:07] - new upgrade spec dramatically simplifying production rollout procedure [15:07] Mad Max game [15:07] - Cleared Chumbucket's territory [15:07] - cleared a decent area of Jeet's territory [15:07] (fin) [15:07] robru: was that last bit just to see if we're paying attention? :) [15:07] barry: ;-) [15:08] well, it did get my attention [15:08] sil2100 doesn't seem here [15:08] vacation [15:08] k then my turn [15:08] tdaitx: package builds shouldn't rely on $HOME being set fwiw; if something wants to write to $HOME during the build, create a scratch directory inside the package build tree and set the env var to point there [15:08] Bugfix: [15:09] - lucid -> precise -> trusty upgrade issue [15:09] * Unbootable system after upgrade (LP: #1491894) [15:09] Launchpad bug 1491894 in grub2 (Ubuntu) "lucid to precise to trusty upgrade may leave system unbootable" [Undecided,New] https://launchpad.net/bugs/1491894 [15:09] Merges: [15:09] - rsyslog merge : spent most of the time on merging 8.12 [15:09] then fixing FTBS. rsyslog 8.12.0-1 is now available [15:09] Investigate Core Dev application [15:09] ☑Done [15:09] py35 transition ongoing [15:09] dh-python syncpackage testing (pyqt5, mock, mako); [15:09] main+flavor ftbfs analysis (see ppa-status script); [15:09] sil2100 is on vacation yes [15:09] filing bugs, fixing bugs where possible, detailed ftbfs analysis (sometimes due to deps several levels deep), contacting upstreams, status reports. [15:09] python-pykmip w/o python3-enum34 (removed from archive). python-zeroconf 0.17.2-1. deja-dup 34.0-1ubuntu3 (succeeds in archive, fails in ppa due to libunity ftbfs). chatting w/zyga re: checkbox ftbfs. LP: #1491162. autopilot ftbfs (succeeds in archive, fails in ppa due to testtools). six 1.9.0-5. [15:09] Launchpad bug 1491162 in six (Ubuntu) "FTBFS in Wily" [Undecided,Invalid] https://launchpad.net/bugs/1491162 [15:09] will be sending detailed summary to ubuntu-devel later today [15:09] --done-- [15:10] pitti has a conflict this afternoon but sent me his status [15:10] apport: [15:10] slangasek, do you recall any package that does that? I would like to take a look and replicate it [15:10] - several bug fixes/optimizations requested by bdmurray (#1487174, #1485773, etc.) [15:10] - stop requiring apt lists to make origin check work with system-images (#1489410) [15:10] autopkgtest: [15:10] - Spent way too much time trying to find a non-hackish solution to detect and clean up leaked background processes which cause eternal hangs (hello deja-dup tests!) (#1488359) [15:10] - various bug fixes and stabilization from daily test watching [15:11] - enable britney/cloud testing for precise (mostly for kernel/dkms) [15:11] - Implement autopkgtest/worker/britney changes for running DKMS tests against multiple kernels [15:11] - Finish documentation: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure [15:11] systemd: [15:11] - resumed working on networkd integration, have if-up.d/if-post-down.d/ support working now (in review) [15:11] - package 225, various bug fixes [15:11] misc: [15:11] - fix various package test regressions to unblock stuff in -proposed [15:11] - clean up and generalize SRU policy for new LTS features, send proposals to TB [15:11] - big catch-up on bug triage [15:11] (done) [15:11] tdaitx: If a testsuite actually relies on $HOME in a way that's a pain to patch out, you can just mkdir foo && HOME=foo ./testsuite [15:11] tdaitx: tox used to but doesn't need to any more. you might find a solution in its older vcs history [15:11] tdaitx: But I generally view that as an upstream bug worth fixing. [15:11] tdaitx: not offhand no, but what infinity said [15:12] being sure to also remove foo/ in the clean target then [15:12] investigation into gtk+3.0 trusty crash rate increase and bucket not updating [15:12] found and resolved an issue with how crash reports that have previous failures to retrace are bucketed [15:12] wrote code to bucket unbucketed OOPSes [15:12] submitted RT regarding allocating retracers to the failed queues [15:12] modification of daisy-retracer charm to support retracing the failed queue [15:12] worked with webops to sort out status of retracer for the failed queue [15:12] review list of core files currently in swift so we can remove Utopic crashes [15:12] rebuilt test crashes for current package versions [15:12] uploaded fix for ubiquity package hook in apport to W [15:12] talked to pitti about LP: #1485787 and LP: #1485773 [15:12] Launchpad bug 1485787 in apport (Ubuntu Vivid) "package_hook does not include package version" [High,Fix committed] https://launchpad.net/bugs/1485787 [15:12] investigation into apport not adding origin information to foreign packages [15:12] Launchpad bug 1485787 in apport (Ubuntu Vivid) "duplicate for #1485773 package_hook does not include package version" [High,Fix committed] https://launchpad.net/bugs/1485787 [15:12] fixed an issue with the bug bot OOPSing when tagging ubiquity bugs [15:12] SRU review of python-neutronclient fixing a regression in V -updates [15:12] SRU verification of T, V fix for LP: #1485787 [15:12] review of patch for software-properties LP: #1381050 [15:12] Launchpad bug 1381050 in software-properties (Ubuntu) ""Import Key File" fails when the path of the file has special characters" [Medium,In progress] https://launchpad.net/bugs/1381050 [15:13] ✔ done [15:13] (mumble is back) [15:13] - debugging of NM autopkgtests [15:13] - sponsored/reviewed some ubiquity-slideshow MPs [15:13] - updated doxia [15:13] - sponsored golang, dh-golang [15:13] - working on ubiquity update, fixing new PEP8 errors [15:13] - skiboot (opal-prd) update and SRU [15:13] - fixing util-linux 'lscpu -p' bug on ppc64el (bug 1427995) [15:13] - debugging more parted/multipath issues: bug 1473903 [15:13] bug 1427995 in util-linux (Ubuntu Trusty) "lscpu -p is showing wrong values for Node component" [High,Fix committed] https://launchpad.net/bugs/1427995 [15:13] - testing ubiquity timezone map update for Pyonyang time [15:13] bug 1473903 in parted (Ubuntu) "parted will generate two devices when adding one partition on mpath device" [High,Triaged] https://launchpad.net/bugs/1473903 [15:13] - preparing rrdtool FFE for sync. [15:13] robru: personally, I'm still more partial to playing Minecraft in my free time, don't know about Mad MAx... [15:13] (done) [15:13] infinity, slangasek, barry thanks, I will check if the jruby folks can update their test [15:14] cyphermox: ;-) [15:15] any questions over status? [15:15] tdaitx: It's widely considered very poor practice in the free software world for a build to ever leave its build tree, so shouldn't be a hard sell upstream. [15:16] infinity, indeed, but right now I'm not sure if the mspec tests is something they own or just got from somewhere else [15:16] no questions from me [15:17] tdaitx: either way, worst case is they should be able to do the same HOME= trick upstream :) [15:17] [TOPIC] AOB === meetingology changed the topic of #ubuntu-meeting to: AOB [15:17] anything else today? [15:17] monday is a usa holiday [15:17] o yes [15:17] Monday is a holiday in Canada too [15:17] as surprizing as it may seem, it is *not* a holiday in France [15:18] wut? it is a holiday in Brazil as well [15:18] caribou: The French would have to work before it would make sense to observe Labour Day. [15:18] http://qa.ubuntuwire.com/ftbfs/ [15:19] infinity: they already celebrated it in May, be impressed that they're not taking it twice [15:19] at least in main, there is some stuff belonging to foundations ... [15:19] so, summer ends in may in france? [15:19] doko: I'll fix up curl today. [15:19] http://qa.ubuntuwire.com/ftbfs/#core specifically, I believe? [15:19] (not ftbfs, but you know what I mean) [15:19] curl isn't on this list ;p [15:19] doko: or is there something other than those that you wanted to draw attention to? [15:20] not yet! [15:20] :) [15:20] cyphermox: You mean the curl-udeb thing? [15:20] yeah [15:20] i'll look in to python-* [15:20] cyphermox: I think fixing maas is the right answer. [15:20] plus: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-ppc64el-20150902-wily.html (note these are not ppc64el only) [15:20] infinity: it is [15:20] cyphermox: Given that curl-udeb was empty before it was dropped, so they can't possibly have been using it. :P [15:20] oh, it was? [15:20] Yeah. That's why it was dropped. [15:20] It was clearly broken for several releases. [15:20] heh [15:20] With not a single person complaining. [15:20] Which is a fair sign no one was using it. [15:21] hahahaha dep-wait on pypy* [15:21] barry, look first at the pypy MIR, then these will clear up ;-P [15:21] dh-exec [15:21] infinity: it's not a very much used feature, it's mostly just enrolling maas devices via the ISO [15:21] rpm [15:21] I'll ask harder if we can just drop that altogether... [15:21] sssd? [15:21] cyphermox: Oh, the "enlist in MaaS" bootloader option on the server CD? [15:22] libpod-readme-perl [15:22] cyphermox: If that actually relied on curl-udeb, they haven't tested it in years... [15:22] infinity: well, it's maas-enlist-udeb that requires curl-udeb [15:22] doko: heh, rpm shows up as part of the ubuntu-desktop package set, not core [15:22] doko: sssd is RAOF's. [15:22] the only thing I could think of to use that was the enlist in MAAS option from the CD [15:22] and a lot of perl stuff here: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [15:23] cyphermox: Your logic is sound, but they supposedly test that feature. So, could need more investigating. [15:23] easy enough to test anyway [15:23] Oh look, another java/maven explosion. [15:23] Why, java, why? [15:24] doko: The majority of those perl modules can probably get hand-waved in with a minimal review and subscriber, but I guess we should file a big bug and go through the motions. [15:24] tdaitx, robru: http://qa.ubuntuwire.com/ftbfs/#core should be driven to zero for release, can you take a look at these and see which ones you can help with? (feel free to ask any of the core-devs if you have questions) [15:25] slangasek: sure [15:25] slangasek, sure [15:26] infinity, likely, but maybe check as well if they are maintained by the perl team [15:26] infinity: http://paste.ubuntu.com/12263705/ don't think they were testing it, otherwise it magically worked without that for some reason [15:26] doko: Yeah. Most probably are, they have most of CPAN packaged. :P [15:26] (that's from debian-cd) [15:26] java is known, and ruby is known too, wanted somebody to look at rails; how we can avoid it [15:27] cyphermox: Well, it may well be that maas-enlist-udeb doesn't actually need curl-udeb. [15:27] I'll pick up the firefox FTBFS, I'm sick of arguing with people about it. [15:29] * pitti rentre -- qu'est-ce que j'ai perdu ? :-) [15:30] pitti: un peu de ceci, un peu de c'là [15:30] in 250 [15:30] pitti: we're just about wrapped here, can you join mumble? [15:30] ... [15:30] I'm in [15:34] I think we're done here then [15:34] unless there's anything else [15:35] #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 [15:35] Meeting ended Thu Sep 3 15:35:54 2015 UTC. [15:35] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-09-03-15.04.moin.txt [17:00] hello hello [17:00] Aloha [17:00] welcome to this weeks CC [17:00] feels like a bit of a game show! [17:00] #startmeeting [17:00] Meeting started Thu Sep 3 17:00:47 2015 UTC. The chair is dholbach. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [17:00] Available commands: action commands idea info link nick [17:00] #chair czajkowski mhall119 pleia2 [17:00] Current chairs: czajkowski dholbach mhall119 pleia2 [17:00] o/ [17:01] Do we have folks from the IRC Council and Canonical Community team here? [17:01] #link https://wiki.ubuntu.com/CommunityCouncilAgenda [17:02] ^^ agenda [17:02] o/ [17:03] I don't think anyone sent a reminder to the IRC Council [17:03] ok, let's start with the community team then and I'll try to ping the IRC Council folks [17:04] pleia2: a reminder was sent [17:04] hggdh: oh good :) [17:04] dholbach: balloons mhall119 so life on the community team [17:04] is dpm around [17:04] thanks hggdh! [17:05] btw, hi all, long time and all that [17:05] hggdh: welcome :) [17:05] o/ [17:05] popey: howdy [17:05] #topic Catching up with the Canonical Community team === meetingology changed the topic of #ubuntu-meeting to: Catching up with the Canonical Community team [17:05] I have some opinions :) [17:06] so, there's some things I wanted to bring up, but they are mostly based on popey's thoughts. I'll let him speak first if he wishes [17:06] nah, knock yourself out [17:06] balloons: do tell, but please don't injure you're self [17:06] :) [17:06] haha [17:07] :-) Ok, my first thought was bringing up how we deal with contributions. It's the second half of the lifecycle for contributing. We spend time and effort encouraging folks to contribute, but once they do, we sometimes falter [17:08] * dholbach has opinions on that subject too :) [17:08] There are both good examples and bad examples of this. For instance, we do wonderfully on the core apps projects, while we have patches sitting waiting in other places [17:09] yeah... I just raised the subject with the engineering managers for Ubuntu again - sponsoring and patch review for stuff going into the distro sort of went a bit on the backburner for many and patches had been piling up again [17:09] I would be curious how we might be able to close this gap a bit better. Is there something collectively we could do and/or encourage the community to do to insure we are good stewards of people's contributions? [17:09] yeah [17:10] I haven't checked other queues (NEW, SRU, +1 maintenance, MIR, etc.), but I can imagine that these might require more attention too [17:10] I had a ranty email from a community contributor recently who was annoyed that his merge proposals took a long time to be reviewed [17:10] me too [17:10] is it something we can empower the community collectively to do? AKA, are there not enough people to review the work? [17:10] popey: how long was long? [17:11] could be days to weeks [17:11] and is there way we can get more eyeballs on stuff in a more fun way to do it, as I know folks are busy but it's also a necessity [17:11] One issue is many canonical people work closely on irc, and are happy to ping eachother [17:11] the patch pilot programme was supposed to guarantee that everyone within the distro team with upload rights had 4h/month (or one hour per week) to help out [17:11] Joe: "Hey, bob, can you review that merge on your project?" [17:11] Bob: "Sure, I'll get to it in a bit" [17:11] job done [17:11] o/ [17:11] community person contributes and it looks like it disappears into a black hole [17:12] I am guilty of this too, not pointing fingers at others. [17:12] I hope that we can get more energy into this again [17:12] * dpm and mhall119 I were having a really interesting call with the Mycroft folks [17:12] popey: aye I think at times the IRC ping often doesnt help folks not on irc [17:12] who may be working [17:12] and some of the engineering managers are discussing the subject right now [17:12] and taking things to a public mailing list to show how easy it is to get feedback ina constructive manner [17:13] czajkowski: indeed, and not knowing that people are approachable [17:13] czajkowski: and some people actually _not_ being approachable [17:13] popey: exactly [17:13] yeah, you can't say on a wiki page "ping popey to get your patch reviewed and included" :) [17:13] nail on the head :) [17:13] (e.g. berating someone for pinging them which disturbs them, contributors should ask in public so as not to disturb individuals) [17:13] that's why we had current patch pilots in the topic in #u-devel [17:13] exactly! [17:14] It may be better to encoureage people when they see people being pinged on irc, to suggest can we move this to the ML so others can see how it's done [17:15] popey: balloons dholbach which ml would this go to ? [17:15] a request for a review of a patch? [17:15] devel- devel-discuss, elsewhere? [17:15] dholbach: aye [17:15] both should work [17:15] not sure [17:15] I hope that with support from management we can at least have Canonical engineers help out more regularly again [17:16] could we try for the next few weeks to push to -devel-discuss - I know moderation can be an issue ? [17:16] I'd leave the mailing list as last resort for the urgent cases [17:16] yeah [17:16] we shouldn't ask people to mail the mailing list for everything [17:16] irc is way easier / faster [17:16] but we shouldn't have to go round poking people [17:16] I would also like to think about a way to monitor this and be proactive on our end a bit. Especially since things are backlogged now [17:17] people who are upstream for a project should act like one [17:17] popey: hmm but what about the people who want to contribute that aren't on IRC [17:17] I would rather see us gently nudging upstreams to be more receptive. An MP should be enough to get the contact going [17:17] http://reqorts.qa.ubuntu.com/reports/1glance-sponsoring/ [17:17] if you click on "year" [17:18] you can see that the last call for help seems to have done something [17:18] yea, you can see when you issue the calls :-) [17:18] czajkowski: why arent they on irc? everyone is on irc. [17:18] popey: that whole work thing :) [17:18] dholbach: nods [17:19] popey, there are upstream developers and debian folks and others who just want to do a drive by contribiution [17:19] * hggdh respectully disagrees from popey [17:19] it was somewhat tongue in cheek [17:19] * hggdh removes disagreement [17:19] dholbach: i agree, and we should pick those up and not let them languish [17:19] yep, agreed [17:19] ok [17:19] so you mentioned other issues? [17:19] what are they ? [17:20] maybe we can review in a couple of weeks again and see if the recent discussions helped change something [17:20] balloons, popey: was your point mostly just about sponsoring? [17:20] mine wasnt [17:20] ok, then I'll get out of the way now :) [17:20] mine was a cultural change, more of an observation [17:20] I think it's about MPs and upstreams too [17:21] popey: do tell [17:21] Are we done with the other topic though? [17:21] my point was about us collectively encouraging a better culture in our upstreams as well. But the boots on the ground work from dholbach is part of it [17:21] balloons: cool can we try encouraging more people to review over the next few weeks [17:21] I wonder if most developers in an upstream project are signed up for mails about new MPs... [17:22] see if it makes a difference and if not lets come back and see if we need to take to ML or what we need to do [17:22] yes, and given the changes to LP, we should encourage people to review filtering. I'm guiltly of this. I filtered out those mails [17:22] because it was hard to get the right mix without getting overwhelemd [17:23] the lp team just redid this (I for instance often miss important mails, like renewing in a team) [17:23] maybe it'd be good to write up best-practices "how to be a good upstream" with a few paragraphs on "how to set up your project in LP"? [17:23] yeah, me too [17:23] my gmail has thousands of mails, this is why i rely on web pages with lists of things to do [17:23] +1, dholbach. That's the action I'd like to see, and I think we could do [17:23] rather than email [17:24] dholbach: brilliant idea [17:24] I'm not sure if that'd solve all problems - you still need to do your reviews [17:24] dholbach: I see a to do AI for you then :) [17:24] but it could be a first good step [17:24] czajkowski, erm....... I'm convinced :) [17:25] but yeah, I can have a look around and see what the current LP docs offer [17:25] and bring that up for renewed discussion [17:25] nods [17:25] happy to do that [17:25] lovely jubbly thanks [17:25] popey: so back over to you. [17:25] okay [17:26] this is an observation about our team, and not an opinion or conclusion [17:26] Since jono left things have been a bit different. [17:26] So when things went "wrong" outside canonical jono would typically swoop in wearing a cape and write a blog post [17:26]