== Meeting information ==
 * #ubuntu-meeting: DMB, 17 Aug at 19:15 — 20:24 UTC
 * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-08-17-19.15.log.html]]



== Meeting summary ==

=== previous actions ===
The discussion about "previous actions" started at 19:16.


=== Core Developer Application Łukasz Zemczak sil2100 ===
The discussion about "Core Developer Application Łukasz Zemczak sil2100" started at 19:18.

  * ''LINK:'' https://wiki.ubuntu.com/LukaszZemczak/CoreDeveloperApplication 
  * ''LINK:'' http://people.canonical.com/~ubuntu-archive/component-mismatches.txt <- there's this place here, but there's also e-mails sent on each new one
  * ''LINK:'' http://people.canonical.com/~ubuntu-archive/nbs.html 
  * ''Vote:'' sil2100 for Core Dev application (Denied)
  * ''ACTION:'' xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100

=== AOB ===
The discussion about "AOB" started at 20:20.




== Vote results ==

 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-08-17-19.15.log.html#153 sil2100 for Core Dev application]]
  * Motion denied (For/Against/Abstained 0/1/3)
   *  Voters bdmurray, xnox, micahg_work, cyphermox



== Action items, by person ==

 * sil2100
  * xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100
 * xnox
  * xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100



== Done items ==

 * (none)



== People present (lines said) ==

 * xnox (79)
 * sil2100 (62)
 * meetingology (13)
 * cyphermox (12)
 * micahg_work (8)
 * bdmurray (6)
 * ubottu (2)
 * DalekSec (1)



== Full Log ==


 19:15 <xnox> #startmeeting DMB

 19:15 <meetingology> Meeting started Mon Aug 17 19:15:35 2015 UTC.  The chair is xnox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.

 19:15 <meetingology> 

 19:15 <meetingology> Available commands: action commands idea info link nick

 19:15 <xnox> !dmb-ping

 19:15 <ubottu> cyphermox, infinity, Laney, micahg, xnox, bdmurray, stgraber: DMB ping

 19:15 <xnox> roll-call bdmurray cyphermox xnox micahg_work are present

 19:16 <xnox> #topic previous actions

 19:16 <xnox> bdmurray: micahg_work: there are previous actions on the agenda

 19:16 <xnox> all done, or not so much?

 19:17 <micahg_work> not so much :(

 19:17 * xnox doesn't see Unit193 around

 19:17 <micahg_work> mozc was in the packageset

 19:17 <xnox> ack.

 19:17 <bdmurray> I setup a bzr branch although its not clear if that is sufficient or not.

 19:17 <xnox> ok.

 19:17 <xnox> i don't see Unit193

 19:17 <xnox> so i guess, move to sil2100 application

 19:17 <bdmurray> I believe micahg_work pinged Unit193

 19:18 <xnox> well, we can keep that item on the agenda for the time being, i guess.

 19:18 <xnox> #topic Core Developer Application Łukasz Zemczak sil2100

 19:18 <xnox> sil2100: hola! please introduce yourself and your application =)

 19:19 <sil2100> Hello dear DMB!

 19:19 <xnox> https://wiki.ubuntu.com/LukaszZemczak/CoreDeveloperApplication

 19:19 <sil2100> My name is Łukasz Zemczak, I'm a MOTU that would like to advance to a CoreDev

 19:20 <xnox> And i see you have been motu for over a year now.

 19:20 <sil2100> Most of the time I'm dealing with touch packages, operating the CI Train, managing the touch seeds, managing image builds and channels, acting as one of the release managers of the touch stack

 19:20 <sil2100> I also have some experience with non-touch through patch pilot sessions

 19:20 <sil2100> I do them rarely, but I try to spend at least a few hours every now and then

 19:21 <sil2100> In the past it was more frequent, but after we got the few official ubuntu touch phones on the market I didn't have as much free cycles

 19:22 <sil2100> Becoming a CoreDev will also help me in my patch pilot duties, as there's more main packages on the sponsoring queue than universe usually ;)

 19:23 <xnox> sil2100: ok. looking at your set of packages you work on, e.g. uploaded / synchronised list, they seem to be mostly universe things.

 19:23 <xnox> sil2100: which main packages did you modify to date, and proud off, that got sponsored into ubuntu?

 19:24 <sil2100> hmm, that's a hard one, my memory is not so good, would have to think about that for a bit

 19:24 * xnox looks through your history.

 19:24 <sil2100> There weren't so many of those, I usually tried working in the fields where I can do the most, so universe - I helped out in some main transitions, but nothing that super specific

 19:26 <sil2100> There were a few during the libav11 transiiton too... there was also the upower transtion we did, but not sure if that counts as it was in the infameous ubuntu-rtm distro

 19:27 <xnox> ok, from renet there is https://launchpad.net/ubuntu/+source/thumbnailer/1.2+14.10.20140901.is.1.2+14.10.20140814-0ubuntu1 in main

 19:27 <xnox> it FTBFS across the board

 19:27 <xnox> click in utopic built https://launchpad.net/ubuntu/+source/click/0.4.31.2.is.0.4.30

 19:27 <xnox> revert https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.4+14.10.20140820.is.0.5.3+14.10.20140806-0ubuntu1

 19:27 <xnox> in universe

 19:28 <sil2100> Yeah, the reverts are automatic creations from the CI Train tool

 19:28 <xnox> sil2100: patch piloting can be done without upload rights -> cause most of things in the queue need review, comments, test building and +1. That would make it easier for those with upload rights, to quickly upload those things.

 19:28 <sil2100> All those funny ones with versioning of version.is.version - I don't remember what happened with that one, but it was probably one attempt in a crisis and trying to revert a really broken package

 19:29 <cyphermox> there's some older stuff in -changes emails I can see as qtbase-opensource-src/5.0.2+dfsg1-7ubuntu18

 19:29 <sil2100> xnox: yes, I know as other MOTUs do that as well, but I always thought that I'll be of more use if I decrease the queue itself by doing uploads

 19:30 <sil2100> If there were no urgent universe packages in the queue, I was moving to main ones, but that wasn't too frequent from my side

 19:30 <cyphermox> sil2100: so, how would you say the CI Train work of reviewing others' package prepare you for having permission to upload any package in the Ubuntu archive?

 19:31 <cyphermox> I think since this is a particularly unusual situation in where you don't necessarily get to upload many things yourself because it goes through CI Train, but you do see a whole lot of stuff and people go to you for help

 19:31 <xnox> sil2100: from what i can see, there aren't many things in main that you have been working on. and most of your work is based on reviews & landing other peoples code. I wouldn't feel confident granting main upload rights for all packages, without much evidence of working on main packages.

 19:31 <cyphermox> I'm not sure what precedent we may or may not want to make, but I think it probably warrants discussion.

 19:31 <sil2100> It gives me an overall idea of possible packaging issues and problems that inexperienced developers were having

 19:32 <sil2100> We're using the CI Train for main packages most of the time, so most of the main uploads I do I drive them through the CI Train

 19:32 <xnox> sil2100: can you list some reasons for a package to FTBFS?

 19:32 <sil2100> Every main upload needs to be ACKed by a core-dev, but before that happens I have to do a review of it

 19:33 <bdmurray> Do you have examples of those reviews?

 19:33 <cyphermox> sil2100: would you have examples of things that went particularly *not* well through the CI Train that you caught too late, or whatnot, that could have been handled differently?

 19:33 <cyphermox> (or examples of outstanding work via...)

 19:33 <sil2100> One of the most common reasons for a FTBFS of a new package is the lack of build-dependencies or invalid versions of such - another can be a change in the toolchain, or even an unnoticed ABI break in one of the dependent packages

 19:34 <sil2100> Usually the last one is caught by symbol files in our packages

 19:35 <xnox> sil2100: why did this package FTBFS? https://launchpadlibrarian.net/214593878/buildlog_ubuntu-wily-amd64.gunicorn_19.0-6ubuntu1_BUILDING.txt.gz

 19:36 <sil2100> sbuild-build-depends-gunicorn-dummy : Depends: tox but it is not installable <- from the first look it seems that there's a dependency problem

 19:36 <sil2100> But I would need to check what sbuild-build-depends-gunicorn-dummy is and what's the tux dep it has, and why it's not installable

 19:36 <xnox> sil2100: what is sbuild-build-depends-gunicorn-dummy?

 19:37 <xnox> sil2100: by the way, tox is installble in wily.

 19:37 <sil2100> Sometimes when it's not super obvious on first glance, I run a chroot for the given system and try to install the build deps as the build machine does

 19:37 <sil2100> Let me check

 19:37 <xnox> i can do that, just did, tox is intallable.

 19:38 <xnox> why would a tox be installable locally in a chroot, but wouldn't be installable in launchpad during a particular package build?

 19:38 <xnox> by the way, which package is being built now?

 19:38 <xnox> (now, as in, in the above changelog)

 19:38 <sil2100> dpkg-deb: building package 'sbuild-build-depends-gunicorn-dummy'

 19:38 <sil2100> And a package can be uninstallable with other packages, for instance

 19:39 <sil2100> Because of a conflict

 19:39 <xnox> true, but there is no conflict here, and apt would say about it.

 19:39 <xnox> by the way package 'sbuild-build-depends-gunicorn-dummy' -> is not the one being built here.

 19:40 <sil2100> The build log is in overall from the gunicorn

 19:40 <sil2100> package

 19:40 <xnox> ok.

 19:40 <xnox> correct.

 19:40 <sil2100> Checking the source if you don't mind

 19:41 <xnox> yeah, you can look at anything =)

 19:41 <xnox> and the build fails at: Install gunicorn build dependencies (apt-based resolver), stage of sbuild

 19:41 <xnox> with failing to install tox.

 19:42 <xnox> btw. sbuild-build-depends-gunicorn-dummy is what it says on the tin, a dummy package sbuild generates to install build dependencies of gunicorn. Kind of a hack, because one cannot do apt-get build-dep against an unpacked source package =(, `apt-get build-dep` only works against packages that are already built and published in the archive.

 19:43 <xnox> sil2100: which component of the archive is gunicorn in?

 19:44 <sil2100> Ok, this is something I did not know, ugh

 19:44 <sil2100> It's a main component

 19:44 <xnox> sil2100: ok. and which component is tox in?

 19:45 <sil2100> Ah, universe! A main-mismatch!

 19:45 <xnox> sil2100: how do i check components of packages from command line?

 19:46 <sil2100> Interesting though, as usually in the past builds didn't fail because of that, I remember we had multiple cases where people had main packages depping on universe and we only caught it right before publishing

 19:46 <sil2100> BUt that's probably because we built everything in PPAs

 19:46 <sil2100> And those don't have the checkbox for checking this checked by default

 19:46 <sil2100> xnox: I usually use rmadison for this

 19:46 <sil2100> Although it tends to be slow nowadays

 19:47 <xnox> sil2100: ok.

 19:48 <xnox> sil2100: where would you check all "main-mismatch" in the archive?

 19:49 <sil2100> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt <- there's this place here, but there's also e-mails sent on each new one

 19:50 <xnox> sil2100: ok. and you know about graphical output for them as well, there is .svg about it

 19:50 <xnox> sil2100: and there is also a separate one generated for -proposed

 19:50 <sil2100> Yeah, all in the http://people.canonical.com/~ubuntu-archive place

 19:51 <xnox> sil2100: i would recomend to check those out, and see if you can prepare uploads to resolve those, and or file MIR.

 19:51 <xnox> sil2100: have you filed MIR before?

 19:51 <micahg_work> is there a tool that you can use to see if all of the dependencies for a package are in main/restricted?

 19:51 <sil2100> xnox: yes, a few ones I remember, most for touch packages of course...

 19:52 <sil2100> micahg_work: check-mir :)

 19:52 <xnox> ok. good.

 19:52 <micahg_work> yep!

 19:52 <xnox> sil2100: what is NBS? how to resolve them?

 19:52 <sil2100> didrocks whipped me in the past for not using it

 19:53 <sil2100> I remember that being Not Buildable from Source, but I need to think what it was about

 19:53 <sil2100> *built

 19:53 <xnox> good

 19:53 <sil2100> I don't think I resolved any of those before though...

 19:54 <xnox> http://people.canonical.com/~ubuntu-archive/nbs.html

 19:54 <cyphermox> sil2100: did you help out with the gcc5 transition?

 19:54 <sil2100> cyphermox: not too much... I was doing some work uploading/merging changes from the transition itself and helped out developers with packaging questions

 19:55 <sil2100> But not as much as I would like

 19:55 <cyphermox> it's fine, I'm just trying to figure things out

 19:56 <sil2100> xnox: I suppose NBSes might be cases when certain packages depend on some binary packages that are no longer provided by source packages?

 19:56 <sil2100> (a bit guessing here)

 19:56 <xnox> sil2100: correct.

 19:56 <sil2100> In that case I suppose those can be resolved by either adding transitional packages or, if a package got renamed, maybe adding a Provides and making those virtual?

 19:57 <sil2100> (or for the case the same functionality is provided by a different package now)

 19:57 <xnox> sil2100: no. usually what needs to be done, is those dependand package need to be rebuild to depend on new package names, and/or drop the dependencies.

 19:58 <sil2100> Oh, yeah, the easy way, I think I went overboard with that idea

 19:58 <DalekSec> xnox: Sorry I didn't get the pint (I'm Unit193)

 19:58 <xnox> sil2100: e.g. maas-enlist-udeb needs to be rebuild to start depending on e.g. libcurl3-udeb.

 19:58 <xnox> sil2100: my expectation from a core developer, to know about at least one thing at a proficient level: sbuild logs, components mismatches, NBS.

 19:59 <xnox> sil2100: none of those things are typically encountered by universe / motu, developers as these things are either exclusive or have higher priority in main.

 20:00 <sil2100> Maybe I could gain some points by my experience with dealin with -proposed migration update_excuses and update_output ;p?

 20:00 <sil2100> *dealing

 20:00 <xnox> sil2100: i would expect you to work on resolving NBS, filing/follwing up on MIR reports, and/or resolving components-missmatches by e.g. moving optional build-dependencies for test-suites only into adt tests.

 20:01 <sil2100> I never resolved NBS as is, but I did similar work during the few transitions I was doing, as there were always a lot of rdeps to rebuild and change dependencies

 20:02 <xnox> sil2100: yes, ultimately. things like nbs/components-missmatches end up entangling and keeping packages stuck in proposed migration.

 20:02 <xnox> sil2100: and fixing proposed migration, especially during current gcc5 transition was what most core devs have been working on past few weeks.

 20:03 <xnox> sil2100: i really think you should do get experience with those tools and reports, before i would vote +1 on your application.

 20:03 <sil2100> Ok, I understand...

 20:04 <xnox> do other people have more questions, or can we vote on the application?

 20:05 <sil2100> I know it's bad I'm rather concentrated on touch packages

 20:05 <xnox> !dmb-ping

 20:05 <ubottu> cyphermox, infinity, Laney, micahg, xnox, bdmurray, stgraber: DMB ping

 20:05 <xnox> are we ready to vote?

 20:06 <sil2100> I did try to help out with some transitions for experience though, and also I got some experience with resolving packages being blocked in -proposed

 20:08 * bdmurray is still here

 20:08 <xnox> sil2100: do more of that. keep notes, get those uploads sponsored and keep a list. If you can demostrate that to us, for example i would be in favor voting +1 on your application very soon (e.g. within 1-3 months, as you have enough things to demonstrate)

 20:09 <xnox> sil2100: i am confident in the rest of your skills and general programming. it's the coredev specific things, that i see you as lacking deep experience in.

 20:09 <sil2100> Ok :)

 20:09 <sil2100> Thanks

 20:11 <xnox> but today will be a -1 from me.

 20:14 <xnox> #vote sil2100 for Core Dev application

 20:14 <meetingology> Please vote on: sil2100 for Core Dev application

 20:14 <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)

 20:14 <xnox> !dmb-ping

 20:14 <xnox> -1

 20:14 <meetingology> -1 received from xnox

 20:16 <micahg_work> +0

 20:16 <meetingology> +0 received from micahg_work

 20:16 <bdmurray> +0

 20:16 <meetingology> +0 received from bdmurray

 20:16 <cyphermox> sorry

 20:16 <cyphermox> +0

 20:16 <meetingology> +0 received from cyphermox

 20:16 <bdmurray> I'd like to echo what xnox said though.

 20:16 <micahg_work> me too

 20:17 <sil2100> Ok... thanks

 20:18 <xnox> #endvote

 20:18 <meetingology> Voting ended on: sil2100 for Core Dev application

 20:18 <meetingology> Votes for:0 Votes against:1 Abstentions:3

 20:18 <meetingology> Motion denied

 20:18 <xnox> sil2100: please follow advice above, and we hope to see you reapply soon!

 20:19 <xnox> #action xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100

 20:19 * meetingology xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100

 20:19 <sil2100> Will do

 20:20 <xnox> since inception of core-dev a lot of things have changed, and it's good to have that documented.

 20:20 <xnox> #topic AOB

 20:22 <cyphermox> micahg_work: did N o s k c a j get his feedback after all?

 20:23 <micahg_work> no :(

 20:23 <micahg_work> but I did chat with him a little and let him know that we haven't forgotten

 20:24 <cyphermox> ok

 20:24 <xnox> #endmeeting



Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)