16:03 <slangasek> #startmeeting
16:03 <meetingology> Meeting started Tue Jun 24 16:03:50 2014 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:03 <meetingology> 
16:03 <meetingology> Available commands: action commands idea info link nick
16:03 <pitti> right, last meeting was a no-op as there were no topics and UOS going on
16:04 <slangasek> is it just the three of us? mdeslaur sent his regrets, and I think infinity is off-cycle at the moment
16:05 <pitti> right
16:05 <pitti> kees didn't respond
16:05 <slangasek> ok
16:05 <pitti> but we don't have pending actions, and AFAIK the only current issue is the juju-core MRE
16:05 <slangasek> does that give us quorum to do anything substantial?  Do we have anything substantial to do? :)
16:05 * pitti waves to rbasak
16:05 <rbasak> o/
16:05 <ScottK> MRE really only needs one TB member, right?
16:05 <pitti> yes, MREs can be ack'ed by a single TB member, but this is a rather general issue which might raise some questions
16:06 <pitti> FWIW, I'm not sure whether that has acutally been the intent when writing that, or just a grammar problem :)
16:06 <slangasek> [TOPIC] juju-core MRE
16:06 * pitti tosses in bug 1329302
16:06 <slangasek> I thought it was quite intentional fwiw
16:06 <pitti> -ENOUBOTTU
16:06 <pitti> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1329302
16:07 <pitti> that has the proposed changelog
16:07 <slangasek> I'm afraid I'm not up to speed on the mail thread
16:07 <pitti> there's a lot of "fix for utopic" bits there which seem quite irrelevant, then some commits which I can't really make sense of, and some which are quite obvious and relevant fixes
16:07 <slangasek> irrelevant, but presumably not blockers under the MRE policy?
16:08 <pitti> under SRU policy
16:08 <pitti> like, juju-bootstrap reportedly isn't working at all, but as it's a new feature it's not technically a regression
16:08 <pitti> so juju in general is in a tricky position
16:09 <pitti> it's in universe and formally unsupported, but with all the buzz around it we support it anyway, and I figure it has a lot of users :)
16:09 <rbasak> s/juju-bootstrap/juju-quickstart/ I think?
16:09 <pitti> so I do see the value of making juju-bootstrap work for an LTS
16:09 <rbasak> That was new in Trusty, and regressed late in the cycle
16:10 <rbasak> So no regression from < Trusty, no.
16:10 <pitti> rbasak: err yes, sorry; that "install it, no I don't want to talk to you" thing :)
16:10 <rbasak> :)
16:10 <pitti> rbasak: are there other fixes in that update which do fall under the normal SRU criteria, i. e. major regressions / data loss / upgrade failures from precise etc?
16:11 <rbasak> pitti: there are some, eg: https://bugs.launchpad.net/juju-core/+bug/1302205
16:12 <pitti> ok; also not technically a rgression as arm64 is new, but I do see that it's a good MRE material
16:12 <slangasek> this conversation feels a bit low-level
16:13 <pitti> so AFAICS there's a number of fixes in the "we want it" category (but not covered by the SRU criteria), and not a lot of regression fixes
16:13 <pitti> IOW, exactly what an MRE is for
16:13 <ScottK> From a release team POV, it seems like juju tends to stack features late in the development cycle, so having a number of bugs to address post-release doesn't seem surprising.
16:13 <pitti> rbasak: is quickstart under some kind of CI so that it won't break again?
16:14 <pitti> (as an example how newly introduced features are being handled/tested upstream)
16:14 <rbasak> I think that if you're not happy about some specific items in this changelog, then upstream will probably be happy to update their own criteria on what lands in their stable branch based on your guidance.
16:14 <rbasak> pitti: so after the quickstart bug, it became evident to me that quickstart and juju-core are quite heavily tied together, which I didn't realise before.
16:14 <pitti> rbasak: no, I was actually saying "this is not an MRE request which is actually just a "simple" SRU"
16:15 <rbasak> So I filed bug https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1325013
16:15 <pitti> right, that's what my question was aimed for
16:15 <rbasak> I commit to fixing this. I haven't done it yet as I'm still untangling various juju-core pieces - this SRU is the next piece for this.
16:15 <rbasak> I have filed bugs for everything that I think needs doing from the QA perspective.
16:16 <pitti> I'm a bit hesitant to make quickstart work now and advertise it, just to break it with the next microrelease
16:17 <rbasak> How about I commit to testing juju-quickstart manually with each juju-core trusty-proposed upload, until I have a dep8 test in place?
16:17 <pitti> rbasak: OOI, the changelog doesn't actually mention quickstart; will that be a separate SRU of juju-quickstart itself?
16:17 <pitti> rbasak: sounds fine to me, as part of the verification test plan
16:17 <rbasak> Since we're not running dep8 tests in trusty-proposed automatically anyway, I'd have to do it manually regardless.
16:18 <rbasak> Yes - I'll need a separate juju-quickstart SRU, but I don't think that'll need an MRE as it's a straightforward cherry-pick for that specific issue.
16:18 <pitti> rbasak: we can manually run them BTW (bug is filed for doing it automatically, that would indeed be helpful)
16:18 <pitti> rbasak: ack
16:18 <rbasak> I've been running adt-run locally before uploading to -proposed in general, for the dep8 tests I've written.
16:18 <pitti> slangasek, stgraber: so, I don't have further questions about this, do you?
16:19 <slangasek> I haven't looked closely enough to formulate intelligent questions
16:19 <pitti> I'm fine with a provisional MRE to see how this goes and test-drive the verification etc.; not yet convinced enough to turn it into a permanent MRE
16:19 <slangasek> but as the policy is that you only need one TB member to sign off.. :)
16:19 <pitti> heh
16:19 <stgraber> based from what i remember of the thread and what I re-read just now, I don't think I've got any question
16:20 <slangasek> [ACTION] pitti to record a provisional MRE for juju-core
16:20 * meetingology pitti to record a provisional MRE for juju-core
16:20 <rbasak> Thank you!
16:20 <pitti> ok, so I'll follow up to that mail with that summary
16:20 <pitti> (and edit the wiki page)
16:21 <pitti> thanks rbasak
16:21 <slangasek> ok
16:21 <slangasek> other agenda items?
16:21 <pitti> zarro community bugs
16:22 <slangasek> looking to see if there were any action items from before
16:22 <pitti> slangasek: no, they all got resolved
16:22 <slangasek> https://wiki.ubuntu.com/TechnicalBoard/TeamReports/Current hasn't been updated since 2014-05-12, which is 3 meetings ago?
16:22 <pitti> nothing else on the ML either
16:23 <pitti> slangasek: we didn't have a meeting on June 6 (no topics, UOS)
16:23 <pitti> May 27 was on Malta, trying to remember that one
16:24 <slangasek> http://irclogs.ubuntu.com/2014/05/27/ has no logs for this channel ;)
16:24 * stgraber digs for a log
16:25 <pitti> got that
16:25 <pitti> we ack'ed the LibO and vlc MREs
16:25 <slangasek> right
16:25 <pitti> nothing else
16:25 <stgraber> http://paste.ubuntu.com/7695848/
16:25 <pitti> (and that was committed to the wiki)
16:25 <slangasek> [TOPIC] other items from list
16:25 <slangasek> none
16:25 <slangasek> [TOPIC] other community bugs
16:25 <slangasek> none at https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
16:26 <slangasek> so that's all, yes?
16:26 <pitti> nothing else from me
16:26 <stgraber> yep
16:26 <stgraber> looks like I'll be chairing our next meeting
16:27 <slangasek> [TOPIC] Next meeting
16:27 <slangasek> which is when?
16:27 <slangasek> July 8?
16:28 <slangasek> Next meeting, July 8 @ 1600 UTC - that works for "everyone"?
16:28 <pitti> looks right
16:28 <slangasek> [AGREED] stgraber is chair for the next meeting
16:28 <slangasek> [AGREED] Next meeting, July 8 @ 1600 UTC
16:28 <slangasek> #endmeeting