[06:29] <tonyyarusso> https://bugs.launchpad.net/launchpad/+bug/66105
[06:30] <ubotu> Launchpad bug 66105 in launchpad "Team admin can't contact prospective member who hides e-mail addresses" [Medium,Confirmed]  https://launchpad.net/bugs/66105
[06:30] <ubotu> Launchpad bug 66105 in launchpad "Team admin can't contact prospective member who hides e-mail addresses" [Medium,Confirmed]  
[06:30] <tonyyarusso> laggy bot
[09:20] <rob> hello, just wondering what language Launchpad is predominately written in. I assume python, is that correct?
[09:21] <Hobbsee> & zope, i think
[09:21] <jtv> Correct.
[09:21] <rob> thanks :)
[09:21] <jtv> Apart from the spelling of "predominantly."  :-)
[01:05] <ubotu> New bug: #132648 in launchpad-bazaar "imports for deactivated projects should not appear on import list" [Undecided,New]  https://launchpad.net/bugs/132648
[01:42] <takdir> bzr: ERROR: Can't rename /srv/sm-ng/push-branches/00/00/13/d2/.bzr/repository/lock/cq1h9i680q.tmp to /srv/sm-ng/push-branches/00/00/13/d2/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/13/d2/.bzr/repository/lock/held already exists
[01:42] <mwhudson> ouch
[01:57] <lifeless> takdir: bzr break-lock <url you are pushing to> if, and only if you know no-one else is currently pushing there
[02:10] <takdir> thanks lifeless
[02:10] <takdir> it's work
[03:39] <Belutz> hi all
[03:39] <Belutz> what may cause this --> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/belutz/blankon/gnome-desktop/'); you may be able to use bzr upgrade
[03:41] <spiv> Belutz: That branch is in a format that does not support tags, but you are trying to do an operation that needs tag support.
[03:41] <mwhudson> what are you trying to do/?
[03:41] <spiv> Belutz: what command did you run?
[03:42] <Belutz> spiv, i did bzr tag gnome-desktop-2.19.90-0blankon1
[03:42] <spiv> Right, that's an operation that would need a format that supports tags :)
[03:42] <spiv> You can use "bzr upgrade --dirstate-tags" to upgrade the branch to a format that supports tags.
[03:43] <Belutz> spiv, only that?
[03:43] <spiv> The drawback is that it's a relatively new format.
[03:43] <spiv> So people will need bzr 0.15 or newer to use that branch.
[03:45] <spiv> IIRC, the plan is that that will be the default format in bzr 0.91, which will be released in a month or so.
[03:45] <Belutz> ah i see
[03:45] <Belutz> ok then :)
[03:50] <mtaylor> spiv: dare I ask... the jump from bzr 0.17 to 0.91 in a month? 
[03:51] <statik> mtaylor!
[03:51] <statik> it's 0.19
[03:51] <spiv> mtaylor: 0.18 was released about a month ago, 0.90 will be the next release (0.90rc1 is already out), then the next after that will be 0.91.
[03:51] <statik> no it's not, I'm behind the times
[03:51] <mtaylor> statik: you should keep up!
[03:51] <mtaylor> so I'm guessing that's to prep-for-1.0...
[03:51] <spiv> The jump to 0.90 instead of 0.19 is to reassure people that we're almost at 1.0 :)
[03:51] <statik> mtaylor: I should, I should. 
[03:52] <mtaylor> statik: maybe it would help if you got a job at canonical...
[03:52] <statik> mtaylor: I'm not talking to you for the next 5 minutes
[03:52] <mtaylor> :)
[03:53] <mtaylor> statik: actually... I just asked a question on #bzr that you might have a good opinion on
[03:53] <statik> what's that?
[03:54] <mtaylor> statik: so, if I'm going to have multiple branches of something like, one for edgy and one for feisty
[03:54] <jtv> statik: don't fall for it.  It's not been 5 minutes yet.
[03:54] <mtaylor> statik: and I want to manage it so that I can pull changes from edgy to feisty, right, so feisty is a child of edgy
[03:54] <mtaylor> statik: this all works just fine and like I would want it too
[03:55] <mtaylor> statik: but is there a sensible way to manage the debian/changelog in such a setup? 
[03:55] <mtaylor> or am I just stuck dealing with it by hand? 
[03:55] <statik> mtaylor: I've been struggling to figure out how to handle that myself
[03:56] <mtaylor> statik: well at least I'm not the only one
[03:57] <mtaylor> statik: right now I'm looking at no separate branches, just one and I change the target distro by hand before building, which seems wrong
[03:57] <mtaylor> and which won't work if I actually need substantive changes in the later distro
[03:58] <statik> mtaylor: that's what I'm doing now, but I'm a newbie to packaging. I've been wondering about generating the changelog somehow.
[03:58] <mtaylor> statik: yes. that would be nice
[03:58] <mtaylor> statik: have you found debcommit yet? 
[03:59] <statik> mtaylor: I don't really understand what overrides are yet either, but there might be some way to ignore/override the distro when you upload
[03:59] <mtaylor> ahh... that's an idea...
[03:59] <statik> mtaylor: no, haven't seen debcommit
[03:59] <mtaylor> it generates a vc changelog for you based on your debian changelog
[03:59] <mtaylor> so you just do dch
[04:00] <mtaylor> and then debcommit and  you don't have to type twice 
[04:00] <mtaylor> :)
[04:00] <statik> mtaylor: there was a recent thread related to this on launchpad-users, somebody posted an interesting dput configuration
[04:00] <statik> oh, saving typing is good
[04:00] <mtaylor> statik: cool. I'll see if I can find the thread
[04:01] <mtaylor> statik: I think it's an issue that needs more and more attention now that ubuntu has so many "live" releases out at once
[04:01] <mtaylor> because I can honestly expect to find people running anything from dapper to gutsy
[04:01] <bac> OgMaciel: good morning
[04:02] <udienzMahyuddin> hi al...
[04:02] <statik> mtaylor: right, people can reasonably be running the last LTS, the current release, or the current dev version
[04:02] <OgMaciel> morning bac! ;)
[04:02] <bac> OgMaciel: have you seen #ubuntu-northcarolina ?
[04:02] <OgMaciel> bac:  that I have not... but I've reached my 20-channels limit too  ;)
[04:03] <OgMaciel> bac: been waiting for a friend who knows someone who could lift this
[04:03] <bac> OgMaciel: well perhaps you can squeeze the loco in some time
[04:03] <OgMaciel> bac: will do
[04:05] <Hobbsee> OgMaciel: ask nalioth
[04:05] <OgMaciel> Hobbsee: thanks for the tip ;)
[04:05] <bac> kiko, statik, barry : meeting?
[04:05] <Hobbsee> OgMaciel: no problem.  
[04:05] <barry> bac: yes
[04:06] <statik> here
[04:06] <barry> me
[04:06] <kiko> me
[04:06] <barry> who's running the meeting?  BjornT?
[04:06] <kiko> barry, you.
[04:06] <bac> BjornT is gone
[04:06] <kiko> (it's always who asks)
[04:06] <bac> me
[04:06] <barry> kiko: hah!  zee power it eez all mine!
[04:07] <barry> statik, kiko, bac: okay thanks for coming.  see you next week
[04:07] <barry> oh wait
[04:07] <Hobbsee> statik: for changelogs, use dch -D RELEASENAME, iirc
[04:07] <statik> Hobbsee: thanks! that sounds promising
[04:08] <barry> == Agenda ==   * Roll call  * Next meeting  * Queue status. 
[04:08] <barry> heh
[04:08] <kiko> that was the roll call!
[04:08] <Hobbsee> statik: i believe you can also upload to ubuntu/targetrelease, in dput.cf (i think thatwas covered in a LP thread).
[04:08] <barry> do we expect anybody else?
[04:08] <Hobbsee> apologies for disrupting the meeting, as i didnt read and action the backscroll quick enough!
[04:09] <barry> no?  okay, moving on
[04:09] <kiko> barry, not salgado or jtv I suspect
[04:09] <bac> barry: i think most of the world seems to be off celebrating one thing or another today
[04:09] <bac> has jtv been recruited?
[04:09] <jtv> oh, hi
[04:10] <barry> bac: not officially afaik, though we should talk about that in a moment
[04:10] <barry> okay, next meeting.  same time and place?
[04:10] <kiko> fine by me, I'm not on vacation then.
[04:10] <statik> +1
[04:10] <barry> done.
[04:11] <barry> * Queue status
[04:11] <bac> i just counted:  22 red, 8 not red
[04:11] <statik> I have 2 in my queue now which will go out today, I can take one more for tomorrow but will be on vacation on friday 
[04:12] <barry> looks like 6 over the limit in the needs-review section
[04:12] <kiko> I have like a million
[04:12] <kiko> but I am reviewing them right now
[04:12] <kiko> so I will be finished in 4h
[04:12] <barry> oops, not over the limit. in conflict
[04:12] <kiko> SOMEBODY gave me two huge patches
[04:12] <barry> kiko: yeah, let's talk about that in a minute
[04:13] <kiko> okay.
[04:13] <barry> does anybody think they /won't/ be able to get to all their reviews in the next day or two?
[04:13] <kiko> I'll be able.
[04:13] <bac> i will
[04:13] <kiko> barry, but really, they should be done by today.
[04:14] <kiko> tomorrow and friday are already too late
[04:14] <statik> i'll be able to
[04:14] <bac> kiko: do you mean reviewed and approved today or just through the initial review?
[04:15] <kiko> bac, the latter, though we're trying hard for the former
[04:15] <barry> kiko: well, then i wonder if it's even worth me completing carlos's branch.  it's huge.  i've spent 4.5 hours on it already and i'm about 20% done.  and he's not available today so he won't even respond on it until tomorrow.  i think that makes it impossible to get into 1.1.8 and i should concentrate on things that /do/ have a possibility of making it in
[04:15] <kiko> barry, I agree. if it had been done yesterday we'd have been in better shape.
[04:15] <Kmos> how about to enable for launchpad beta testers ?
[04:15] <Kmos> we can start checking for bugs :)
[04:15] <kiko> jtv, I am really crazy mad about this massive branch. carlos knows better.
[04:16] <jtv> At least he split up the next big one...
[04:16] <barry> kiko: okay, let's move on to the items then.  huge branches
[04:16] <kiko> barry, what I meant was that if you had managed to finish reviewing yesterday it'd have been a bit better.
[04:17] <barry> kiko: yeah, but i couldn't spend 20 hours on it yesterday
[04:17] <kiko> jtv, no excuses for carlos, he's been with us long enough to know he's not meant to do that. be sure it /never/ happens again as I'm at the limit of my patience on this sort of thing
[04:17] <jtv> aye-aye, sir
[04:17] <kiko> it's just plain lack of discipline and IT DRIVES ME CRAZY
[04:17] <barry> kiko: agreed
[04:17] <kiko> okay.
[04:17] <kiko> so huge branches
[04:18] <kiko> we should have a bonfire at allhands and burn people who post branches above 1000 lines.
[04:18] <kiko> any other ideas?
[04:18] <barry> kiko, jtv: i'm going to punt this back to carlos then.  i'll send him my review so far and let's get him to split this branch up and resubmit for 1.1.9
[04:18] <kiko> maybe a symbolic burning? 
[04:18] <kiko> barry, I think splitting the branch up is going to make the problem worse
[04:18] <barry> kiko: :(
[04:18] <kiko> barry, so I think that a) it should miss 1.1.8 and b) you should finish reviewing it by early next week so he lands it early
[04:18] <kiko> barry, sorry, but mitigation at this point is going to be better
[04:19] <barry> kiko: sounds good.
[04:19] <kiko> sending carlos back to the drawing board is going to delay things even further. I'm sorry you have to run the pain of doing it but as we said it's the last time
[04:19] <barry> yep, np
[04:19] <jtv> Food for tomorrow's Translations meeting.
[04:20] <kiko> more seriously, we should have a hard limit of 1000 lines per patch
[04:20] <barry> it will take a few back-and-forths to get it into shape, so i have no problem seeing it through, but i will give higher priority to things that can actually make it into 1.1.8
[04:20] <kiko> if it goes over that, you need to a) talk to a reviewer ahead of time and make sure there is time reserved for you
[04:20] <kiko> or b) go back to the drawing board
[04:20] <kiko> and c) not plan on landing it on week 3
[04:21] <kiko> barry, agreed
[04:21] <statik> kiko: if by hard limit you mean not enforced automatically, then I'm on board with that. I wouldn't want PQM rejecting patches based on line counts because of things like sampledata that shouldn't really count against a branch
[04:21] <barry> kiko: in principle i agree (obviously).  but is 1k lines enough?  (he says with a 1500 line patch in the queue)
[04:21] <barry> statik: yes, i agree.  also removed lines shouldn't count against
[04:22] <kiko> barry, I think that any limit is arbitrary, but that there's a conway's law for patch sizes
[04:22] <bac> 1000 is a good target.  can the counter be changed to not count deletions?
[04:23] <kiko> statik, I say hard limit in that reviewers will reject as soon as they see the mess that they are being invited into.
[04:23] <kiko> not any sort of automatic process
[04:23] <barry> i'd agree on 1k lines if we don't count removals and stuff like sampledata.  that's difficult to capture automatically tho
[04:23] <kiko> bac, it's a rule-of-thumb thing, so I would prefer it be a simple measure
[04:23] <statik> I'm definitely on board then
[04:23] <kiko> so it needs to be the number that is displayed here:
[04:23] <kiko> https://devpad.canonical.com/~jamesh/pending-reviews/
[04:23] <jtv> grep -c ^+?
[04:24] <kiko> that way the reviewer can scan the list and say WTF
[04:24] <kiko> and you can convince jamesh to change the way counts are done there to get what you want
[04:24] <kiko> but it needs to be a number that you can decide upon at a glance
[04:24] <barry> kiko: yes.  and if a reviewer rejects a 1k+ line diff automatically, the author can say "but 800 of them are deletions!".  i.e. there's some back and forth negotiations and it doesn't need to be automatic
[04:24] <kiko> barry, sure, that's fine.
[04:25] <barry> +1 from me then
[04:25] <kiko> deletions are tricky though
[04:25] <kiko> because you need to actually read them to make sure he's not doing something crazy like deleting tests
[04:25] <kiko> so it's not as cheap as you're led to believe
[04:25] <barry> kiko: yes, definitely agreed
[04:25] <bac> i notice jtv's patch under the wire at 998.  good job.
[04:25] <jtv> phew
[04:25] <barry> it's like the price is right for diffs
[04:26] <jtv> kiko: didn't you ask me to merge that 998-line diff with a related branch?
[04:26] <barry> i'm fine with getting some push back from authors if they think the 1k+ charge isn't fair
[04:26] <kiko> jtv, well, the problem there is that the changes were all related and I wanted to get a general overview there. but maybe I was wrong in asking that, in hindsight
[04:27] <barry> kiko: can you send a message to the launchpad list describing the new policy?
[04:27] <kiko> barry, how about you do that? :)
[04:27] <barry> kiko: will do
[04:28] <kiko> thanks
[04:28] <barry> okay, anything else to get off y'all's chests about huge branches?
[04:28] <barry> 5
[04:28] <barry> 4
[04:28] <barry> 3
[04:28] <barry> 2
[04:28] <barry> 1
[04:28] <barry> moving on.  jtv: notes to reviewers.  you're up
[04:29] <jtv> Says it all, really.  Sometimes I need to get a message across to reviewers that does not belong in the code.
[04:29] <jtv> Examples:
[04:29] <jtv> A message saying "I'll file a bug for thix XXX when you approve the branch (doesn't make sense before then)"
[04:30] <kiko> jtv, it's okay to leave an XXX in the code with no bug number and expect the reviewer to sign off on it.
[04:30] <jtv> Or "This code flatly denied the comment above it, but the change repairs that.  No comment needed, but the diff may look weird."
[04:30] <barry> kiko: or give a TBD for the bug id in the XXX
[04:30] <kiko> barry, right.
[04:31] <kiko> jtv, I don't see an easy way of doing that beyond having per-branch comments which would not scale well to the wikipage approach we currently have.
[04:31] <bac> i don't understand why the bug can't be filed?
[04:31] <jtv> Do we have a convention for TBDs?
[04:31] <kiko> not really
[04:31] <jtv> bac: in my example, it didn't make sense to file a bug for something that was still in an unreviewed branch.
[04:31] <kiko> but anything that the reviewer wouldn't be confused with would be fine
[04:31] <barry> bac: i think jtv is saying that during the review process, the XXX bug might go away so it makes no sense to file it before the branch is approved
[04:32] <kiko> bac, what if the bug is actually not warranted? what if the XXX is a hunch? I think this is what jtv is driving towards
[04:32] <jtv> Could be, just no telling at that stage.
[04:32] <bac> ok
[04:32] <barry> jtv: i've always used XXX itself as a hint to the reviewer
[04:32] <jtv> What I had in mind was not advanced: just writing something similar to XXX in the code
[04:32] <barry> jtv: though i'd be okay with XXX REVIEWER: hey lookie here
[04:32] <kiko> do that
[04:32] <kiko> that'd be fine.
[04:32] <jtv> SteveA pointed out to me today that XXX might not be appropriate here
[04:33] <bac> jtv: and it is meant to disappear before submitting?
[04:33] <jtv> Exactly
[04:33] <kiko> look
[04:33] <kiko> I use XXXs for this
[04:33] <barry> jtv: it's a temporary XXX but we're so trained to spot those things that it's more of a marker that something needs attention, either during review or some time down the road
[04:33] <barry> kiko: yes, exactly
[04:34] <jtv> I also suggested the "XXX: REVIEWER" thing, but...
[04:34] <kiko> XXX: I am not sure about this. the problem is that getBranchesByName() can return a tuple in this specific situation and I am unsure of whether it's best to fix the callsite or the API.
[04:34] <kiko> etc
[04:34] <kiko> and the reviewer can look at that
[04:34] <kiko> XXX: REVIEWER would be fine
[04:34] <barry> kiko: agreed
[04:34] <jtv> Add to XXXPolicy?
[04:34] <bac> i'd think some of those questions might be better addressed in a call
[04:35] <kiko> sure
[04:35] <barry> yep
[04:35] <barry> jtv: yes, please do so.  feel free to communicate that to the launchpad list too
[04:35] <jtv> ok
[04:35] <barry> thanks
[04:35] <barry> anything else?
[04:35] <barry> 5
[04:35] <barry> 4
[04:35] <barry> 3
[04:35] <barry> 2
[04:35] <barry> 1
[04:36] <barry> okay, last item, which isn't on the agenda...
[04:36] <barry> graduations and new reviewers
[04:36] <barry> so we have at least two graduations pending that i know of.  kiko give me the okay and i will send out an official graduation notice
[04:37] <statik> ooh, official notices
[04:37] <barry> i think it's important to do that
[04:37] <barry> are there any other mentored reviewers that are ready for graduation?
[04:38] <bac> i don't think there are any other mentored reviewers period
[04:38] <statik> I think bac and I were the only two left, and once we graduated we were going to set up a new batch
[04:38] <barry> bac: maybe not ;)
[04:39] <barry> as for new recruits, i will send an email to launchpad-reviews asking for nominations.  then next week we can go over them and decide who to invite.  any objections?
[04:39] <statik> sounds good to me
[04:39] <bac> i'm all for more reviewers.  it's a good time in the cycle, too
[04:40] <barry> bac: agreed!
[04:40] <barry> okie dokie.  unless kiko wakes up and disagrees, i'll do both these later today.
[04:40] <barry> :)
[04:41] <barry> 5 minutes left.  is there anything else not on the agenda?
[04:41] <statik> I've got nothing
[04:41] <barry> 5
[04:41] <barry> 4
[04:41] <barry> 3
[04:41] <barry> 2
[04:41] <barry> 1
[04:41] <Hobbsee> there's a user launchpad meeting in over an hour
[04:41] <barry> cool.  meeting ends.  thanks everyone.  review, review, review!
[04:41] <bac> thanks barry!
[04:42] <statik> thanks for chairing barry
[04:42] <bac> statik: i'm working on an mpt review.  since i'll be gone tomorrow can you finalize it tomorrow?
[04:43] <kiko> gar sorry
[04:43] <statik> bac: ok
[04:43] <bac> i don't want to leave him hanging, especially given the time diff
[04:43] <kiko> my dad is leaving for australia and I had to go say bye
[04:44] <bac> statik: thanks
[04:44] <kiko> barry, bac, statik: I am happy with the resolutions above. they make sense.
[04:44] <barry> kiko: cool, thanks
[04:44] <kiko> I want to have more reviewers, but I also want to do formal reviewer training at allhands
[04:44] <statik> kiko: thanks! oh, that sounds interesting. what kind of training?
[04:45] <kiko> barry, before allhands, let's collect some 5 largish branches and comment on them but not email them out.
[04:45] <barry> kiko: great idea: a reviewer sprint.  would help even experienced reviewers level set
[04:45] <kiko> then we do these reviews live
[04:45] <kiko> and summarize things that we pointed out that might have been ignored
[04:45] <barry> kiko: would everybody review the same 5 branches then?
[04:45] <kiko> a reviewer sprint is kinda weird :)
[04:46] <kiko> barry, we'd do maybe 2 live as a group and then 3 in individual task forces
[04:46] <barry> kiko: +1.  i like it
[04:46] <kiko> like do the 2 live, point out issues that we found and the general concept behind them (for instance, checking test coverage, or questioning code placement)
[04:47] <kiko> and then do the 3 in a few 2-person groups
[04:47] <kiko> combining experienced with non-experienced reviewers
[04:47] <kiko> and at the end have the groups present their review findings
[04:47] <kiko> the branches need to be picked sort of carefully
[04:47] <kiko> so maybe pick them out while you are doing the review
[04:48] <kiko> and contact the branch author and say "hey can I hold on to this branch for the reviewer training?"
[04:48] <barry> kiko: only thing is not sending them out will have an impact on landing schedules.  where does allhands fit into the cycles?
[04:48] <barry> kiko: yep, so critical branches wouldn't be candidates
[04:49] <kiko> we /could/ send them out, but it'd more fun if we don't
[04:49] <kiko> or send them out privately to the author so they don't go crazy
[04:50] <barry> kiko: sounds good to me
[04:50] <kiko> barry, I think allhands fits in between cycles
[04:50] <kiko> so it shouldn't be too bad.
[04:50] <kiko> barry, can you help coordinate this? i want to have the idea but if you give me the execution I will drop it horrifically
[04:51] <barry> kiko: if you help remind me as we get closer, sure :)
[04:51] <kiko> barry, I'm reminding you already!
[04:51] <kiko-afk> okay, lunchtime
[04:51] <barry> ;)
[04:59] <OgMaciel> Hobbsee: ping
[04:59] <Hobbsee> OgMaciel: pong
[04:59] <OgMaciel> Hobbsee: hey, where can I grab a hold of nalioth?
[04:59] <Hobbsee> OgMaciel: #ubuntu-ops, or a query
[05:00] <Hobbsee> OgMaciel: unsure if he's around at this time of day, though
[05:00] <OgMaciel> Hobbsee: tried a whois but didn't tell me anything usefull
[05:00] <OgMaciel> Hobbsee: thanks
[05:00] <Hobbsee> OgMaciel: you're basically looking for a freenode staffer who can give them out.  nalioth's the easiest
[05:00] <OgMaciel> Hobbsee: gotcha
[05:01] <Hobbsee> OgMaciel: i'm no tsure they're a good thing, though :P
[05:01] <Hobbsee> OgMaciel: one should just learn to have less channels open
[05:01] <OgMaciel> hehe
[05:02] <OgMaciel> :P
[05:02] <Hobbsee> + the 3
[05:02] <Hobbsee> + queries
[05:07] <Hobbsee> :)
[05:07] <Hobbsee> OgMaciel: of course, you can get around it by just connecting to freenode twice
[05:07] <OgMaciel> Hobbsee: hehe
[05:08] <Hobbsee> OgMaciel: i know people who do this :)
[05:08] <OgMaciel> Hobbsee: really???  ;)
[05:09] <Hobbsee> OgMaciel: :P yep
[05:09] <mman> is the launchpad users meeting running now?
[05:09] <Hobbsee> mman: another hour
[05:09] <Hobbsee> mman: timeanddate.com
[05:10] <mman> thx
[06:00] <mrevell> Welcome to the Launchpad Users Meeting for 15th August 2007. Thank you for attending!
[06:00] <mrevell> The next half hour or so is an opportunity for Launchpad users to put their questions and suggestions to the Launchpad team.
[06:01] <mrevell> Of course, you can also use this channel and the launchpad-users mailing list at other times to talk to the Launchpad team.
[06:01] <mrevell> Let's start off with the agenda:
[06:01] <mrevell> * Introduction to the Launchpad developers are who present
[06:01] <mrevell> * Invitation to beta team
[06:02] <mrevell> * User question/issue of the week
[06:02] <mrevell> *User questions for the team
[06:02] <mrevell> * Next meeting
[06:02] <mrevell> According to the agenda, gmb, bac and jtv are members of the Launchpad team who are here specifically for the meeting but I can see that others are here too.
[06:03] <mrevell> I'd like to start by inviting you to join the Launchpad beta team. It's a great way to find out what's coming up in Launchpad and to help shape the future of Launchpad features.
[06:03] <mrevell> You can sign up at:
[06:03] <mrevell> https://launchpad.net/~launchpad-beta-testers/+members
[06:03] <mrevell> We ask two things of all beta team members:
[06:04] <mrevell> 1. That you use your real name in the profile.
[06:04] <mrevell> 2. That you promise not to discuss publicly the features you test, as they may be significantly different when they are released.
[06:04] <mrevell> If you're interested, sign up and mail feedback@launchpad.net to say you're happy with those conditions. Also, join us on the launchpad-users list at:
[06:05] <mrevell> http://lists.ubuntu.com/mailman/listinfo/launchpad-users
[06:05] <popey> when do beta memberships expire?
[06:06] <mrevell> popey: There isn't a set time for expiry.
[06:06] <Hobbsee> mrevell: can i ask why they're requiring real names?
[06:06] <mrevell> popey: In the future, we may review the beta team and decide we need something different, but right now it's indefinite
[06:06] <mrevell> Hobbsee: Sure.
[06:06] <mrevell> Hobbsee: There are two reasons:
[06:07] <mrevell> 1. A simple practical matter: we email members of the beta team when there's something new to test. Our script says, "Hi <first name" and so works better if the person uses a first-name last-name as their display name.
[06:08] <mrevell> 2. We're asking people not to discuss features publicly and so we're entering a trust relationship. We prefer to enter such a relationship with someone using their real name, than a pseudonym.
[06:09] <mrevell> Any other questions re beta team?
[06:09] <Hobbsee> mrevell: right
[06:09] <mman> how do I see what features are being worked on in order to decide whether I want to become a beta tester?
[06:10] <jtv> You can look at the Launchpad pages on Launchpad.
[06:10] <jtv> You'll find milestones there, with bugs and specs assigned to each.
[06:10] <Hobbsee> but the specs are not viewable to the public
[06:10] <mrevell> thanks jtv.
[06:11] <mrevell> mman: However, I'll look into the possibility of putting a list on the help wiki.
[06:11] <mrevell> mman: Right now, one of the main features we're testing is Private Package Archives.
[06:11] <mman> mrevell: ok
[06:12] <mman> mrevell, jtv: thx
[06:12] <mrevell> Okay, unless anyone has further questions, or feels that their existing question hasn't been answered, I'll move on.
[06:12] <mrevell> 5
[06:12] <mrevell> 4
[06:12] <mrevell> 3
[06:12] <mrevell> 2
[06:12] <mrevell> 1
[06:12] <mrevell> Ok
[06:12] <mrevell> Top user issue.
[06:12] <mman> milestone/series management for another distro
[06:12] <mrevell> Each week, I present to the Launchpad team an issue that has been bugging one or more Launchpad users recently.
[06:14] <mrevell> mman: Thanks, let's come to that in the next part of the meeting.
[06:14] <mrevell> mman: :) NP
[06:14] <mrevell> Last week, I told the Launchpad team that Hobbsee and others had noticed an increase in timeouts. This sort of information is really important to the team and ensures that we can offer you a better service.
[06:15] <mrevell> So, if you have an issue - anything that has concerned or annoyed you about Launchpad - you can tell me now or
[06:15] <mrevell> email feedback@launchpad.net.
[06:15] <mrevell> Our developer meetings are here at 14.00 UTC each Thursday.
[06:15] <mrevell> So, try to let me know before then.
[06:15] <nathansamson> mrevell: launchpad doesn't offer webpage hosting (with or without php or somethin) is this planned?
[06:16] <mrevell> nathansamson: Thanks for the question. I'd like to deal with that in the next part of the meeting, dedicated to user questions.
[06:16] <nathansamson> k
[06:16] <mrevell> Does anyone have an issue with Launchpad as it is now, that they'd like to raise?
[06:16] <nathansamson> I thought mine was an issue
[06:17] <nathansamson> (for me it is ;))
[06:17] <mrevell> nathansamson: Okay, no problem :) I'll be happy to raise it with the Launchpad team as a feature request.
[06:17] <mrevell> nathansamson: Is this something that prevents you from using Launchpad to host a project?
[06:18] <nathansamson> no, I found hosting now for my project (pystrago) but I found it strange it doesn't offer it
[06:18] <Hobbsee> user affecting issue:  speed bzr up, make sure it actually works with the rest of the distro.
[06:18] <Hobbsee> there is no way a bunch of text files should be 14.5mb
[06:18] <Hobbsee> :)
[06:19] <mrevell> nathansamson: Thanks. I'll pass it onto the team and see what plans we have. I'll post a reply, when I have some info, on the launchpad-users list.
[06:20] <nathansamson> k
[06:20] <Hobbsee> although i guess that's technically bzr rather than launchpad
[06:20] <mrevell> Hobbsee: Bazaar has made great speed improvements over the past months and the guys are working hard to ensure that it continues to see speed improvements. Not sure what you mean about working the distro. As you say, it's more a bzr question.
[06:21] <Hobbsee> mrevell: stuff like bzr-builddeb actually working.  making using bzr being more of a help than a hindrance.  etc
[06:21] <Hobbsee> (usually dies with unrepresentable changes to source, for a package with an orig.tar.gz)
[06:22] <mrevell> Hobbsee: Thanks for the clarification. I'll leave that here, if you don't mind, as it's a Bazaar question.
[06:22] <Hobbsee> mrevell: no problem
[06:22] <mrevell> Let's move onto user questions. I'll take those on the agenda first, then open up to questions from anyone else.
[06:22] <mrevell> First up:
[06:22] <Hobbsee> mrevell: to be honest, i'm finding it a little hard to figure out what you're wanting here.  and i suspect that's why we're getting so little response
[06:22] <mrevell> Hobbsee: Ah, I'm sorry that I haven't been clear.
[06:23] <mman> series/milestone management for other distros....
[06:23] <mrevell> Hobbsee: Let me try to do a better job of explaining.
[06:23] <Hobbsee> mrevell: for next time.  feel free to go ahead with the meeting :)
[06:23] <mrevell> Hobbsee: I'll have a go now :)
[06:23] <Hobbsee> whichever :)
[06:24] <mrevell> As a Launchpad user, you may come across a bug or even a feature that makes it harder for you to work with Launchpad.
[06:24] <mrevell> Even if you've reported the problem as a bug, it can be helpful for the Launchpad team to know what in particular is causing pain to people who use Launchpad.
[06:25] <mrevell> One good example is the text size used on Launchpad. This was filed as a bug but also people raised it as an issue with me and I was able to raise it directly with the Launchpad developers in the weekly development meeting.
[06:26] <mrevell> By highlighting the issue in this way, discussion happened in the dev meeting and the team were able to see that it was something that affected users more than some other bugs that had been reported.
[06:26] <Hobbsee> so it's effectively a "i want to raise $mypetbug, which i also think is important for multiple people"
[06:26] <mrevell> Hobbsee: Essentially, yes. With any evidence to back up that it affects multiple people as a bonus.
[06:26] <Hobbsee> cool
[06:27] <mrevell> As time's moving on, please email me if you want to highlight such a problem. feedback@launchpad.net.
[06:27] <mrevell> Okay, the first question I'll take is on the wiki:
[06:27] <mrevell> So long to do a little fix - Make suggestions from should use prefered user settings
[06:27] <jtv> That's one of mine.
[06:27] <mrevell> I think this comes from Marco Rodrigues. Thanks jtv
[06:27] <jtv> That is, it's an item I'm working on.
[06:28] <jtv> It's a good question.  That particular bug was filed before I even joined the company.
[06:28] <jtv> So why _does_ it take so long?  I see several reasons:
[06:28] <Hobbsee> Kmos: ^
[06:29] <jtv> The first is that it's a small team (was 2 people, now 3) and there are many things to do.
[06:29] <Kmos> Hobbsee: :)
[06:29] <Hobbsee> :)
[06:29] <jtv> And that means that doing one thing first means that another thing waits, even if we think it's important or we'd love to get it done today.
[06:30] <jtv> As for this particular bug, actually making a drop-down menu do what makes sense is the easy part.
[06:30] <Kmos> jtv: it was a filter now in translation for languages we want to see translations, it will be easily applied to the combo box
[06:31] <Kmos> i think :)
[06:31] <Kmos> but it can waits.. isn't urgent
[06:31] <Kmos> just want to know the reasons, thanks
[06:31] <jtv> Kmos: I was about to give you another one.  :)
[06:31] <mrevell> please go ahead jtv :)
[06:32] <jtv> The hard parts of this particular bug are: fitting the change into the existing framework;
[06:32] <jtv> doing it in the proper way so we can keep maintaining it in the future;
[06:32] <jtv> making sure it's all well-tested;
[06:32] <Kmos> :)
[06:32] <jtv> and perhaps most of all, going through all the existing tests that the change will break, and making sure there's no unwanted breakage among them.  :-)
[06:33] <Kmos> jtv: ok, i'm clarified now
[06:33] <jtv> It's no Herculean effort, it all just adds up!
[06:33] <Kmos> it should wait :)
[06:33] <jtv> Kmos: I'm already on it. :)
[06:33] <Kmos> nice
[06:33] <mrevell> Thank you for your answer jtv and for the question Kmos!
[06:33] <jtv> np
[06:33] <mrevell> Okay, next up another wiki one:
[06:34] <Kmos> np
[06:34] <mrevell> When remove an attachment, remove also the comment entry - this yours too Kmos?
[06:34] <Kmos> mrevell: yes
[06:34] <mrevell> gmb: I think this is one you were going to speak about it.
[06:34] <gmb> Indeed.
[06:35] <Kmos> graham as assigned it today
[06:35] <gmb> This doesn't look to be a huge issue to fix, work wise. It's more that with a lot of big changes going on recently in the bug tracker it just hasn't been picked up by anyone.
[06:35] <gmb> Kmos: Yes.
[06:35] <Kmos> so it's nice for me, to see someone is working on it
[06:35] <gmb> Luckily I have time to spare in the next cycle :)
[06:35] <gmb> So I've targeted it for the release after this one.
[06:35] <Kmos> gmb: thanks
[06:36] <gmb> Kmos: No problem.
[06:36] <Kmos> mrevell: you can continue.
[06:36] <mrevell> Kmos: Thanks :) And thank you gmb
[06:36] <mrevell> Is there any plan for tightening the relationship between launchpad translations and upstream? (mikel)
[06:38] <mrevell> mikel I'll see if I can get an answer to your question for the launchpad-users list.
[06:38] <mrevell> The next question from the wiki is:
[06:38] <mrevell> Launchpad is similar to some of the distributed enterprise systems I've worked on over the years. Just wondering if the design is publicly documented anywhere? (jamesstansell)
[06:40] <Rinchen> Greetings
[06:40] <mrevell> jamesstansell: Thanks for your question. As far as I know, the overall design of Launchpad is not publicly documented in one place. However, we use the Launchpad blueprint tracker to plan our work and so you can get an idea from the blueprints.
[06:40] <mrevell> Rinchen: Thanks for joining us. jamesstansell asks if Launchpad's design is publicly documented.
[06:41] <Rinchen> The design documentation has not been completely release at this point. This is due to several factors.
[06:42] <Rinchen> The basic design can be inferred from the launchpad-suite project
[06:42] <Rinchen> https://launchpad.net/launchpad-project
[06:43] <Rinchen> If you were to inspect the front page project listing, that will give you an idea of the components / projects that make up Launchpad
[06:43] <Rinchen> mrevell, this might be a good item to take away 
[06:43] <Rinchen> mrevell, we should think about how better to represent this to the community
[09:06] <ubotu> New bug: #132759 in launchpad "Ability to sort bugs by summary, package, status" [Undecided,New]  https://launchpad.net/bugs/132759
[09:17] <tck> aloha
[09:17] <tck> any launchpad admins here ?
[09:23] <kiko_> tck, yes, but I hope mthaddon can help you instead. :)
[09:24] <tck> https://bugs.launchpad.net/loco-webhosting/+bug/129773
[09:24] <mthaddon> tck: what do you need?
[09:24] <ubotu> Launchpad bug 129773 in loco-webhosting "Change of team leader for Irish Ubuntu Team" [Undecided,In progress]  
[09:24] <tck> its a bit of a mess, i was speaking with nick ali
[09:24] <tck> and he said to ask in here
[09:24] <mthaddon> kiko_, is it jono that needs to approve that?
[09:28] <kiko_> mthaddon, yes.
[09:28] <mthaddon> kiko_, I'll comment on the bug and assign it to jono - once that's approved, I can take care of it, tck
[09:29] <tck> cool, thank you mthaddon kiko_ 
[09:29] <mthaddon> np
[10:00] <ubotu> New bug: #132771 in launchpad-answers "Switch question enums from dbschema to lazr" [Medium,Fix committed]  https://launchpad.net/bugs/132771
[11:06] <ubotu> New bug: #132784 in launchpad "XMLRPC tests could be more helpful when errors occur" [Undecided,New]  https://launchpad.net/bugs/132784
[11:08] <harrisony> Damn slept in my alarm for the LP meeting :(
[11:45] <mdke> can lp be used as a shared repository for bzr? I've been reading about how it's possible to keep revision history on a central server, presumably that improves speed dramatically
[12:12] <Rinchen> thumper, ^^