15:26 <bdmurray> #startmeeting Ubuntu DMB
15:26 <meetingology> Meeting started Mon Apr  7 15:26:47 2014 UTC.  The chair is bdmurray. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:26 <meetingology> 
15:26 <meetingology> Available commands: action commands idea info link nick
15:26 <bdmurray> #topic Ubuntu Core dev application: Adam Stokes
15:27 <xnox> From service manpage restart is stop, start =))))))))) </joke>
15:27 <stokachu> hi, thanks guys for restarting for me
15:27 <bdmurray> stokachu: Could you introduce yourself, your work, and your application?
15:28 <stokachu> Hi, I've been working for Canonical doing a Sustaining Engineering role and recently moving into Solutions Engineer concentrating on juju, maas, and our most recent project cloud installer
15:28 <stokachu> one sec lemme get the app link
15:29 <stokachu> https://wiki.ubuntu.com/AdamStokes/CoreDevApplication
15:29 <ScottK> For those of us that don't work at Canonical, sustaining/solutions engineering doesn't mean much.
15:29 <stokachu> as stated in the application ive been using Ubuntu for roughly 3 years and Fedora prior to that for 7 years
15:29 <stokachu> Susstaining engineering revolved around maintaining the quality and stability of the existing product lines
15:30 <stokachu> inlucding Base OS, Kernel maintenance, and Cloud technologies such as Juju
15:30 <xnox> stokachu: mostly on LTS releases only?
15:30 <stokachu> Sustaining rarely did new feature enhancements or new package appication
15:30 <stokachu> Yea our main focus was LTS releases
15:30 <stokachu> however when we sent a patch we did it for all supported Relesaes
15:30 <stokachu> releases*
15:31 <stokachu> In solutions engineering we are kind of a R&D department
15:31 <stokachu> where we work on upstream enhancements with focus in maas, juju, and hpc
15:32 <ScottK> Usually, people apply for MOTU, before core-dev.  How it's somewhat unusual to see someone going for core-dev as their first entry point into ubuntu-dev.
15:32 <stokachu> as for outside of the canonical realm i've successfully submitted the package sosreport in the Debian archive via the mentors program
15:32 <stokachu> which was handled from scratch until upload
15:32 <stokachu> I am currently a Ubuntu contributing developer
15:33 <stokachu> ScottK: ^
15:33 <stokachu> when time permits ive done package merges from debian into X ubuntu release
15:33 <stokachu> participated in +1 maintenance
15:34 <ScottK> Right, but that's not part of ubuntu-dev (that's people with upload rights)
15:34 <Laney> What do you imagine you'll be mainly working on in the Ubuntu archive?
15:34 <xnox> ScottK: however, I went straight from contributing developer -> core dev. So there have been cases like that before. Also looking at stokachu's upload history most of the uploads that got sponsored for him are for "main" packages.
15:34 <stokachu> My main focus will be our cloud products such as Maas, Juju, and Cloud installer
15:34 * Laney doesn't think going straight for core-dev is a problem in itself if there's experience and that's where the interests/intention to contribute is
15:34 <stokachu> curtin
15:35 <stokachu> Where main package contributions come into play will be against those that are depending on by the stated cloud products
15:35 <stokachu> dhcp, bind, etc
15:35 <ScottK> xnox: I know it's happened, it's just not usual.
15:36 <stokachu> ive worked with xnox and bdmurray on a few occasions related to packaging and userspace maintenance work
15:36 <bdmurray> stokachu: with your change in teams and responsibilities has your focus shifted from SRUs to the development release?
15:37 <stokachu> bdmurray: yea my focus won't be SRU at this time
15:37 <stokachu> primarily due to team sizes/resources etc
15:37 <stokachu> CTS would still handle the SRU's for products i will directly work on
15:37 <ScottK> CTS?
15:37 <stokachu> canonical technical services
15:38 <stokachu> the department where Sustaining Engineering resides
15:38 <stokachu> ScottK: sorry i dont intentially mean to automatically assume everyone knows canonical
15:38 <ScottK> Let's try and make it through the rest of the meeting without any references to the Canonical org chart.
15:39 <stokachu> sure
15:39 <ScottK> What do you think of the process for landing maas/juju development efforts into Ubuntu?
15:40 <stokachu> They aren't in line with the rest of development processes
15:40 <bdmurray> stokachu: your application seems to be missing the "Things I could do better" section.  Is that deliberate?
15:40 <stokachu> As in feature freezes tend to not apply to them, however, I feel they should
15:40 <stokachu> bdmurray: there is a one liner which states Increase my productivity by stream lining my work items for the different projects I am involved in.
15:41 <stokachu> and by increasing productivity I mean adhearing to the processes defined by Ubuntu
15:41 <ScottK> stokachu: Feature freeze does apply.  They just ignore it and ask for an FFe every time.
15:41 <stokachu> reduce back and forth
15:41 <xnox> stokachu: MAAS & juju testing is loosely integrated with ubuntu release cycle. Past three releases co-incided with Openstack summits and there was nobody available (and had hardware) to execute end-to-end MAAS testing, and it hasn't been tested regularly during the development cycle. In your opinion, how can this be improved?
15:41 <xnox> (thus critical bugs were discovered more-or-less during release weeks)
15:41 <stokachu> xnox: So CI is definitely a big issue in my eyes
15:42 <stokachu> we shouldnt be releasing products that do not 100% pass tests and have a huge percentage of coverage
15:42 <ScottK> Having a release schedule that's aligned to Ubuntu's would help.
15:42 <stokachu> For juju in particular it would be beneficial to stick to not making breaking changes in minor releases
15:42 <stokachu> Also maas release 1.5 which is way to close to the 14.04 release
15:43 <stokachu> to be audited and signed off on
15:43 <stokachu> released*
15:43 <stokachu> Making sure codebases are green before doing releases is a pet peeve of mine
15:44 <stokachu> But, maas and juju teams do realize the pitfalls
15:44 <stokachu> and are actively changing their processes and increasing testing
15:45 <stokachu> They are in the right direction so I strongly believe those aligned processes with Ubuntu will be seen in the near future
15:45 <xnox> stokachu: ok. Slightly different question: What should one do when updating a library, that removes one function from its ABI?
15:46 <stokachu> xnox: ifa function is removed the symbol tables would need to be updated to reflect that
15:47 <stokachu> among a version bump and possible rebuilds of affected packages
15:48 * bdrung_work arrives
15:48 <xnox> stokachu: how would you find out list of affected packages?
15:50 <stokachu> xnox: running a rdepends to see which version of the library is used
15:50 <stokachu> using ldd will also give you the library version used
15:50 <xnox> stokachu: ok. There is also "reverse-depends" command, that I find is often faster (it uses pregenerated caches)
15:50 <xnox> no more questions from me.
15:51 <bdmurray> Does anybody else have any questions?
15:51 <stokachu> xnox: is that different than the rdepends argument?
15:52 <stokachu> apt-rdepends?
15:52 <stokachu> or that may be recursive
15:52 <ScottK> If you have a library that needs a version bump, what packaging changes are needed?
15:53 <xnox> stokachu: one is local, the other one uses remote cache. Otherwise basic functionality is about the same. But each has extra features lacking in the other tool.
15:53 <stokachu> ah ok good t oknow
15:53 <ScottK> Also reverse-depends -b will give you the reverse build-deps.
15:54 <stokachu> ScottK: changing the SONAME and corresponding name for the binary package
15:54 <stokachu> call ldconfig within postinst
15:54 <stokachu> hm.. what else
15:55 <stokachu> i think those are the main things
15:55 <ScottK> Other than sosreport and the things related to your work, what interests in Ubuntu development do you have?
15:56 <stokachu> im a big fan of KDE so I'd like to be more active in that area
15:56 <stokachu> maybe not so much the DE portion but its applications
15:57 <stokachu> I also enjoy blogging and talking about products/projects in a way that can benefit small businesses
15:58 <stokachu> wrt juju I have a interest in the "scaling down" part of the environment
15:59 <bdmurray> Alright, is that all the questions?
16:01 <bdmurray> #vote Adamd Stokes for Ubuntu Core Developer
16:01 <meetingology> Please vote on: Adamd Stokes for Ubuntu Core Developer
16:01 <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)
16:02 <xnox> +1
16:02 <meetingology> +1 received from xnox
16:02 <ScottK> +0 #clearly knows a lot, but straight to core-dev is a big jump - I would be more comfortable starting with PPU or maybe server dev.
16:02 <meetingology> +0 #clearly knows a lot, but straight to core-dev is a big jump - I would be more comfortable starting with PPU or maybe server dev. received from ScottK
16:02 <Laney> +1
16:02 <meetingology> +1 received from Laney
16:02 <stgraber> +1
16:02 <meetingology> +1 received from stgraber
16:02 <bdmurray> +1
16:02 <meetingology> +1 received from bdmurray
16:02 <Laney> micahg: bdrung
16:03 <bdrung_work> i still have to catch up.
16:03 <Laney> ok, well no need anyway :-)
16:04 <xnox> micahg had tentative +0
16:05 <bdmurray> #endvote
16:05 <meetingology> Voting ended on: Adamd Stokes for Ubuntu Core Developer
16:05 <meetingology> Votes for:4 Votes against:0 Abstentions:1
16:05 <meetingology> Motion carried
16:05 <stokachu> sweet!
16:06 <stokachu> bdmurray: just noticed Adamd Stokes :)
16:06 <Laney> well done ;-)
16:06 <arges> congrats
16:06 <bdmurray> stokachu: sorry about that typo
16:07 <stokachu> bdmurray: its cool man
16:07 <stokachu> micahg: ScottK, promise not to let you down :)
16:07 <xnox> stokachu: =) congrats.
16:07 <stokachu> thanks everyone :)
16:07 <bdmurray> Okay, we already handled AOB in the previous meeting ;-) so I guess that's a wrap.
16:08 <stokachu> thanks again for your time and restarting the meeting
16:08 <stgraber> stokachu: congrats!
16:08 <ScottK> stokachu: The main thing is to ask when you're not sure.  Core-dev means you have more ability to break things, it doesn't mean you're expected to know it all.
16:08 <stokachu> ScottK: i will definitely do that
16:08 <stokachu> stgraber: thanks!
16:08 <ScottK> The breaking part or the asking part?
16:08 <bdmurray> #endmeeting