[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00] <bac> good morning
[15:00] <bac> me?
[15:00] <bac> anyone else?
[15:00] <salgado> me
[15:01] <bac> sinzui, danilos, gary_poster, flacoste, deryck, noodles775: ping
[15:01] <flacoste> me
[15:01] <gary_poster> yup me sorry
[15:01] <noodles775> me (sorry)
[15:01] <gary_poster> was here seconds before your good morning
[15:01] <gary_poster> will cal trops
[15:01] <gary_poster> call troops
[15:01] <sinzui> me
[15:01] <bac> EdwinGrubbs: ping
[15:02] <EdwinGrubbs> me
[15:02] <mars> me
[15:02] <leonardr> me
[15:02] <bac> gmb: ping...can you find your TL?
[15:02] <bac> hmm, no bug types around at all
[15:03] <gmb> me
[15:03] <adeuring> me
[15:03] <abentley> me
[15:04]  * noodles775 calls jelmer in (as he's started as a mentat).
[15:04] <bac> thanks noodles775
[15:04] <bac> [topic] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <bac> * Roll call
[15:04] <bac>  * Agenda
[15:04] <bac>  * Outstanding actions
[15:04] <bac>  * Mentoring update
[15:04] <bac>  * New topics
[15:04] <bac>  * Peanut gallery
[15:05] <danilos> bac, hi, I have a call now (when have we changed the time of the meeting?)
[15:05] <bac> danilos: we changed a few weeks ago after discussion here
[15:05] <danilos> bac, I guess that was the week when I was sprinting then
[15:05] <bac> danilos: sorry if you didn't get updated
[15:05] <bac> danilos: can you make it next week?
[15:06] <bac> [topic]  Outstanding actions
[15:06] <MootBot> New Topic:   Outstanding actions
[15:06] <danilos> bac, no worries, we'll work something out (I might change the phone call time for next week)
[15:06] <bac> [topic] thumper/mwh to bring up issues with launchpadlib testing on ML.
[15:06] <MootBot> New Topic:  thumper/mwh to bring up issues with launchpadlib testing on ML.
[15:06] <bac> we we discussed the work leonardr did for automating launchpadlib tests, thumper and mwhudson had some concerns
[15:07] <bac> michael did bring it up on the list but as far as i could tell it was unresolved.
[15:07] <leonardr> well, i know there were concerns about automatically creating launchpadlib objects
[15:07] <bac> leonardr or gary_poster do you have any update on possible changes?
[15:07] <leonardr> i landed a branch that takes that out. you now have to create your own launchpadlib object
[15:08] <gary_poster> bac, leonardr addressed all concerns to my knowledge.  It is cooler and more flexible now
[15:08] <bac> leonardr: great
[15:08] <leonardr> there were also concerns about using the sampledata users, which i also addressed
[15:08] <leonardr> there's a helper function that will create an oauth access token for any user
[15:08] <leonardr> so you can create a dummy user and then give them an access token if you want
[15:08] <leonardr> i think that was it
[15:08] <bac> leonardr: is it easy to create an object for anonymous access?
[15:09] <leonardr> bac: i haven't tried it, but Launchpad.login_anonymously() should work in the pagetests just as it does in real life
[15:09] <bac> ok, good.
[15:10] <leonardr> one thing we could add to make things nicer is a url alias for 'the launchpad instance accessible to the testrunner'
[15:10] <leonardr> which is http://api.launchpad.dev/ (not https)
[15:10] <bac> what do we want to do going forward?  start requiring lplib tests for new API changes?  what about coverage for existing methods?
[15:10] <bac> i approved some API changes yesterday but didn't require a lplib test.  i think we should.
[15:11] <leonardr> bac, did you require a test at all?
[15:11] <bac> leonardr: the webservice test was updated to show the new field
[15:11] <bac> that was all
[15:11] <gary_poster> From Foundations' perspective, my main interest is in tests verifying that our critical clients work with the specified webservice version
[15:11] <leonardr> certainly if it's something that requires a test (and doesn't need to be tested by hacking HTTP requests) an lplib test is better than a webservice() test
[15:12] <leonardr> we thought of two ways to do what gary says, and i don't think we've decided on one (not that we have to go all one way or the other)
[15:12] <gary_poster> And from a general perspective, I'm a string +1 on using launchpadib directly now that we have it.  Leonard wrote one (yesterday) that caught a problem that would not have been otherwise caught.
[15:12] <gary_poster> argh
[15:12] <gary_poster> strong
[15:13] <leonardr> the first way is to write a launchpadlib test every time we make a change in (eg.) 2.0 that doesn't bleed through to earlier versions
[15:13] <leonardr> make sure that 1.0 still has the old behavior, and 2.0 has the new
[15:13] <leonardr> the other way is to get our critical clients to expose their launchpadlib test suites, and run them as part of the launchpadlib test suite
[15:14] <leonardr> the apport developers are working on this now. if we run apport's launchpadlib tests as part of launchpad's tests (just as we run launchpadlib's launchpadlib tests) we'll know when we make a change that breaks apport
[15:14] <abentley> I think the second way more directly supports gary_poster's interest.
[15:15] <bac> leonardr: that effort is great and something i assume foundations will pursue.  but as reviewers we need to decide how to handle testing of changes to API functionality.  it sounds like you're in favor of using lplib tests over the older web service tests.
[15:15] <leonardr> bac: yes, unless you're writing a test that needs to send a specific http request
[15:16] <leonardr> in which case webservice() is better
[15:17] <bac> that sounds good to me.  the web services tests will require updating when new fields are exposed but the actual tests should be lplib.
[15:17] <gary_poster> abentley: (agree, and Francis and I have talked about different ways we can attack that.  I suspect that the first way will be appropriate sometimes, particularly for API calls that are heavily used, but this hasn't been hardened yet.)
[15:18] <bac> anything else on this topic?
[15:18] <bac> [topic]  * bac to restart discussion on community reviewer/committers after feedback from elmo
[15:18] <gary_poster> not from me
[15:18] <MootBot> New Topic:   * bac to restart discussion on community reviewer/committers after feedback from elmo
[15:18] <abentley> gary_poster, it can be very difficult to predict what kind of changes will break clients.  Some will accidentally depend on bugs, for example.
[15:18] <gary_poster> abentley: agreed.
[15:19] <bac> i've been unable to get an opinion from legal about community reviewers/committers but got a strong one from elmo.  i'll share that with the list and start the discussion again.
[15:20] <bac> apologies for dragging this out.
[15:20] <bac> [topic] peanut gallery
[15:20] <MootBot> New Topic:  peanut gallery
[15:20] <bac> any new topic to discuss?
[15:20] <bac> oh, wait, backup.
[15:20] <noodles775> Just an update that Jelmer has started reviewing on Thurs...
[15:20] <bac> [topic] mentoring update
[15:20] <MootBot> New Topic:  mentoring update
[15:20] <noodles775> :)
[15:21] <noodles775> as a mentat.
[15:21] <bac> welcome jelmer to the meeting and as a reviewer mentat.
[15:21] <bac> noodles775:  thanks for doing the mentoring
[15:21] <jelmer> thanks Brad
[15:21] <noodles775> bac: np!
[15:22]  * wgrant wonders in which direction elmo's opinion was.
[15:22] <bac> so everyone bring lots of good reviews to jelmer on thursdays
[15:22] <noodles775> Yeah, particularly some non-soyuz ones!
[15:22] <bac> so, back to the peanut gallery.  are there any other topics?
[15:23] <bac> 3
[15:23] <abentley> I am having trouble remembering to attend this meeting
[15:23] <abentley> And part of it is because it's no longer a weekly meeting.
[15:24] <flacoste> it's not weekly anymore?
[15:24] <abentley> Instead of notifying people when it's *not* happening, maybe we could notify people when it *is*?
[15:24] <bac> abentley: would you prefer a regularly scheduled meeting even if there isn't much going on or the disruption of occassionally canceled ones?
[15:24]  * noodles775 just assumes it is on, unless there's notice.
[15:24] <abentley> flacoste, it's been cancelled due to lack of agenda frequently.
[15:26] <abentley> noodles775, bac: I find the routine helps me remember.
[15:26] <bac> abentley: but if you're around at this time, and keep your calendar free for the hour, is it a burden if we just ping you to join?
[15:26] <abentley> bac, no, that's fine on my end.
[15:27] <bac> abentley: i understand routine is nice.  but i figured saving the team from showing up when there isn't much to discuss outweighs it.  and others have commented they like the idea.
[15:27] <bac> abentley: and you're at a disadvantage b/c you have no other team members to check to see if you're around...
[15:28] <abentley> abentley, true.
[15:28] <abentley> bac, true
[15:28] <bac> if there's nothing else let's call it a meeting.
[15:28] <bac> thanks for coming
[15:28] <bac> #endmeeting
[15:28] <MootBot> Meeting finished at 09:28.
[15:28] <noodles775> Cheers bac
[22:31] <bac> hi thumper, mwhudson, rockstar -- up for a reviewers meeting?
[22:31] <mwhudson> alright
[22:31] <thumper> bac: if it's quick, I have something on soonish
[22:32] <bac> thumper: let's do quick, then
[22:32] <bac> in the ameu meeting we had a very brief conversation
[22:32] <bac> we talked about the issue michael raised on the list wrt launchpadlib
[22:33] <bac> it sounds like leonard has addressed all of your concerns.
[22:33] <bac> he provides helpers for creating credentials for a user and getting an object and logging in anonymously is easy
[22:34] <bac> we agreed that new API functionality should be tested with new lplib tests, which are preferred over the webservice tests
[22:34] <bac> of course the old tests will need to be kept up-to-date when new things are exported, unless a test is completely replaced
[22:35] <bac> other than that, i am supposed to reopen the discussion about community reviewers/committers based on info i've gotten from IS
[22:35] <bac> that, in a nutshell, was the meeting.
[22:35] <bac> of course it took us closer to 30 minutes to get all that out
[22:35] <bac> y'all have anything else?
[22:36] <thumper>  what is the result of the email from is?
[22:37] <bac> for many of the reasons we brought up in our internal discussion, elmo does not want to allow commit rights to a branch that automatically goes into production/edge
[22:38] <thumper> but happy for reviews?
[22:38] <bac> he thought it'd be ok if we create an intermediate branch that accepts contributions from some community members but must be reviewed by a canonical employee before deployment
[22:38] <bac> thumper: i'll need to review his email to refresh my memory on the reviewer issue
[22:38] <thumper> ok
[22:38] <mwhudson> bac: yeah, i'm happy with the launchpadlib test scaffolding now
[22:38] <bac> iirc he was not in favor of a single external reviewer.
[22:38] <bac> mwhudson: great
[22:39] <bac> i think there is great value in having community reviewers, even if they do need a second pair of eyes
[22:39] <bac> anyway, let me formulate a proposal and get it out on the list
[22:40] <bac> that's all i've got
[22:40] <thumper> I've nothing to add
[22:40] <bac> ok.  well let's call it a meeting then so you can get to your next one.
[22:40] <bac> later.
[22:43] <mwhudson> thanks bac