#launchpad-meeting 2006-11-27
<ddaa> Yeay
<lifeless> poolie sends apologies
<ddaa> Let's start
<ddaa> MEETING STARTS
<ddaa> sorry being late, just came back home, jetlag and stuff
<ddaa> == Agenda ==
<ddaa> Next meeting Monday 4 December, 09:00-09:45 UTC.
<ddaa>  * production status
<ddaa>  * naming convention [SteveA] 
<ddaa>  * status reports
<ddaa> == Roll call ==
<ddaa> _thumper_ is on leave until start of December.
<ddaa> lifeless says: poolie sends apologies
<SteveA> morning
<ddaa> jamesh: ping
<ddaa> spiv: pin
<jamesh> hi
* SteveA hands lifeless a pin to write new-zealandish with
* ddaa giggles
<SteveA> the pin is mightier than the sword
<spiv> I'm here.
<ddaa> There was a kiwi woman at the hostel... I figured out that .nz people "spin time" :)
<ddaa> okay 'vrybody in there
<ddaa> == Production status ==
<ddaa> New rollouts or production problems.
<SteveA> ddaa: there is a bar/restaurant place call Bazar just down the road from me
<SteveA> http://www.specialnite.com/venues/location/the_pijp/bazar/
<ddaa> SteveA, the one you recommended to me for a stay in Rotterdam?
<SteveA> on the subject of new rollouts, when can we expect the smartserver to run on the supermirror?
<ddaa> So, anything of notice happened in the past two weeks or so in production?
<SteveA> and also the viewcvs kinda stuff?
<ddaa> Is there anything in production in need of firefighting?
<lifeless> SteveA: so there is a wsgi module for it. AFAIK its just a matter of configuration now.
<lifeless> spiv: is that right ?
<spiv> lifeless: Partly ;)
<lifeless> spiv: for the http side that is
<spiv> lifeless: where "configuration" includes "make it work with the different directory layout on disk"
<SteveA> I'd like us to have a meeting (not this one) to determine exactly what needs doing so that we can have the smartserver runing on the supermirror
<SteveA> and who is going to do it and when
<SteveA> right after this here meeting works for me
<spiv> Which is possibly taken care of by the apache magic already, but I don't know exactly how that hooks together yet.
<ddaa> spiv has review meeting just after this one AFAIK
<SteveA> true.  so do i
<lifeless> spiv: if we can pass the path in to the vfs - the chroot transport should be all we need. just command line glue
<spiv> Also, there's an issue that the admins don't like mod_fastcgi, so the magic to hook up WSGI with something else (probably mod_python) needs to be figured out.
<lifeless> spiv: they dont ?
<jamesh> they won't run fastcgi, but they'd run Bazaar code within apache?
<spiv> lifeless: there's a non-free fastcgi thing for a apache, or a free one that sucks, apparently.
<spiv> I spoke to elmo about it briefly at allhands.
<lifeless> how badly does it suck? I mean, is it worth more dev time to reimplement something that exists..
<spiv> Well, there's lots of existing modules for connection WSGI to stuff, including, I believe, mod_python stuff, so it's not something we'd have to implement ourselves.
<spiv> It's also likely we'll want mod_python on the supermirror eventually as a better way to do the URL rewriting that mod_rewrite + a huge periodic dump file from the database.
<SteveA> or just run it as a twisted daemon?
<jamesh> mod_python basically means allowing the code to do whatever apache can, which is why I was surprised the admins would prefer that
<SteveA> jamesh: it's a freeness issue I think
<ddaa> spiv: that sounds like a useful cleanup, but the mod_rewrite problem has not been a problem so far. It's stupid simple but robust.
<ddaa> so I'd call that a low priority cleanup.
<spiv> ddaa: right.  "eventually" :)
<SteveA> ok.  I'm getting confused.  I want to explain what I want out of this.
<SteveA> What I want is a set of numbered list items on a wiki page that lays out all the steps from where we are now, to having the supermirror running the smartserver.  If there are parts that need investigation then that item says
<SteveA> "investigate [foo]  to determine whether [bar] "
<SteveA> spiv: I'd like you to be responsible for writing this
<spiv> SteveA: ok.
<spiv> I think that's a good idea.
<ddaa> spiv: today after review meeting might be late for you. What about meeting tomorrow? Who else than you, SteveA and I needs to be present?
<SteveA> then next time I ask "how is this going", you'll be able to say "did A then B, and the result of investigating [foo]  was [bar] "
<SteveA> ddaa: I think we don't need the meeting, if spiv writes the doc.
<spiv> I'll write the doc within 24 hours, put it on the wiki, and post to the list about it.
<SteveA> thank you spiv 
<ddaa> ACTION: spiv writes supermirror-smart-server plan
<spiv> I think discussion about it can probably be done adequately by email.  If it turns out to be a messier than expected discussion, we can look at scheduling a meeting.
<SteveA> I'd like the same for viewcvs-style support, at some point
<ddaa> spiv: ++
<ddaa> SteveA: let's talk this week about what we'd like Tim to work on next month. The bzrweb integration could be one of those items.
<ddaa> Moving on.
<ddaa> == Naming convention ==
<ddaa>  * Use a naming convention for branches to be hidden/removed (Steve Alexander)
<SteveA> a bzr / supermirror user asked for a branch of his to be removed
<SteveA> or hidden
<SteveA> as it was just an experiement
<SteveA> I spoke with him, and found out that he wanted it hidden just for aesthetic reasons
<SteveA> that is, no problems with illegal data or anything
<SteveA> I explained we can't easily do that right now
<SteveA> he said okay, and suggested that we use a naming convention for branches that are to be hidden
<SteveA> so that people can use this now, and they get hidden when we have support in the code
<SteveA> maybe branch--hidden or something
<ddaa> mh... double dash...
<lifeless> I dont understand why we dont just use branch status
<jamesh> hiding obsolete branches by default?
<lifeless> right
<lifeless> with a 'show all' page to show them
<spiv> Also "merged" branches.
<ddaa> lifeless: because we want to represent a "deleted" state, for branches that should eventually be garbage collected
<lifeless> I feel quite uncomfortable with the idea of conflating 'hide branches' and 'name'
<ddaa> which is different from merged/abandoned, which should appear in the "show all branches" listing even when we have branch deletion support
<lifeless> ddaa: so add a state for that. One new entry in the dbschema, called 'to be deleted'.
<ddaa> which is awkyard since it's not clear whenever we will actually support it
<SteveA> I think we should use the name for this, unless the software will support it reasonably soon, conflation or no conflation
<ddaa> also it's more work than just agreeing on a naming convention
<jamesh> if we have a  "to be deleted" state, people might expect the branch to stop being published.  Is that the intent?
<SteveA> the name is something users can change today, and the conflation is not harmful in the long term.  it just goes away.
<SteveA> becauase the branches do
<ddaa> I think I already used something like "status=obsolete name=<foo>-deleted[-N] "
<spiv> SteveA: We already have a status field with values like "obsolete" and "merged".  Why not make the proposed UI changes use that?
<SteveA> spiv: we can.  if it is done *soon*
<ddaa> I like SteveA's suggestion
<ddaa> I think I understand the issue, and I'll reply to the questions by email today.
<SteveA> I want to avoid us leaving this gap on account of a feature that won't be ready soon.  So, if soon, great.  If not soon, workaround.
<ddaa> workaround sounds better to me right now, it's less commitment and avoids raising expectations, and having more stub features in the UI.
<ddaa> Shall we move on?
<ddaa> == Status reports ==
<ddaa>  * spiv: supermirror-smart-server.
<ddaa>  * jamesh: spec-branches.
<ddaa>  * ddaa: python import.
<jamesh> spec-branches is still in the queue
<ddaa> python import: up and running since all-hands
<ddaa>  * ddaa: pyrex.
<spiv> The status of supermirror-smart-server is probably best addressed by the wiki page I've promised to write shortly.
<ddaa> Dunno if SteveA has reviewed the pyrex branch, or if their status has changed somehow.
<spiv> So I'll skip that for now, if that's alright.
<ddaa> spiv: that's alright, it's been discussed enough at the beginning of the meeting.
<SteveA> so, the pyrex thing is ddaa's experimental new svn bindings, focused on what we need
<SteveA> is that right?
<ddaa> SteveA: that's right
<SteveA> how complete is the pyrex stuff for what we need?
<ddaa> Not complete yet. Includes removal of dep on native swig bindings.
<ddaa> Now, the prereq have been merged to allow the work to start on using svn_ra API for the critical code paths.
<SteveA> what is svn_ra
<SteveA> ?
<SteveA> what do you want to do with this branch?
<ddaa> Which will allow very substantial improvements in efficiency. But I'd like feedback on the proof-of-concept code that's already pending review.
<ddaa> svn_ra is the low-level "talk with svn over the wire" API
<jamesh> ra == repository access
<ddaa> goals: simplify the code (only one entry point to libsvn, thin bindings), more flexibility (allow access to all libsvn functionality), more efficient (allow using functionality not available with pysvn)
<ddaa> ultimately, the problem is that all all python-libsvn bindings suck in one way or another
<ddaa> and the svn import code has reached the point where that's become the next roadblock.
<SteveA> what problems are we seeing that are blocked by shoddy bindings?
<ddaa> using svn_ra allows to use a single session in the critical loop, which cuts down on round-trip and connection count
<ddaa> SteveA: imports failing because of connection errors in the middle of the import
<ddaa> current code involves literally thousands of connections (sequential) for even moderately sized imports
<ddaa> makes it slow
<ddaa> makes it unreliable
<ddaa> and put uncessary load on community resources
<SteveA> ok.
<SteveA> lifeless: what would you suggest to do with ddaa's branch next?
<lifeless> SteveA: its currently in the review queue, with you as the reviewer.
<lifeless> I dont really get the question I think. Surely we want to achieve two things
<SteveA> I'm not really qualified to review it
<lifeless> 1) demonstrate that this is a solid, reliable way forward. I.e. check that callbacks work properly, and that the apr memory pool stuff is managed well
<lifeless> 2) start using it.
<lifeless> I would ask for the same thing you asked spiv to do - a list of whats needed to achieve these two things.
<SteveA> thank you lifeless 
<SteveA> I agree with your points
<SteveA> in addition, for point 1, this is a new binding that we'll be maintaining
<SteveA> so we should have a good sense that it is a better way to proceed than maintaining existing bindings
<lifeless> the existing bindings are both hard to maintain
<SteveA> questions like, has the upstream for any of the bindings improved things since we last looked?
<lifeless> I vouch for them being difficult
<ddaa> meeting time ended: jamesh, spiv, you can go and workrave
<SteveA> ddaa: I think you should do some more management of the meeting
<SteveA> simply announcing that the time is ended is not good meeting management
<ddaa> well, anyway all theh points have been adressed
<ddaa> we can continue to talk about the svn bindings
<ddaa> jelmer has posted some improvements to the upstream swig bindings
<SteveA> lifeless: ok, so someone competent to do so needs to review it for the points you listed
<ddaa> it's in the svn 1.5 branch and backported in edgy
<ddaa> however, the swig bindings are not reliably maintained upstream
<SteveA> also, is there value in this being released as open source if we do decide to go with it, to get other contributions?
<lifeless> I think so.
<ddaa> the pyrex bindings will be released as they are part of cscvs
<ddaa> and releasing cscvs is something I want to do before the end of the year
<SteveA> ddaa: the pyrex bindings exist as your private experiment.  they are not part of cscvs at this point
<ddaa> SteveA: well, assuming they get merged, of course
<SteveA> one of the points of this review process is to decide whether we switch to them
<lifeless> it doesn't make a lot of sense to me for the bindings to be part of cscvs
<ddaa> makes sense to me, as they are very focused on what cscvs needs
<ddaa> to keep them as simple as possible
<ddaa> no more exposed functionality than necessary
<ddaa> so, no more bugs than necessary
<SteveA> it's an API binding
<SteveA> adding new API to it won't create bugs in the rest, I think
<ddaa> I see them more as a glue. Generic libsvn bindings is... complicated, it's not a nice-and-simple API
<SteveA> if there's a point in releasing it, it's so that people get interested in it, perhaps to extend it, and reduce our maintenance burden
<spiv> It's a clearly independent module in terms of functionality.  If nothing else, keeping them seperate will make it easier for the community to contribute to them.
<SteveA> trying to enforce a false limit on its scope will not help people get interested in it
<spiv> A small, fairly simple set of pyrex files is much less scary to a potential contributor than those files + all of cscvs, which is pretty hairy in parts.
<ddaa> I do not think there is intrinsic value in getting people interested in them. If there was actual interest in the python community for effective libsvn bindings, we would not have to roll our own.
<spiv> And similarly, a contributor to cscvs might be scared by the false impression they have to learn pyrex or compile stuff to hack on cscvs.
<ddaa> spiv: right, it would be good to clean up the cscvs packaging to have clear modules and extension points. The overall design is okay, but the execution is not quite there in terms of practical modularity.
<spiv> I think we should try fairly hard to be a good open source citizen, providing reasonably neatly packaged source, rather than just a messy, tangled dump.  We will damage the goodwill we generate by releasing source if we do it in a community-hostile way.
<SteveA> ok
<ddaa> some truth in that. That's why I want to keep this release low-key.
<ddaa> It's just there for people who have expressed a desire to help already.
<SteveA> who will review ddaa's pyrex stuff?  someone who knows about how svn bindings need to work.
<jamesh> spiv:a separately packaged binding only really makes sense if things other than cscvs will use it
<jamesh> if the aim of the binding is just "as much of libsvn as cscvs needs", then it doesn't really have a separate target audience
<ddaa> jamesh: ++
<ddaa> Also, the code might be independent in terms of  functionality, but there's value in keeping it couple in terms of design for KISS compliance.
<jamesh> plus, if the binding is "as much of libsvn as cscvs needs", then you may need to update the two in lockstep anyway
<lifeless> I have to run another meeting now
<lifeless> I suggest that spiv or jamesh review the code forits pyrexstyle.
<jamesh> which makes separate packages less useful
<lifeless> I have done some  pyrex too, so in a pinch I can review it.
<lifeless> for the svn style, me/spiv/jamesh can review it I suspect.
<spiv> I know some pyrex, and some high-level svn, but not svn API.
<lifeless> use of svn API should not be reviewed in this regard I think
<lifeless> thats ddaa's problem :)
<ddaa> yeah, anyway current code is mostly bug-for-bug compatible
<ddaa> I just want guidance on coding standard, code organisation, etc.
* Starting logfile irclogs/launchpad-meeting.log
#launchpad-meeting 2006-11-30
<kiko> oy
<carlos> hi
<danilos> yo
<kiko> stub!
<kiko> thanks for joining in
<kiko> so for the +translate timeouts
<danilos> thanks stub
<carlos> stub: how do you feel?
<kiko> there are some approaches we can take
<stub> ok. Had a nice nap.
<kiko> 1. we currently issue a large number of suggestion queries per page; I could change the code to issue only 4
<kiko> 2. we could change the loading of suggestions to come in via ajax. one question is whether to do it as N small hits or as the 4 queries (as I propose in 1.)
<danilos> will we sacrifice detail for 1? like not listing which are "used in..." etc?
<kiko> 3. we could do the database refactoring and then revisit the issue again.
<danilos> or is it only about 4 BIG queries?
<kiko> no, danilos -- equivalent queries, but doing them in one shot instead of 10
<danilos> kiko: ok, but how much will that help? stub?
<carlos> kiko: will it work if a user selects 100 queries?
<kiko> you mean 100 translations?
<kiko> yeah, it will
<kiko> it will issue only 4 queries
<carlos> kiko: yeah, sorry
<kiko> one for each type of suggestion
<stub> Issuing fewer, large queries is generally better than many small.
<kiko> (or are they 5? I forget. it's a small number)
<stub> But we need to time them to be sure.
<kiko> I think it will help some, but not too much
<carlos> kiko: me too, I think it's just 4
<carlos> I would like to do both
<danilos> stub, kiko: I am more thinking on order of magnitude -- I am aware it will help, but will it help enough?
<carlos> optimise the DB + move it to reduce the amount of queries
<kiko> it's basically an "id IN (...)" query instead of N "id = X"  queries
<carlos> even if just the optimisation kills the timeouts
<kiko> danilos, it won't help enough, no. it will mitigate the problem.
<danilos> carlos ++
<danilos> kiko: ok, so I am all for both, just like carlos
<kiko> the only reason for doing 1. before 3. is because I don't know when you guys can get to 3.
<kiko> I'm really unhappy with all the pain being inflicted on SteveA and I on rosetta 1.0
<stub> If we are going to trim the tables down as specced, we might as well do it first to avoid needing to redo work.
<kiko> and I want to make sure the distractions stop so that you can concentrate on those items.
<stub> Also any benchmarking on the old schema will be irrelevant with the new schema
<kiko> stub, nobody's going to have time before 1.0 -- rosetta's in bad shape
<danilos> stub: it involves changing a lot of existing code, so no go at this time, I think
<stub> ok. So 3 isn't an option.
<kiko> stub, I don't think you have much time either..
<carlos> kiko: the only problem with DB optimisations is the migration process
<kiko> carlos, and updating the code.
<carlos> not really, we are talking about more than 24 hours to do the migration....
<carlos> at least that was our guess at all hands
<danilos> carlos: well, each and every query, class usage (ok, we can mitigate that by providing same interfaces in code), etc.
<carlos> we cannot block the DB for 24 hours...
<danilos> carlos: ah, right, but I guess we can block rosetta input for 24 hours
<carlos> danilos: and the rest of launchpad
<danilos> then do the migration on carbon or something
<danilos> hum... stub, any ideas?
<kiko> carlos, 24 hours of migration downtime is manageable, but taking weeks to do the code update is not so much
<stub> Nothing that will be aailable in the short term.
<stub> It might not be 24 hours - again, we won't know until we have benchmarked it.
<kiko> danilos, carlos, stub: we could disable rosetta for that period and survive.
<danilos> ok... btw, stub, will you be considering 8.2 upgrade soon?
<carlos> kiko: without distractions, I'm sure I would migrate code in a couple of working days 
<kiko> carlos, a "couple". :-)
<stub> kiko: We can't do that yet. It isn't implemented. Same with read only launchpad.
<carlos> tests shouldn't be an issue...
<carlos> kiko: 2
<kiko> stub, I mean, we could disable translations.launchpad.net and put a page there.
<kiko> stub, and turn off the cronjobs
<carlos> kiko: no, I already talked with stuart about it, and the migration would lock person table too
<stub> Hmm... is it all on the one domain now? Then we could.
<carlos> and that will lock the rest of launchpad
<kiko> carlos, oh. the person table?!
<stub> carlos: I could work around that by dropping the constraint during migration.
<danilos> can't we have a read-only copy of person table? (we won't be changing it)
<carlos> kiko: we are moving that reference between tables
<carlos> stub: if you feel confident about that, then it's fine for me to shutdown rosetta for the migration, that makes the process much more easy
<kiko> yeah.
<danilos> we can only run into problems with accounts being merged into anothers while we do the migration, right?
<kiko> that's what I was thinking
<stub> danilos: That is a good point.
<kiko> danilos, we can disable merging, good point.
<carlos> that should be easy too
<kiko> it's work, I know
<carlos> at least more easy than playing with triggers and trying to do it on a live system...
<stub> We still need to test this though - we need to have disabled anything that looks at the rosetta tables, and I'm guessing we have portlets around that want to do that.
<kiko> but it's at least not launchpad downtime for an undetermined time
<kiko> mmmm
<danilos> anyway, so, our plan is? go with 1 (optimize translate to have constant number of queries), then when 1.0 rolls out, go on with db optimizations as well
<kiko> stub, can't they go on querying the old tables? or will that be a disaster?
<kiko> danilos, there was the ajax solution. how do people feel about that?
<danilos> kiko: more work for "jumpy" page, imho
<stub> That would work I guess.
<danilos> i.e. suggestions popping up as they're loaded
<danilos> expanding the page, etc.
<kiko> it's true
<kiko> carlos, is that how your patch behaved?
<kiko> I think it also makes it harder for us to tell what the end-user experience is
<danilos> if we use clickety-drop-downs, then that won't be very discoverable, imho
<danilos> right
<carlos> kiko: I think it was hidden and when the user selected it
<carlos> we expand and load the suggestions
<carlos> kiko: if non ajax solution works well, I would prefer it
<danilos> I think this is basically just hiding the problem
<kiko> danilos, well, mitigating the problem
<danilos> though, it might make sense for any *complete* translations
<danilos> i.e. if a message is translated, don't show the suggestions
<danilos> that might even turn out to be better UI, imo
<carlos> anyway, we should do that *after* the optimisation
<danilos> (don't show == use ajax to show them)
<danilos> well, I think these are mutually exclusive
<danilos> almost, anyway
<danilos> i.e. ajax still means separate queries for each message
<kiko> carlos, yeah, you think so?
<kiko> danilos, well, maybe not, but it's more complex if so.
<danilos> though, if we go with above of showing suggestions by default only for untranslated messages
<carlos> well, I guess that we can optimise it, and later add the ajax part as an extra feature
<danilos> both would turn out useful
<danilos> carlos: agreed
<carlos> I know will not be 100% reused and will require more changes
<kiko> ok.
<kiko> so fine, leave +translate with me for the time being. I will refactor the queries and then we'll see how it looks
<danilos> ok
<kiko> hopefully 1.0 will be in better shape by then
<kiko> thanks.
<danilos> now, another db related thing: search?
<danilos> do we only want google-search at this time, or should we go with db search as well?
<danilos> db search may require db upgrade at the very least (for partial indexes)
<carlos> I think we should keep going with the search feature
<danilos> hum, maybe not
<danilos> http://www.postgresql.org/docs/8.0/static/indexes-partial.html
<kiko> google-search for now will be enough
<carlos> as planned
<kiko> after 1.0 you can come back to proper searching
<danilos> I was under the impression that this required 8.2 at least
<stub> yup
<kiko> IF you surprise me and deliver 1.0 without me getting fired
<carlos> kiko: sure, search was a post 1.0 feature
<kiko> okay.
<kiko> carlos, please make an effort to get TR landed so I can do browsing next week, ok?
<carlos> kiko: I will do it before leaving, don't worry
<kiko> thanks
<carlos> danilos: so, let's defer that for post 1.0 
<danilos> carlos: right
<carlos> kiko: anything else?
<kiko> carlos, danilos: no. thanks a lot! 
<kiko> thanks for joining too stub 
<carlos> thanks dudes!
<danilos> yup, especially stub, hope you get better soon
* stub coughs pitifully 
<danilos> :)
#launchpad-meeting 2008-11-25
<barry_> #startmeeting
<MootBot> Meeting started at 21:00. The chair is barry_.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry_> hello everybody and welcome to this week's asiapac reviewer's meeting.  who's here today?
<barry_> jml, mwhudson, thumper ping?
<jml> barry_: hi
<barry_> hi!
<thumper> hi, kinda here
<jml> barry_: I completely forgot about the innate tuesdayness of today :)
<thumper> on a call
<thumper> :-|
<mwhudson> hi
<barry_> jml: well, it's still monday for me, does it still count? :)
<barry_> thumper: no worries, there's not much on the agenda today
<barry_> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry_>  * Roll call
<barry_>  * Come prepared for next meeting with top 1-2 m-p bugs for code review team to consider
<barry_>  * If there's time, the old boring script
<barry_>    * Next meeting
<barry_>    * Action items
<barry_>    * Queue status
<barry_>    * Mentoring update
<barry_>      * al-maisan looking for a mentor
<barry_> [TOPIC] merge proposal bugs
<MootBot> New Topic:  merge proposal bugs
<barry_> so we talked about doing some internal evaluation of top m-p bugs we'd (reviewers) like to see fixed
<barry_> just to give you guys an idea of our priorities, which of course are not necessarily your priorities
<barry_> thoughts?  questions?
<jml> barry_: so you didn't *actually* do any prioritizing?
<barry_> jml: no.  we'll gather information this week and then prioritize, though that might happen on the list instead of on irc
<jml> two comments
<jml> - we're reviewers too, so it's likely our priorities mesh :)
<jml> - on a mailing list, this could be bikeshed city
<barry_> indeed :)
<barry_> well, i don't think so, because each person only gets one or two top bugs.  i suspect most people won't have any
<barry_> and if we bog down on exactly priority, i'll just cut that short and let you guys decide :)
<jml> barry_: :D
<barry_> i suspect there won't be many surprises, but i think it still helps to gather the info
 * jml thinks that Australia's preferential voting mechanism should be more widely known.
<barry_> :)
<barry_> btw, do you guys want to email me your top 1-2 list?  if you do that before the ameu meeting, i can make sure those get represented
 * barry_ needs bug numbers
<jml> sure.
 * mwhudson still hasn't actually used merge-proposals enough to really have a list (!)
<barry_> cool
<barry_> mwhudson: !  use 'em, they rock
<mwhudson> barry_: two weeks leave, mainly
<barry_> leave shmeave :)
<jml> barry_: bug 245257, bug 301836 (as described in my email to launchpad-users)
<ubottu> Launchpad bug 245257 in launchpad-bazaar "include diffs or bundle in merge request notification" [High,Triaged] https://launchpad.net/bugs/245257
<ubottu> Launchpad bug 301836 in launchpad-bazaar "Difficult to figure out what to do with merge-proposals" [Undecided,New] https://launchpad.net/bugs/301836
<barry_> jml: wow, sounds familiar :)
<barry_> anyway, that's all i have really, except that al-maisan is looking for a mentor.  i think the timezone differences probably make it infeasible for you guys to mentor him though
<barry_> do you guys have anything?
<mwhudson> barry_: nothing leaps to mind
<jml> nope.
<barry_> cool.  then have a great week.  it's a short one for us americanos
<barry_> #endmeeting
<thumper> ta
<MootBot> Meeting finished at 21:14.
<barry_> thanks guys
<mwhudson> g'night
<jml> barry_: cya
#launchpad-meeting 2008-11-26
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<sinzui> me
<beuno> me
<gmb> me
<bac> me
<mars> me
<adeuring> me
<EdwinGrubbs> me
<abentley1> moo
<flacoste> me
 * mars was thinking of 'moo', but chicken'd out
<mars> cluck cluck
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Getting graphs in place before rolling out features (way before) - beuno
<barry>  * Merge proposal bugs
<barry>    * 245257 - 5 (diffs/bundles)
<barry>    * 202000 - 3 (complete diffs)
<barry>    * 300462 - 2 (better follow up diffs)
<barry>    * 297547 - 2 (CC someone via email)
<barry>    * 295156 - 1 (one mail on merge proposals)
<barry>    * 297640 - 1 (quote comments in web ui)
<barry>    * 297669 - 1 (Approve a mp via email)
<barry>    * 301836 - 1 (dashboard - difficult to figure out what to do)
<barry>    * 264905 - 1 (access via launchpadlib)
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>    * Action items
<rockstar> me
<barry>    * Queue status
<barry>    * Mentoring update
<barry>      * al-maisan looking for a mentor
<barry> [TOPIC]  * Getting graphs in place before rolling out features (way before) - beuno
<MootBot> New Topic:   * Getting graphs in place before rolling out features (way before) - beuno
<barry> beuno: the floor is yours
<beuno> hello hello
<beuno> so, I sent out an email to the list about this
<beuno> and since everyone seemed on board with the idea
<beuno> I'd like to formalize it somehow for the reviews
<beuno> the main idea is to have enough information beforehand being collected, to be able to track the impact of the feature/change
<danilos> me (late)
<jtv1> me too
<abentley> beuno: I don't really get it.  What features do we graph, and how do we know what we care about?
<danilos> I wonder more about how much overhead this introduces to our development process
<bac> beuno: like abentley i'm a little confused and would benefit from a fleshed-out example.
<beuno> so, if you're going to add diffs to merge proposals, make sure we have a graph on how many merge proposals we have per day
<beuno> maybe how many comments per merge proposal
<beuno> and that we we can measure what kind of impact the feature had
<beuno> is it making users use the feature more?
<beuno> are they commenting less?
<beuno> basically enough information to be able to interpret them
<barry> beuno: i have no idea how to create graphs.  i know how to collect data i might be interested in in my db tables tho
<barry> beuno: are we basically talking about making sure we're collecting interesting usage data for our new features, or is there more to that?
<mars> abentley, a good example of a back-fill graph would the the 'Review type' feature.  Do people ever set the review type?  How often?
<flacoste> barry:  i think it's adding cricket graph
<beuno> barry, it's just opening an RT ticket with the sql query to be ran every day
<kiko-afk> hey there
<kiko-afk> can you guys ask martin through email
<jtv1> kiko-afk, you're here!
<kiko-afk> or next century
<kiko-afk> kthxbye
 * beuno closes laptop
<barry> okay!  i guess we'll continue that discussion on the ml
<mars> now *that* was a drive-by
<gmb> From now on let it be known:
<gmb> kiko is beuno's mother
<rockstar> Ha!
<barry> now that they're gone, it's time to party!
<barry> [TOPIC]  * Merge proposal bugs
<MootBot> New Topic:   * Merge proposal bugs
<barry> thanks everyone who sent me their feedback.  here are the totals so far:
<barry>    * 245257 - 5 (diffs/bundles)
<barry>    * 202000 - 3 (complete diffs)
<barry>    * 300462 - 2 (better follow up diffs)
<barry>    * 297547 - 2 (CC someone via email)
<barry>    * 295156 - 1 (one mail on merge proposals)
<barry>    * 297640 - 1 (quote comments in web ui)
<abentley> beuno: I am skepical that we'll know the right things to graph before we land the feature.  I am skeptical that it will be physically possible to create the graph before we land the feature.
<barry>    * 297669 - 1 (Approve a mp via email)
<barry>    * 301836 - 1 (dashboard - difficult to figure out what to do)
<barry>    * 264905 - 1 (access via launchpadlib)
<barry> the first number is the bug number, second is the # of people who named that bug, followed by a brief summary
<bac> bug301836 += 1
<barry> bac: i guess make that 2 :)
<barry> it's clear to me that 245257 is our top priority
<barry> 202000 and 300462 are closely related
<danilos> my idea about 297669 is similar to what 301836 will provide (i.e. if we finally start using the merge-proposal status and set it as "Approved" instead of just voting, we'd be able to see what is there that still needs to be reviewed)
<barry> does anybody have any addition comments, and then i'd like to get abentley and rockstar 's feedback
<rockstar> barry, I know MOST of those are being worked on in some form or another.
<danilos> rockstar: ok, so they'll be done by next week? ;)
 * danilos runs and hides
<rockstar> danilos, well, for some of them, yes.
<barry> rockstar: i'm off for thanksgiving weekend, so if you could land those my monday, that would be great kthxbye
<barry> :)
<rockstar> barry, but I need turkey too!
<barry> abentley: clearly 245257 is our #1 request.  any word on that?
<flacoste> barry: 300462 +1 (i didn't vote on my bug)
<abentley> barry: The general case will take a while, because we need a job processing system to accomplish it.
<barry> rockstar: http://markmail.org/message/bve73p3qumsij3he
<barry> flacoste: thanks, i'll up the tally on that one
<abentley> barry: And that was blocked by sabdfl until quite recently
<barry> abentley: ack
<abentley> barry: I am currently working on support for merge directives.  That will be able to use the diff from the merge directive.
<barry> abentley: that.  will.   rock.
<barry> abentley, rockstar do you think the team will find this list helpful?
<rockstar> barry, I know I do.
<abentley> barry: Not really.  We know all this stuff.
<rockstar> The bugs at the top I knew are important, but the ones farther down are helpful in figuring out which bugs tagged code-review are most important.
<rockstar> Because there are probably 30 bugs, and it's good to know which 10 of those are most important to the rest of the lp team.
<abentley> barry: Code review by email was intended to support attachments.  We'll need to investigate why they don't.
<barry> cool, what say i update the tallies after this meeting and send it on to the list.  maybe someone on the team can provide a feedback on a rough alignment of these with your own priorities?
<barry> abentley: thx
<barry> BjornT: what do you think?
<gmb> barry: BjornT's all sprinty with beuno, kiko and intellectronica.
<gmb> So his responses might be delayed somewhat.
<abentley> thumper is working on 295156
<flacoste> abentley: do you know they don't, i assumed they didn't but didn't try it out
<barry> gmb: k
<abentley> 297669 seems reasonable and easy
<abentley> thumper is also working on 301836
<abentley> rockstar is working on 264905
<barry> abentley: are the email commands documented in the help wiki?
<abentley> barry: yes.
 * rockstar nods
<barry> abentley: great!
<barry> anything else on this topic?
<abentley> 300462 will take even longer than a general solution for 202000, because sabdfl doesn't want us to do this for every project on launchpad.
<barry> abentley: why not?
<abentley> Instead, there will be a script you can run in an EC2 instance.
<abentley> barry: Resource consumption.
<barry> ah
<flacoste> abentley: for the record, if attachment are handled, i consider 300462 as not really worth it
<flacoste> abentley: developer are used to and can attach the diff to the follow-up email, i though attachments weren't supported
<abentley> 297547 is impossible, because sabdfl doesn't want to allow subscriptions to code reviews.
<flacoste> and thumper didn't told me they were when I discuss this aspect with him and he told me to file a general bug about that aspect
<abentley> flacoste: We intended attachments to work.  They don't.  We haven't had a chance to find out why.
<flacoste> abentley: then fixing attachment is enough for me to consider that bug complete
<abentley> I only verified it yesteday.
<abentley> flacoste: Cool
<barry> thanks everyone.  i appreciate the discussion.  i think it will make mp's really excellent to use.  moving on...
<barry> i'm going to skip around a little bit...
<barry> [TOPIC]    * Mentoring update
<MootBot> New Topic:     * Mentoring update
<barry>      * al-maisan looking for a mentor
<barry> have we rounded up a mentor for al-maisan yet?
<al-maisan> barry: yes
<barry> al-maisan: excellent, who?
<al-maisan> gmb volunteered
<al-maisan> :)
<barry> fantastic!  al-maisan welcome aboard.  gmb thanks!
<al-maisan> thanks!
 * bigjools winks at gmb and hands over the fiver
<barry> [TOPIC]    * Action items
<MootBot> New Topic:     * Action items
<gmb> Heh.
<barry>  * barry to look into techniques for eliminating back-patching of schema types (avoiding circular imports)
<barry> i have done nothing on this yet, but i plan on looking at it over the break.  i think it will be easy
<barry> [TOPIC] anything else?
<MootBot> New Topic:  anything else?
<barry> does anybody have anything not on the agenda today?
<abentley> Yes.  When am I a reviewer?
<abentley> OCR, I mean?
<rockstar> :)
<barry> abentley: ah.  what would you prefer?  i'm very happy to say we have great coverage for eu/am
<barry> abentley: i'm also happy to move if you prefer mondays
<rockstar> abentley, you get the Monday AsiaPac shift!  :)
<barry> but i think we'll be doubling up no matter what we do, unless some of us move to au/nz :)
<barry> doubling up is not a bad thing!
<abentley> I think Mondays are best for me.  But if al-maisan and gmb are doing mondays, that doesn't make sense, does it?
<gmb> abentley: Well, you start fairly late in our day.
<abentley> Fridays might also work.
<al-maisan> hmm .. different time zones
<gmb> So it's not *that* mcuh of an overlap.
<al-maisan> yep
<gmb> abentley: What's your timezone?
<abentley> On Monday, I haven't spoken to thumper for 2 days.
<mars> gmb, same as mine
<gmb> ...
<barry> abentley: i'm also happy to move to another day if you really want mondays
<gmb> mars: Which one is that?
 * gmb has the dumb
<mars> gmb, EST
<gmb> Ah, okay.
<gmb> So, abentley is al-maisan -6, gmb -5. That's not a terrible overlap.
<barry> abentley: your call.  pick a slot
<abentley> Okay.  I guess I didn't realize you were going off shift soon after I arrived.
<abentley> barry: Okay, Mondays please.
<barry> abentley: it's yours.  i'll find a time to move to
<abentley> barry: ta
<barry> cool.  any other topics for today?
<barry> 5
<abentley> barry: Is it true that we're no longer adding entries to lib/canonical/launchpad/interfaces ?
<barry> abentley: more specific imports are preferred, yes
<abentley> i.e. you should do "from canonical.launchpad.interfaces.branch import Branch"?
<barry> abentley: correct
<abentley> Okay.  What about "from canonical.launchpad.interfaces import branch"?
<barry> abentley: i have no problem with that if it helps avoid name conflicts
<barry> i.e. implements(branch.IBranch)
<abentley> barry: it helps reduce the number of imports tremendously.
<sinzui> abentley: barry: That is common practice in Zope code
<abentley> sinzui: Also in Bazaar, though both forms are accepted.
<barry> i think i'd like to see what that looks like if it's used more frequently.  i like the shorter names and don't mind the longer imports, but if you want to start using that style, let's see how it looks
<abentley> Okay.
<barry> anything else with our last 2 minutes?
<sinzui> barry: It may be a solution to the insanely long soyuz names
<barry> sinzui: that in itself would be enough! :)
<bigjools> leave our long names alone!
<barry> and with that, we're done! :)
<sinzui> It's not the size that counts, it's what you do with it.
<barry> #endmeeting
<MootBot> Meeting finished at 09:45.
<gmb> sinzui: Well placed last word on the log.
<barry> thanks everyone!  for those of you in the use.  have a happy thanksgiving
<barry> s/use/us/
<sinzui> gmb: I was trying to get that in before barry closed the meeting
<mars> thanks barry
<barry> sinzui: i was counting on a risquÃ© comment to end the meeting :)
#launchpad-meeting 2008-11-27
<matsubara> #startmeeting
<MootBot> Meeting started at 09:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> so, who's here today?
<henninge> me
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<flacoste> me
<henninge> me
<matsubara> I always forget that
<allenap> me
<salgado> me
<Ursinha> me
<matsubara> today is thanksgiving in the US, right?
<henninge> yup
<matsubara> so, no herb or mthaddon, it seems
<bigjools> me
<matsubara> all right, so let's move on. everyone is here but the US people
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> same time next week?
<henninge> I'm on leave then.
<henninge> s/'m/'ll be/
<matsubara> henninge: can you coordinate with danilos or jtv to cover up for you?
<henninge> sure
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * gmb to add sql to hide bug 297388 as a fix for bug 300324
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/297388/+text)
<ubottu> Launchpad bug 300324 in malone "Bug 297388 OOPSing because had its 0 comment deleted" [High,Triaged] https://launchpad.net/bugs/300324
 * gmb is made of fail, forgot, will do it now so that it gets done monday.
<matsubara> given that we still have a Internal server error, that wasn't done :-)
<matsubara> * ursinha to file a bug about OOPS-1055EC45 and coordinate with Registry to get it fixed
<Ursinha> I did that
<Ursinha> and gave sinzui the number
<matsubara> all right.
<matsubara> [action] gmb to add sql to hide bug 297388 as a fix for bug 300324
<MootBot> ACTION received:  gmb to add sql to hide bug 297388 as a fix for bug 300324
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/297388/+text)
<ubottu> Launchpad bug 300324 in malone "Bug 297388 OOPSing because had its 0 comment deleted" [High,Triaged] https://launchpad.net/bugs/300324
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/297388/+text)
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> Ursinha: take the stage please
<Ursinha> it's me
<allenap> Looks like +text is b0rked.
<Ursinha> thanks mars
<Ursinha> argh
<Ursinha> thanks matsubara
<matsubara> allenap: it's because the bug was deleted from the db
<Ursinha> allenap, that bug is missing its comment 0
<matsubara> or something liket that
<allenap> Ah, cool.
<Ursinha> so I explodes when somebody tries to access it
<Ursinha> ok
<matsubara> anyway, gmb is going to mark it as private so it'll only explode to lp admins
<Ursinha> I have three bugs, two for bugs and one for code
<Ursinha> let's see the code one first
<Ursinha> rockstar, hi
<Ursinha> bug 301595
<matsubara> Ursinha: rockstar is not around
<ubottu> Launchpad bug 301595 in launchpad-bazaar "OOPS when deleting a branch with revisions" [Undecided,Triaged] https://launchpad.net/bugs/301595
<Ursinha> oh, true
<Ursinha> crap
<matsubara> he's on thanksgiving holiday
<Ursinha> who's code QA contact today?
<matsubara> nobody it seems
<matsubara> move on to the bugs team
<Ursinha> okay
<Ursinha> the bugs ones
<matsubara> and I'll ask aaron to join, if he's around
<sinzui> matsubara: Ursinha: We tested a performance fix for OOPS-1055EC45. We should landed it Monday at the latests
<matsubara> thanks sinzui
<Ursinha> sinzui, great. thanks
<Ursinha> bug 296293 and bug 302253
<ubottu> Launchpad bug 296293 in malone "Trying to search through the API for bugtasks passing milestone="url" gives a 500, Internal Server Error" [Undecided,New] https://launchpad.net/bugs/296293
<ubottu> Launchpad bug 302253 in malone "NotOneError when trying to access +nominations with start > 548" [Undecided,Triaged] https://launchpad.net/bugs/302253
<Ursinha> okay
<Ursinha> gmb, are you looking 302253?
<Ursinha> oh, it's allenap
<Ursinha> ok
<Ursinha> allenap, that bug is ugly
<Ursinha> can somebody take care of that,please?
<matsubara> Ursinha: and there he is ^ :-)
<Ursinha> hi abentley
<abentley> Hi Ursinha
<Ursinha> abentley, do you know who's fixing bug 301595?
<ubottu> Launchpad bug 301595 in launchpad-bazaar "OOPS when deleting a branch with revisions" [Undecided,Triaged] https://launchpad.net/bugs/301595
<Ursinha> it needs love
<Ursinha> it's oopsing a lot and doesn't have an owner
<Ursinha> neither importance set
<abentley> Ursinha: I don't think anyone's fixing it.  I don't think anyone knows why it's broken.
<Ursinha> abentley, guess it needs to be investigated, no?
<abentley> Sure.
<flacoste> it's kind of oopsing all of the place
<bigjools> it needs someone to take ownership
<Ursinha> flacoste, yes
<flacoste> in lpnet yesterday's report, most of the OOPS were from there
<Ursinha> flacoste, exactly
<Ursinha> abentley, can you please talk to code team about that?
<abentley> Ursinha: Okay.
<Ursinha> thanks abentley
<allenap> I'll look into bug 302253 some more later.
<ubottu> Launchpad bug 302253 in malone "NotOneError when trying to access +nominations with start > 548" [Undecided,Triaged] https://launchpad.net/bugs/302253
<Ursinha> thanks allenap
<Ursinha> allenap, it would be nice if someone take a look at bug 296293 also
<ubottu> Launchpad bug 296293 in malone "Trying to search through the API for bugtasks passing milestone="url" gives a 500, Internal Server Error" [Undecided,New] https://launchpad.net/bugs/296293
<Ursinha> [action] abentley to talk to code team about bug 301595
<ubottu> Launchpad bug 301595 in launchpad-bazaar "OOPS when deleting a branch with revisions" [Undecided,Triaged] https://launchpad.net/bugs/301595
<matsubara> [action] abentley to talk to code team about bug 301595
<MootBot> ACTION received:  abentley to talk to code team about bug 301595
<Ursinha> matsubara, thanks
<Ursinha> I'll talk to intellectronica later about that bug so
<Ursinha> about +translate timeouts, jtv is handling
<Ursinha> no critical bugs
<Ursinha> so that's all from me guys
<Ursinha> thanks all
<matsubara> we have one fix committed, will that ever be released?
<matsubara> I mean, it's been fix committed for ages now
<Ursinha> matsubara, good question
<matsubara> allenap: do you know how bugzilla-launchpad bugs transition from committed to released?
<allenap> matsubara: I don't follow... are you talking about the plugin?
<matsubara> allenap: I'm talking about bug 269538 which is in fix committed for a long time
<ubottu> Launchpad bug 269538 in bugzilla-launchpad/bugzilla-3.2 "Compliation error in plugin when authenticating" [Critical,Fix committed] https://launchpad.net/bugs/269538
<matsubara> will it ever be fix released or something?
<matsubara> anyway, we can sort that out later.
<matsubara> i'll comment on the bug
<matsubara> moving on
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<matsubara> so, no losas around, they're on holiday
<allenap> gmb: Can bug 269538 be marked as Fix Released?
<ubottu> Launchpad bug 269538 in bugzilla-launchpad/bugzilla-3.2 "Compliation error in plugin when authenticating" [Critical,Fix committed] https://launchpad.net/bugs/269538
<matsubara> [action] matsubara email losas to request operations report
<MootBot> ACTION received:  matsubara email losas to request operations report
<matsubara> [TOPIC] * DBA report (DBA contact)
<MootBot> New Topic:  * DBA report (DBA contact)
<matsubara> stub is on holiday too
<matsubara> [action] matsubara email stub to request dba report
<MootBot> ACTION received:  matsubara email stub to request dba report
<matsubara> and I guess that's all we have for today
<matsubara> anything else?
<Ursinha> I do
<Ursinha> have
<matsubara> go ahead
<Ursinha> about QAing your pending test items
<gmb> allenap: Good question. I don't think so yet but I'll ping Max about it and ask him.
<matsubara> thanks gmb
<matsubara> and allenap
<Ursinha> it seems people are not QAing their items right after they land
<Ursinha> if you need help QAing stuff, let me and matsubara know, we'll be glad to help
<Ursinha> as EdwinGrubbs asked me yesterday
<Ursinha> but it would be really great if things could be tested way before release week :)
<Ursinha> so I'd like to ask you to take a look on your testplans and see what can be done
<Ursinha> that's all
<Ursinha> thanks matsubara
<matsubara> thanks Ursinha
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> weee
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:26.
<Ursinha> thanks matsubara
<henninge> thank Ursinha :)
<Ursinha> henninge, :)
<Ursinha> wgrant, too late :P
#launchpad-meeting 2009-11-25
<jtv> danilos: no meeting?
<danilos> jtv, I am not sure
<jtv> danilos: we could start going "me" in case it helps
<danilos> jtv, with summer-time changes, I am not even sure of the time anymore :)
<jtv> danilos: it's as if somebody decided, "okay, we grok the Gregorian calendar now... what else can we do to make it hard?"
 * jtv gives up
<barry> #startmeeting
<MootBot> Meeting started at 09:33. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody.  apologies for the delay.  welcome to this week's ameu reviewers meeting.  who's here today?
<sinzui> me
<henninge> me
<barry> abentley intellectronica leonardr allenap gary_poster jtv adeuring bigjools salgado-lunch noodles775 EdwinGrubbs BjornT jml danilos bac ping
<noodles775> me
<adeuring> me
<gary_poster> moi
<bigjools> me
<allenap> me
<bac> me
<danilos> me
<abentley> me
<EdwinGrubbs> me
<barry> i think this will be a short meeting since many of us were sprinting and at uds
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry>  
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica and barry to draft guidelines for drive-by cleanups
<barry> well, that one's been on the list for forever, but nothing's been done so we can carry that forward.  maybe i'll get a chance to write something up over the holiday weekend
<barry> [TOPIC]  * UI review call update
<MootBot> New Topic:   * UI review call update
<barry> EdwinGrubbs or noodles775 do you want to give a summary?
<noodles775> I think flacoste summarised it well in his email?
<barry> cool.  maybe we don't need this agenda item any more then?
<barry> noodles775: congratulations on your ui graduation.
<noodles775> Thanks! :-)
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> i'm done.  is there anything on your mind?  any thoughts from the lazr-js sprint you want to share?
<barry> okay!  then let's call it
<barry> #endmeeting
<MootBot> Meeting finished at 09:41.
<abentley> barry: thanks.
<henninge> barry: thanks
<barry> thanks everyone.  you amerikins have a happy thanksgiving weekend
<noodles775> Oh, one thing, now for next week, it'd be great to involve other teams in lazr-js reviews. :-)
<barry> noodles775: yes, excellent point.  i'll put that on the agenda for next week
<gary_poster> fwiw, mars should be involved in/lead/something discussion about lazr-js code reviews
<gary_poster> barry: ^^^
<barry> gary_poster: agreed. i'll ping him about that
<gary_poster> so that just means we need to be sure to ping him :-)
<gary_poster> thanks
#launchpad-meeting 2009-11-26
<matsubara> #startmeeting
<MootBot> Meeting started at 09:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<noodles775> moi
<matsubara> apologies from stub and Ursinha
<allenap> me
<matsubara> and gary too
<matsubara> rockstar, Chex, sinzui: hi
<matsubara> danilos, h
<matsubara> danilos, hi
<sinzui> matsubara: It is a national holiday for the US members
<danilos> me
<danilos> oh, my clock is delayed still
<matsubara> sinzui, right, I guess rockstar is not joining then. aren't you taking the holiday?
<noodles775> matsubara: ah, that's why bigjools isn't around... I forgot.
<noodles775> He took a day holiday as everyone else in the states was on holidays.
<sinzui> matsubara: I am but I happen to be here and I can answer questions
<matsubara> noodles775, I see. thanks for covering for him :-)
<matsubara> today's meeting should be quick
<matsubara> let's move on
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * Ursinha to send one email to lp list explaining the qa-tags experiment
<matsubara> * matsubara to chase someone from code team about bug 480000
<matsubara> * matsubara to chase code people about code script failures (create-merge-proposals, branch puller and update branches)
<matsubara> * matsubara to ask someone from code about bug 485318
<matsubara> * Chex to talk to thumper about the multiple git import failures on the importd
<ubottu> Launchpad bug 480000 in launchpad-code "OOPS deleting a branch" [Undecided,New] https://launchpad.net/bugs/480000
<ubottu> Launchpad bug 485318 in launchpad-foundations "POSTToNonCanonicalURL error using bazaar client" [Undecided,New] https://launchpad.net/bugs/485318
<matsubara> I didn't talk to code people about all the issues.
<matsubara> [action] * Ursinha to send one email to lp list explaining the qa-tags experiment
<MootBot> ACTION received:  * Ursinha to send one email to lp list explaining the qa-tags experiment
<matsubara> [action] * matsubara to chase someone from code team about bug 480000
<MootBot> ACTION received:  * matsubara to chase someone from code team about bug 480000
<matsubara> [action] * matsubara to chase code people about code script failures (create-merge-proposals, branch puller and update branches)
<MootBot> ACTION received:  * matsubara to chase code people about code script failures (create-merge-proposals, branch puller and update branches)
<matsubara> [action] * matsubara to ask someone from code about bug 485318
<MootBot> ACTION received:  * matsubara to ask someone from code about bug 485318
<ubottu> Launchpad bug 485318 in launchpad-foundations "POSTToNonCanonicalURL error using bazaar client" [Undecided,New] https://launchpad.net/bugs/485318
<matsubara> Chex, did you talk to thumper about the git import failures?
<Chex> matsubara: hi, I pinged him in my morning today, but we are time-zone challenged, sorry I didnt get back to him sooner on that
<matsubara> [action] Chex to follow up with thumper about the multiple git import failures on the importd
<MootBot> ACTION received:  Chex to follow up with thumper about the multiple git import failures on the importd
<matsubara> thanks Chex
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> one bug for sinzui: https://bugs.edge.launchpad.net/launchpad-registry/+bug/488762
<ubottu> Launchpad bug 488762 in launchpad-registry "SnapShot OOPS editing team with 13000 members" [High,Triaged]
<matsubara> which you already triaged
<matsubara> :-)
<sinzui> of course
<matsubara> thanks sinzui
<matsubara> and another one for danilos:  https://bugs.edge.launchpad.net/rosetta/+bug/488765
<ubottu> Launchpad bug 488765 in rosetta "OOPS accessing translations page for a source package" [Undecided,New]
<matsubara> and another OOPS-1420ED1047 for danilos which I haven't filed a bug for yet
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1420ED1047
<danilos> matsubara, looking
<matsubara> danilos, can you take a look at those and triage accordingly please?
<danilos> matsubara, sure, thanks
<matsubara> [action] matsubara to file a bug for OOPS-1420ED1047
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1420ED1047
<MootBot> ACTION received:  matsubara to file a bug for OOPS-1420ED1047
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1420ED1047
<matsubara> danilos, I'll let you know once I have a bug for that one
<matsubara> thanks danilos and sinzui
<matsubara> we have 2 critical bugs, one is fix committed and another one is in progress
<matsubara> so all good
<danilos> matsubara, I think I've seen that one already (https://lp-oops.canonical.com/oops.py/?oopsid=1420ED1047)
<matsubara> we had 2 script failures since last week
<matsubara> one in checkwatches which gmb already took care of
<matsubara> and another one in distributionmirror-prober
<matsubara> sinzui, does that one ^ belongs to registry?
<danilos> matsubara, yes, that's bug 484368
<ubottu> Launchpad bug 484368 in rosetta "LocationError: 'top_projects_and_packages_to_translate'" [High,Triaged] https://launchpad.net/bugs/484368
<matsubara> danilos, thanks
<sinzui> matsubara: I will take the mirror prober
<matsubara> [action] sinzui to investigate failure on the mirror prober (The script 'distributionmirror-prober' didn't run on 'loganberry' between 2009-11-23 06:07:04 and 2009-11-23 12:07:04 (last seen 2009-11-23 04:54:10.444057))
<MootBot> ACTION received:  sinzui to investigate failure on the mirror prober (The script 'distributionmirror-prober' didn't run on 'loganberry' between 2009-11-23 06:07:04 and 2009-11-23 12:07:04 (last seen 2009-11-23 04:54:10.444057))
<matsubara> thanks sinzui
<matsubara> I think that's all for this section
<matsubara> let's move on
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone, quick report today
<Chex> - Python 2.5 upgrade: Update on how testing is going on Python 2.5?
<Chex> - next LP rollout: Scheduled for Wed 02 Dec, 2009 at 2200 UTC.
<Chex> - LP incidents of note:
<Chex>         ; CP 8653 rolled out to loganberry and bzrsyncd
<Chex>         ; continued Codebrowse restarts
<Chex> and thats our report for today. Any questions??
<matsubara> Chex, I'm not sure about the python2.5 upgrade status. That's a question for Gary, but he's on holiday today. do you want me to chase that for you?
<Chex> matsubara: yes that would be great if you could, please
<matsubara> [action] matsubar to ask gary about python2.5 update and get back to losas
<MootBot> ACTION received:  matsubar to ask gary about python2.5 update and get back to losas
<matsubara> I can't type my own name :-(
<matsubara> thanks Chex!
<mthaddon> matsufail
<matsubara> hehe
<matsubara> Chex, btw, there's some progress regarding the codebrowser restarts. Max seems to have identified some bugs and likely some code will land soon
<matsubara> Chex, mthaddon: there is an email thread going on in the list about it if you are interested in the details
<matsubara> let's move on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> relaying for stub
<matsubara> I've got the first part of LP standalone DB working (build, configure and control a launchpad specific PostgreSQL).
<matsubara> In DB land we have some more graphs detailing database load for scripts - no surprises so far.
<matsubara> sanitized db generation is still underway. Last run was 5 days before I killed it and optimized the slow bit.
<matsubara> Staging restorations were slow due to a very inefficient restore procedure (we had to change due to production replication setup changes). This process has been optimized and a restoration currently underway.
<mthaddon> matsubara: nothing stands out from the DB user CPU usage graphs?
<mthaddon> matsubara: we're seeing a lot of load increase on wildcherry and would really like to get to the bottom of it
<matsubara> mthaddon, I haven't seen the graphs, I'm relaying the report stub sent to me. I'll pass your question on to him and ask stub to contact you. is that ok?
<mthaddon> ah right
<mthaddon> yeah, of course
<matsubara> [action] matsubara to ask stub to contact losas about load increase on wildcherry
<MootBot> ACTION received:  matsubara to ask stub to contact losas about load increase on wildcherry
<matsubara> ok, last one
<matsubara> [TOPIC] * Proposed items
<matsubara> there are no proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> which brings this meeting to an end, unless someone have any questions?
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:29.
#launchpad-meeting 2010-12-01
<bigjools> moi
<allenap> me
<leonardr> has the meeting actually started yet?
<jcsackett> i don't think so.
<bac> #startmeeting
<MootBot> Meeting started at 09:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> leonardr: it did, but in the wrong channel
<bac> who is here today?
<jtv> me
<abentley> me
<allenap> me
<leonardr> me
<jcsackett> me
<mars> me
<adeuring> me
<sinzui> me
<EdwinGrubbs> me
<benji> me
<bac> deryck and flacoste send apologies
<gary_poster> me
<bigjools> o/
<salgado> me!
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> First, let me apologize about last week.  I was on holiday and simply forgot to cancel the meeting or find someone else to lead it.
<bac> Sorry if it wasted your time.
<jtv> Aplogize?  It was fun.  :)
<bac> [topic] outstanding actions
<gary_poster> heh
<MootBot> New Topic:  outstanding actions
<bac> sinzui: any progress on the lint changes wrt Storm 'in'?
<sinzui> no
<bac> alrighty
<bac>  * bac to work with mars regarding a slow introduction of new reviewer points regarding the ArchitectureGuide.
<jelmer> me, sorry I'm late
<bac> i finally talked to mars about this today and i'm going to send an email this week announcing a plan.  we'll phase in one item at a time for reviewers to concentrate on.
<bac> hi jelmer
<bac> [topic] mentat update from salgado
<MootBot> New Topic:  mentat update from salgado
<salgado> haven't been requested to do UI reviews lately, so if you've got UI reviews, send them my way
<sinzui> He needs reviews
<sinzui> I need to stop stealing reviews
<bac> bad sinzui
<abentley> sinzui: wasn't your sig "guilty of stealing everything I am"?
<bac> yes, please let's get salgado more reviews so he can graduate and get on with life
<sinzui> I am true to my word
<bac> the same is probably true with steven and code reviews...
<bac> [topic] New stuff?
<MootBot> New Topic:  New stuff?
<bac> There are no new topics to discuss.
<sinzui> mrevell, will be starting UI review training
<bac> Does anyone have an item off agenda.
<bac> yay, mrevell!
<abentley> Yeah, I have a couple.
<bac> go, abentley
<abentley> I sent out an email about database patches needed time checking.  Did that make sense to everyone?
<abentley> I didn't get any responses, except stub telling me that the patch to show db time had been rolled back.
<jtv> Well I was wondering: what about indexing large tables?
<bac> abentley: i was confused by the state of the request given stub's reply
<jelmer> abentley: I haven't actually tried it, but it did make sense.
<abentley> Which now leaves us with a database time budget and no way to ensure we stay within it.
<bigjools> we have the staging restore time at the weekend to go on
<abentley> jtv: staging has always been used as an indicator of production for patch application time.
<abentley> jtv: The staging db is at most a month stale.
<sinzui> Yes it is surprising to see two updates in the last 4 weeks
<abentley> bigjools: We do.  but since we're merging db-stable into devel on Friday, that will only tell us if we've failed to stay within it, not act as a guide to keep us within it.
<jtv> abentley: perhaps I was unclear in some way.  I mean: indexing large tables would be likely to overrun the patch time budget.
<jtv> There's ways around that, but not really within the existing patch system AFAICS.
<gary_poster> bigjools: I believe part of the eventual intent is to make this change so that the weekend restore is no longer necessary--so that we can run that monthly, for instance.  maybe I'm wrong.
<bigjools> abentley: you might want to consider postponing that then
<bigjools> gary_poster: ack, indeed
<abentley> jtv: So, I was talking about a system whereby we get an estimate of how long a patch will take to apply.
<jtv> And I was talking about staying within the budget that creates for us.
<abentley> jtv: even indexing a large table may be in the budget.
<abentley> jtv: We would rely on the incremental db patch application times over the week, if we had those.
<abentley> jtv: I suppose we could reject any patches that index large tables.  Is that what you had in mind?
<jtv> abentley: if we had a suitable escape hatch, yes.
<bigjools> not that I don't want to talk about this, but it's drifting OT for the meeting
<abentley> bigjools: okay.
<bac> yes, thanks abentley.  follow up on the list?
<bac> abentley: you had another topic?
<abentley> bac: Hasn't worked so far..
<abentley> The other topic is the reorganization into Launchpad Squads.
<bac> abentley: ok.  review team related?
<abentley> Some teams like mine are scattered across timezones, which means we are more inclinded to use on-call reviews.  The new squads will reduce that, and could reduce the use of on-call reviews.
<jtv> The squads are also scattered, aren't they?
<abentley> Is that something we should be concerned about?  should we embrace it?
<jcsackett> will it reduce that? many of the squads look scattered.
<abentley> Orange squad looks Euro/NA
<abentley> That's less scattered than NA/NZ
<jtv> My squad is SEA/Euro/America
<bigjools> jtv: ours might change, depending on who I recruit
<jtv> â¦or fire.  Got it.
 * jtv shuts up
<abentley> Odd, I had heard that they were going to be less scattered.  Maybe I have a false premise.
<bac> abentley: i think we'll have to see how it pans out.  i don't foresee it being an issue.
<jtv> I hadn't heard anything, but looking at the teams thought they deliberately spanned multiple continents.
 * abentley yields the floor.
<sinzui> The goal is to span time zones, but limit the spread so that all the member can meet
<bac> anything else?
<bigjools> we need half a day overlap, or so
<bac> 3
<bac> 2
<bac> 1
<sinzui> jtv and jcsackett are in a predicament
<bac> #endmeeting
<MootBot> Meeting finished at 09:24.
<jtv> In terms of timezone span, yes.
<jtv> thanks bac!
<bac> thanks everyone
<jcsackett> thanks, bac.
<bigjools> sinzui: yes
<abentley> thanks bac.
<jtv> sinzui: I really hope I won't have to go back to the post-midnight meetings!
<bigjools> thanks everyone
<jcsackett> jtv: better to look at it less as a post-midnight meeting and more a pre-5am meeting. :-P
<jtv> Oh yes, that helps
<jtv> â¦
<jtv> no, I was wrong.  It doesn't.  :)
 * jcsackett laughs.
<bigjools> early to bed, early to rise, makes a man healthy, wealthy and tired
