[01:02] <LarstiQ> kiko: hmm, what about subsections of bugtrackers, are they possible too?
[01:03] <kiko> LarstiQ, what do you mean?
[01:06] <LarstiQ> reacting on your bugtracker mail to l-u
[01:06] <LarstiQ> kiko: registering that a certain product uses a bugtracker
[01:07] <LarstiQ> hmja
[01:07] <kiko> LarstiQ, yes, I realize, but what do you mean by "subsections of bugtrackers"? :)
[01:08] <LarstiQ> kiko: bugs.debian.org/package, but I guess the bugnamespace is the same regardeless
[01:08] <kiko> LarstiQ, right. that's the main thing -- that IDs are unique over it. note that Bugzilla has the same sort of concept (product/component) but the bug ID is unique throughout
[01:09] <LarstiQ> kiko: for some reason I keep thinking of wikis with subpages, but I'm not aware of a bts using that
[01:09] <kiko> :)
[01:09] <LarstiQ> so just disregard that question then :)
[01:09] <LarstiQ> how about distributed ones though? :)
[01:09] <LarstiQ> like Bugs Everywhere
[01:10] <bradb> BjornT: ping
[01:10] <kiko> heh
[01:53] <kiko> jamesh, where are you going to post that blog post?
[01:56] <bradb> kiko: drive-by for bug 56618?
[01:56] <Ubugtu> Malone bug 56618 in malone "Milestone restrictions are too restrictive for Ubuntu" [Critical,In progress]  https://launchpad.net/bugs/56618
[01:56] <kiko> bradb, argh, not tonight, i've been at the wheel for 10h
[01:56] <bradb> ok, can i give you a url for now?
[01:57] <sabdfl> bradb: i'll take it
[01:57] <bradb> https://sodium.ubuntu.com/~andrew/paste/fileEHhd0F.html . first come, first serve!
[01:58] <sabdfl> on me, then
[01:58] <bradb> woohoo
[01:59] <sabdfl> bradb: do you know about launchpad.Drivers?
[02:00] <bradb> sabdfl: I know about the drivers attribute on IDistribution and IProduct. I don't know what exactly launchpad.Drivers refers to.
[02:00] <sabdfl> launchpad.Drivers is a permission, like launchpad.Edit, which a person can have on a series or distrorelease
[02:00] <sabdfl> it means "i can target work to this puppy"
[02:00] <bradb> ah
[02:00] <sabdfl> "i can drive the goals and bugs"
[02:01] <sabdfl> so when you are doing nomination and approval of bugs to distrorelease/series, please use launchpad.Drivers
[02:01] <bradb> noted
[02:02] <sabdfl> and in this case, use launchpad.Drivers on milestone.productseries or milestone.distrorelease
[02:02] <sabdfl> however, please file a bug that this is only temporary
[02:02] <sabdfl> once you have nomination and approval of bugs for series/distroreleases, drop restrictions on milestone targeting
[02:03] <bradb> ok
[02:04] <sabdfl> you'll need to add a test that the driver can do this
[02:04] <bradb> right
[02:04] <sabdfl> you may want to discuss with kiko if you should s/bugcontact/driver/, or just add driver as well
[02:04] <sabdfl> subscribe me to the bug, and then r=sabdfl
[02:05] <sabdfl> i like the fact that we're starting to do conditionally-editable form fields, btw, nice work
[02:05] <sabdfl> we need to generalise that so it's less of a behind the scenes hack
[02:05] <sabdfl> will you work with the LAZR team on how it should feel, as a developer?
[02:05] <bradb> sabdfl: I thought that, using launchpad.Driver permission, would mean including the bugcontact in the checker?
[02:06] <bradb> sabdfl: sure, that'd be cool
[02:06] <kiko> bradb, sabdfl: well, I think in this case it should really be bugcontact, as that's what has been explicitly requested and which will make sense.
[02:06] <sabdfl> bugcontact should not have launchpad.Driver
[02:06] <kiko> I think it's no /problem/ to make it drivers as well but that will be pretty obscure
[02:06] <kiko> agreed entirely on that
[02:06] <bradb> oh, that is indeed a conflict then with what the bug report asked for
[02:06] <sabdfl> kiko: really? was that not requested before mdz understood the drivers?
[02:07] <sabdfl> is it not trivial for him to get it right on his side?
[02:07] <sabdfl> why entrench the wrong thing in the code, just because of that request?
[02:07] <kiko> sabdfl, mdz didn't update the bug report, nor did he request us change the rationale, so...
[02:07] <kiko> I'm not sure it's actually wrong, though
[02:07] <sabdfl> bugcontact is not "i decide when work gets done", is it?
[02:08] <kiko> sabdfl, it's currently "I decide what importance something has". 
[02:08] <kiko> which is a group that is good enough for mdz right now
[02:08] <sabdfl> we need to have a formal approach to "new roles on objects"
[02:08] <kiko> hah, agreed entirely
[02:08] <sabdfl> it's not good enough for me, i'm afraid
[02:08] <sabdfl> i don't want to entrench things that are not right
[02:08] <sabdfl> i'd rather fix them
[02:09] <sabdfl> bug contact is bug contact, drivers is a role that determines priorities and go/no-go
[02:09] <sabdfl> that's well defined, and there's lots of code that uses it consistently that way in blueprint
[02:09] <kiko> well...
[02:09] <sabdfl> it's straightforward to get it right, now, in malone
[02:09] <bradb> at worst, they could add the team that is the bug contact to the drivers team in the UI, if that's how they feel their configuration should be
[02:09] <sabdfl> yes, exactly
[02:10] <kiko> sabdfl, my criticism of this is that when you added drivers you did it without explicitly saying that this is what we should use drivers for, which has lead to this problem. so I guess I am agreeing with you that yes, we should be a lot more careful, open and broad about new role creation process.
[02:10] <kiko> if we want to go ahead and start using drivers for this now
[02:10] <lifeless> ddaa: did you copy and paste an existing branch on pending-reviews ?
[02:10] <sabdfl> kiko: that's not true, i'm afraid, we discussed drivers in the docklands at some length
[02:11] <kiko> then I think we should do it properly, announce it in the meeting, post to the launchpad mailing list, and get people to agree to do it on their behalf
[02:11] <kiko> it may have been discussed. it was never posted to the list, nor is there any paper trail of the new role
[02:11] <ddaa> lifeless: no, I cut it from work-in-progress and pasted it in pending-reviews
[02:11] <kiko> and without a paper trail, we all forget 
[02:11] <lifeless> ok
[02:11] <lifeless> cool
[02:11] <ddaa> lifeless: I should reset the date when I do that?
[02:11] <kiko> and there is no way to bind people together around what we need to do
[02:11] <lifeless> review team are going to go 'whoa' today
[02:11] <lifeless> 5 new reviews 
[02:12] <sabdfl> https://sodium.ubuntu.com/~andrew/paste/fileHm1pQb.html
[02:12] <sabdfl> kiko: ^
[02:12] <ddaa> I've got another 1800 lines monster almost finished.
[02:12] <lifeless> ddaa: if you can make them smaller, but more frequent, I'm sure that would be appreciated
[02:12] <ddaa> I want to keep my reviewers busy while I'm away :)
[02:12] <sabdfl> there was also extensive discussion between stevea and myself about the new permission
[02:12] <kiko> sabdfl, that's not developer consensus, though
[02:12] <kiko> I agree it's in our codebase
[02:12] <ddaa> lifeless: in try usually, but in the case of those patches, it was not really possible
[02:12] <kiko> but that fact that it's in there and some developers don't know they are meant to use it
[02:12] <ddaa> that was just two important, large, and hard to split features
[02:12] <kiko> means we didn't take a good approach to defining and using the new role
[02:13] <kiko> I feel very strongly about this! I hate to find things out through landings!
[02:13] <kiko> and I'm also zzz tired
[02:13] <sabdfl> come on, kiko, we discussed it AT LENGTH in the docklands, and it's very well documented
[02:13] <ddaa> lifeless: one in making branch/+edit not suck anymore, the other is basically adding a new component in importd.
[02:14] <bradb> (sabdfl: i subscribed you to bug 56650)
[02:14] <Ubugtu> Malone bug 56650 in malone "Restrictions on milestone editing should be dropped when release management has rolled out" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56650
[02:15] <lifeless> ddaa: they've been assigned ot reviewers now
[02:15] <ddaa> I'll ping you for the new one if I finish it before leaving
[02:16] <bradb> kiko, sabdfl: please confirm whether this fix should change to use launchpad.Drivers or remain as is, when you're ready
[02:26] <kiko> bradb, if we are to use drivers, then use it for both importance and milestone, and make sure you write email to mdz explaining the setup of drivers to him. I can do it for him if he likes once he is aware of how it should work. meanwhile, I'll add a note to next week's rollout report.
[02:26] <bradb> kiko: will do
[02:27] <kiko> actually
[02:27] <kiko> grumble
[02:27] <bradb> ?
[02:27] <kiko> bradb, I'm not sure if drivers makes all the sense for importance. this is annoying.
[02:27] <bradb> i think drivers needs an unambiguous name
[02:28] <kiko> I can call matt, give me a moment
[02:28] <bradb> if we were saying release_managers, i'd know what we were talking about
[02:28] <kiko> yeah, could be.
[02:30] <sabdfl> bradb: didn't use release_manager because that will be used for tarballs / cd images
[02:30] <LarstiQ> or are ems a d-inq has them: http://liw.iki.fi/liw/log/2006-08.html#20060816b
[02:30] <sabdfl> so you can have a team that can settle on the goals for Python 2.4.x, but only a small team can upload tarballs
[02:31] <bradb> sabdfl: though we've been using release management to describe targeting bugs to things
[02:31] <sabdfl> yes
[02:32] <bradb> my concern is that "drivers" doesn't seem to clearly communicate a group of people that, among other things perhaps, target bugs to things
[02:32] <sabdfl>     driver = Choice(
[02:32] <sabdfl>         title=_("Driver"),
[02:32] <sabdfl>         description=_(
[02:32] <sabdfl>             "The person or team responsible for decisions about features "
[02:32] <sabdfl>             "and bugs that will be targeted to this release of the "
[02:32] <sabdfl>             "distribution."),
[02:32] <sabdfl> pretty clear on the web form, though ;-)
[02:32] <bradb> sabdfl: on the web form is says "Driver": https://launchpad.net/distros/ubuntu
[02:33] <bradb> well, web page
[02:33] <bradb> where people would most likely first encounter that term
[02:33] <sabdfl> i don't mind if we come up with a better name. that name comes from a couple of projects, like mozilla, that are big enough to do this professionally
[02:33] <mdz> my only concern is that the development team be able to set milestones on bugs and NOT to create new releases of the distro, change its name and things of that nature
[02:33] <sabdfl> that's why we don't use launchpad.Edit
[02:34] <mdz> I don't care what role is used for it so long as it isn't overloaded with ridiculous privileges
[02:34] <sabdfl> we have a distinct permission
[02:34] <sabdfl> it was specifically created to deal with this
[02:34] <kiko> mdz, what of other things that the drivers can do, such as targeting specs to releases? and targeting bugs to releases?
[02:34] <mdz> it is logical to me for it to be a QA role but I am not interested in arguing, only in fixing the problem
[02:34] <mdz> kiko: don't care
[02:34] <sabdfl> kiko: backport commitments
[02:34] <kiko> right
[02:34] <bradb> release_planners
[02:34] <mdz> I will gladly pay that price
[02:35] <sabdfl> please, let's stick with drivers till we can have a face to face on it
[02:35] <kiko> mdz, perhaps you could explain how you importance and milestone are managed to make it clearer
[02:35] <kiko> s/how you/how your/
[02:35] <LarstiQ> bradb: well, I see drivers as the driving force for direction
[02:35] <kiko> LarstiQ, bradb: [ot]  for now
[02:36] <mdz> kiko: I am not interested in arguing about what i think is the correct solution.  that is a losing battle
[02:36] <mdz> at this point I only care about fixing the bug
[02:36] <mdz> removing the access control entirely is 100% OK with me
[02:36] <mdz> in order to fix the immediate problem
[02:36] <mdz> would that avoid this discussion?
[02:37] <bradb> removing it entirely would be easiest
[02:37] <bradb> and i could close a bug :P
[02:37] <sabdfl> mdz: you'll have a zillion bugs targeted to edgy before you know it
[02:37] <kiko> mdz, one question: is the bug that the bug /assignee/ cannot set the milestone?
[02:37] <mdz> sabdfl: it will be less work for me to fix those by hand than to argue this
[02:38] <mdz> kiko: no. the bug is that the development team cannot set the milestone
[02:38] <sabdfl> can i make a proposal?
[02:38] <kiko> aha.
[02:38] <mdz> as written in the bug report
[02:38] <kiko> I just wanted to disambiguate.
[02:38] <sabdfl> mdz: do you want anyone in the distro team to be able to set the importance and milestone on ANY bug?
[02:38] <sabdfl> or just on the bugs they are assigned?
[02:38] <mdz> sabdfl: absolutely yes
[02:38] <mdz> to the first question
[02:38] <kiko> on any distro bug, yes, that's what he just said.
[02:39] <sabdfl> ok, then make them drivers
[02:39] <sabdfl> on edgy, not dapper
[02:40] <mdz> done
[02:40] <bradb> hm, will using launchpad.Driver mean a project can't do release management if they don't have a driver set?
[02:40] <mdz> I can't test whether the problem is fixed now though
[02:40] <mdz> er, now there are two drivers. how do I remove the old one?
[02:40] <kiko> bradb, we fall back to the owner.
[02:40] <sabdfl> bradb: no, it falls back to the distro/product/project owner
[02:40] <bradb> ok, cool
[02:40] <sabdfl> yes ;-)
[02:40] <sabdfl> one trick
[02:40] <sabdfl> there is a distro/distrorelease attribute ".driver"
[02:41] <sabdfl> don't use that
[02:41] <mdz> sabdfl: how do I remove a driver from the list?
[02:41] <bradb> i can check_permission launchpad.Driver easily enough
[02:41] <sabdfl> use "for driver in distrorelease.drivers: if user.inTeam(driver) return True"
[02:41] <sabdfl> bradb: yes, that will do that correctly
[02:41] <sabdfl> mdz: you can only set a single driver on the distro, and another one on the release, the "drivers" are the union of those two
[02:42] <mdz> oh
[02:42] <sabdfl> use a team if you want more control
[02:42] <mdz> the display is a bit confusing
[02:42] <sabdfl> that it is, yes
[02:42] <mdz> it said Ubuntu Drivers before, and now it says Ubuntu Drivers and Ubuntu Core Development Team
[02:42] <kiko> sabdfl, what distrorelease, exactly? 
[02:42] <mdz> which made me think it was a set
[02:42] <sabdfl> i recommend a small team on distro (you and core, trusted folks) and then a bigger team on the current dev release
[02:42] <kiko> bradb, check_permission on what?
[02:43] <sabdfl> on stable releases, use a tight backport-oriented team, like [pitti, kees] 
[02:43] <kiko> bradb, on IBugTask.target?
[02:43] <sabdfl> bugtask.target
[02:43] <kiko> sabdfl, well, he will need to add the security wrappers then
[02:43] <bradb> that can be a distributionsourcepackage though too...will that work?
[02:43] <sabdfl> hmm... no
[02:43] <kiko> because there is none for Distribution or DSP.
[02:44] <bradb> i was thinking distrorelease, distribution, product, in that order
[02:44] <sabdfl> mdz: did you set a driver on the Distro?
[02:44] <bradb> (and productseries, when i land that support with RM)
[02:44] <LarstiQ> if drivers is set, is the registrant no longer allowed to drive? Or should it also be displayed in the union?
[02:44] <mdz> sabdfl: I did not
[02:45] <kiko> LarstiQ, it's a union. the display of drivers needs to be really clarified. it doesn't really fit in a portlet I think
[02:45] <mdz> I don't know what that will do and have no immediate problem to solve by doing so
[02:45] <sabdfl> cute
[02:45] <sabdfl> LarstiQ: the registrant is responsible until (s)he delegates this to a driver
[02:46] <sabdfl> if the registrant wants to stay in that loop (s)he can be on the team set as a driver
[02:46] <LarstiQ> sabdfl: so the display is correct, but the intent wasn't clear. ok.
[02:47] <sabdfl> mdz: setting a driver on the distro will allow that team to driver ANY release
[02:47] <sabdfl> so keep it tight
[02:47] <bradb> sabdfl, kiko-zzz: so, launchpad.Driver for both importance and milestone?
[02:47] <mdz> I have no reason to set one
[02:47] <kiko-zzz> bradb, even if you add the security wrapper I don't see how that will work
[02:47] <kiko-zzz> well
[02:47] <sabdfl> mdz: you have an implicit one in the Distro.owner anyhow, which is the techboard
[02:48] <kiko-zzz> unless mdz sets the drivers of the distribution to be his dev team
[02:48] <mdz> one day it would be nice to have a document explaining the privileges associated with these various roles
[02:48] <kiko-zzz> instead of a document it might be better if launchpad itself made it clear in the UI
[02:48] <mdz> is there any way I can test whether the original problem is fixed?
[02:48] <sabdfl> kiko-zzz: mdz has set an edgy driver, and the ubuntu tech board is included too, since they are the owner of the distro and there is no distro driver set
[02:48] <kiko-zzz> sabdfl, but seb128 isn't on the tech board
[02:49] <kiko-zzz> and these bugs are on a distro, not on a distrorelease
[02:49] <sabdfl> https://help.launchpad.net/BlueprintRoles
[02:49] <bradb> mdz: not tonight, unfortunately. the patch is still being cooked.
[02:49] <sabdfl> see "Project drivers"
[02:49] <kiko-zzz> so launchpad.Driver(distribution) won't work..
[02:49] <mdz> bradb: ???!!!
[02:49] <mdz> I was told to do this in order to solve my problem
[02:49] <sabdfl> kiko-zzz: hence, i'm suggesting that mdz set a driver on the distro
[02:49] <sabdfl> but seb128 is in core-dev, which is now the edgy driver
[02:49] <kiko-zzz> sabdfl, right, I missed that then
[02:50] <kiko-zzz> sabdfl, but even being the edgy driver, will that give them launchpad.Driver on the distribution?
[02:50] <mdz> does the distrorelease driver have permission to set milestones on bugs, now, in production, or do we still need a patch?
[02:50] <sabdfl> kiko, mdz: see that doc, it explains it in some detail
[02:50] <sabdfl> you still need a patch
[02:50] <mdz> sigh
[02:51] <bradb> the only way to solve is tonight is mess with owners
[02:51] <mdz> how about if I add everyone to techboard instead?
[02:51] <mdz> I think that would fix it
[02:51] <sabdfl> that would work, yes
[02:51] <kiko-zzz> sabdfl, did you answer that question I posted above?
[02:52] <sabdfl> (given what i understand of the code, from reviewing the patch to fix it :-))
[02:52] <sabdfl> kiko-zzz: sorry, no, it won't
[02:52] <sabdfl> just on the release
[02:52] <bradb> mdz: you can even set up your drivers team correctly, then add that to the owner team
[02:52] <mdz> what I am after is a way to address the problem without a) getting bogged down in an extended discussion about the roles, which seems unlikely to be resolved today, or b) granting seriously dangerous privileges to anyone who shouldn' t have them
[02:52] <kiko-zzz> sabdfl, so that doesn't solve our problem, does it?
[02:52] <sabdfl> mdz: add core-dev to techboard
[02:53] <mdz> sabdfl: what privileges do I grant them by doing that, apart from setting milestones on bugs?
[02:53] <sabdfl> it will work for tonight, bradb will land a patch that uses drivers, and then make sure core-dev is in whatever you set as an edgy driver
[02:53] <sabdfl> EVERYTHING
[02:53] <kiko-zzz> you guys are crazy
[02:53] <mdz> can you be more specific? what's the worst case scenario?
[02:53] <kiko-zzz> creating releases
[02:53] <kiko-zzz> not
[02:53] <sabdfl> distro.owner can https://launchpad.net/distros/ubuntu/+addrelease
[02:53] <sabdfl> hmm... no
[02:54] <kiko-zzz> he can't
[02:54] <sabdfl> i think that's locked down to launchpad.Admins
[02:54] <sabdfl> it's ok then
[02:54] <sabdfl> DOIT
[02:54] <bradb> ok, so launchpad.Driver for *both* importance and milestone?
[02:54] <sabdfl> yes please
[02:54] <kiko-zzz> sabdfl, forgive me if I'm being thick, but I still don't understand how setting drivers on edgy will fix the problem he currently has.
[02:55] <kiko-zzz> the only way I can see this working is him setting drivers for ubuntu
[02:55] <sabdfl> it won't which is why i recommended a short term fix of adding core-dev to techboard
[02:55] <kiko-zzz> what's the proper fix?
[02:55] <bradb> sabdfl: and it should be checked on 1. distrorelease, or if None, then 2. distribution, or if None, then 3. product?
[02:55] <sabdfl> techboard is distro.owner, therefor has launchpad.Edit, and should meet the current code's requirements
[02:55] <mdz> changing the owner seems cleaner than adding to techboard
[02:55] <kiko-zzz> sabdfl, on target.
[02:55] <sabdfl> bradb: sounds right
[02:55] <mdz> do I change the owner of ubuntu or ubuntu/edgy?
[02:55] <kiko-zzz> err
[02:55] <bradb> sabdfl: ok, thanks
[02:56] <kiko-zzz> bradb, on target, and add the specific security wrappers?
[02:56] <kiko-zzz> jesus
[02:56] <bradb> hrm
[02:56] <kiko-zzz> this is crazy
[02:56] <sabdfl> mdz: don't change the owner, just add them to techboard
 what's the proper fix?
[02:56] <mdz> they aren't members of techboard and I can't be sure where else in launchpad techboard is granted privileges
[02:56] <kiko-zzz> I repeat, what is the proper fix once the patch is rolled out?
[02:56] <mdz> techboard is owner of a bunch of teams, for example
[02:56] <bradb> kiko-zzz: so, yeah, i could define launchpad.Driver for IDistributionSourcePackage and ISourcePackage
[02:56] <mdz> kiko-zzz: I have pulled my ejection handle on that discussion, I'm sorry
[02:56] <sabdfl> ok, then make core-dev the distro owner
[02:57] <mdz> confirm: distro, not distrorelease?
[02:57] <sabdfl> mdz: only bradb can confirm, he knows the current code, but i think so, yes
[02:57] <sabdfl> distro
[02:57] <mdz> bradb: confirm: distro, not distrorelease?
[02:57] <sabdfl> kiko-zzz: the proper fix is to have drivers setup appropriately, and code check that at appropriate times
[02:57] <sabdfl> so:
[02:57] <bradb> mdz: for what, sorry?
[02:58] <sabdfl>  - core senior dev's have driver on distro (they can drive ANY release)
[02:58] <mdz> bradb: to grant privileges for setting milestones on bugs
[02:58] <bradb> mdz: yeah, distribution.owner
[02:58] <sabdfl>  - most or trusted devs have driver on current development release (edgy)
[02:58] <mdz> DONE
[02:58] <sabdfl>  - security team have driver on stable releases
[02:58] <kiko-zzz> sabdfl, but these tasks are on pure ubuntu. they are not on any release.
[02:58] <sabdfl> so, mdz can approve a bug to be fixed in a stable release
[02:58] <sabdfl> so can pitti
[02:59] <sabdfl> mdz can approve a bug to be fixed in edgy
[02:59] <sabdfl> so can any edgy dev
[02:59] <kiko-zzz> I understand the idea, but how does this allow mdz to do what he wants now?
[02:59] <sabdfl> hmm... interesting, because it was designed for approvals of nominated bugs, and on DISTRO tasks there is no nomination
[03:00] <sabdfl> that's why i think bugtask.assignee should be able to set importance too
[03:00] <sabdfl> so core trusted devs have driver on distro and therefor can set importance, as can folks on their own bugs
[03:00] <sabdfl> the aggregate would be correct
[03:00] <LarstiQ> drivers can override assignee at any time?
[03:01] <kiko-zzz> mdz, is this just core devs, or any devs?
[03:01] <mdz> lalalala, I can't hear any of this
[03:01] <sabdfl> i don't know how to deal with a situation where you want seb128 to be able to set an importance of a bug assigned to xul, but NOT to be able to target a bug to dapper and edgy
[03:01] <sabdfl> mdz: did you read the documentation i pointed out?
[03:02] <mdz> I glanced at it only long enough to determine that it was not relevant to the problem I was trying to solve
[03:03] <sabdfl> well, have a read there, then i think it will be clearer how this should work
[03:03] <kiko-zzz> sabdfl, that's what the bugcontact role was [incorrectly]  being used for, and for which driver is not such a great replacement now that we've had this conversation.
[03:03] <sabdfl> not sure i follow you
[03:04] <mdz> I have already spoken about how I think this should work, and I discontinued that practice when it was clear that it would not lead to a consensus
[03:04] <sabdfl> sounds like customisable fields, to me
[03:05] <kiko-zzz> sabdfl, the group of people that can decide milestone and importance is not the same group of people that can decide whether or not a bug can be targeted or backported, that's what I meant.
[03:05] <mdz> is there any way I can test whether my latest change has had the desired  effect?
[03:05] <mdz> ubuntu-core-dev is mostly asleep or away except for me, and I have additional privileges
[03:05] <sabdfl> kiko-zzz: i'm willing to be that, if you make them separate teams, they will end up members of one another, in effect
[03:05] <bradb> mdz: hang on, i'll give you a way once i look at the config...
[03:05] <sabdfl> bet
[03:07] <kiko-zzz> sabdfl, how would we solve that bet?
[03:07] <sabdfl> mdz: who do you want to be able to set any bug importance, but do not also want to allow to approve a bug as being on the track-list for edgy?
[03:07] <bradb> mdz: so yeah, if you visit an example bug, https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/21574 , and you can edit Milestone, that's a good sign
[03:07] <Ubugtu> Malone bug 21574 in linux-source-2.6.15 "sound gone after resuming from sleep on hp nx8220" [Medium,Confirmed]  
[03:08] <bradb> mdz: from there, just canvas people in https://launchpad.net/people/ubuntu-core-dev to see if they can too
[03:08] <sabdfl> also, kiko, we have said that the distro task, and devel-focus-distorelease task should be considered to be equivalent in many respects, not so?
[03:08] <sabdfl> in this case, that would seem to solve the problem
[03:08] <kiko-zzz> sabdfl, yes, it may solve the problem nicely in that case.
[03:09] <sabdfl> the person has permission to set the importance of the distro bug task if they also have the ability to set it on the devel distro release task
[03:09] <kiko-zzz> though I'm not sure the implementation of that is straightforward
[03:09] <sabdfl> and in general, mdz wants the whole team to be drivers of the devel distro release
[03:09] <bradb> mdz: er, hm, mostly asleep eh...
[03:10] <sabdfl> kiko-zzz: betcha it's less than 15 lines of code ;-)
[03:10] <mdz> bradb: even though I'm a launchpad admin and god knows what else?
[03:10] <bradb> mdz: you can add then remove me from that time too, and i can check
[03:10] <kiko-zzz> sabdfl, I still think there is a risk that he wants a separate group of people to manage importance/milestone than people that can approve nominations. 
[03:10] <mdz> yeah, that's the trnouwtrouble
[03:10] <bradb> s/that time/that team/
[03:10] <kiko-zzz> I'm sorry if that's not the case, but that's what it appears to be
[03:11] <mdz> the trouble here is that there are two incompatible points of view represented here
[03:11] <kiko-zzz> I don't think mdz wants seb to be need to approve nominated edgy bugs or specifications.
[03:11] <kiko-zzz> I think he does however want seb to be allowed to set importance/milestone.
[03:11] <mdz> one regards launchpad's model for permissions regarding distributions
[03:11] <mdz> the other is the present workflow of the people working on the distribution
[03:12] <sabdfl> let's get this on a whiteboard, and i'm confident we can work it out
[03:12] <sabdfl> i will say this, hippies, BLUEPRINT IS CLOSEST to what you need now ;-)
[03:13] <sabdfl> i'm very happy to be having this discussion, because i think release management and permissions like this are very important, and we haven't done it justice till now
[03:13] <mdz> I propose that we hold a discussion at a later time on each of these topics
[03:13] <mdz> and then attempt to reconcile them
[03:13] <sabdfl> wiesbaden it is
[03:13] <mdz> I would very much appreciate for my opinions and experience to be represented in both discussions
[03:13] <mdz> that is all
[03:13] <sabdfl> you'll be in wiesbaden?
[03:14] <mdz> I will be in Wiesbaden from August 20th-25th
[03:15] <sabdfl> i think ill be there 22-23
[03:16] <mdz> bradb: I can't actually remove you from the team afterward, I don't think
[03:16] <mdz> only deactivate you
[03:16] <bradb> mdz: if you discuss release management with sabdfl just make sure to mutter "wisdom of crowds" under your breath every few minutes. :P
[03:16] <mdz> I'll mail seb and ask him to test in the morning
[03:16] <mdz> since it was he who raised the issue with me
[03:17] <bradb> mdz: i can leave the team too
[03:17] <bradb> +leave, etc
[03:17] <bradb> but whatever, your call
[03:17] <mdz> I've mailed seb
[03:17] <bradb> ok, cool
[03:20] <sabdfl> bradb: are you serious? *release management* by the wisdom of crowds?
[03:21] <bradb> sabdfl: the "what should i care about" end of it, yeah, but not the "this IS what we care about" end of it
[03:22] <bradb> with some interesting side-by-side views of each, for good measure
[03:23] <sabdfl> i think we should do the rigorous version first, then i'm happy for you to explore some crowd wisdom as a separate view
[03:24] <bradb> sure, we're on that path now, so i think it's best to close the deal
[03:25] <sabdfl> bradb: we are even going to do TAG CLOUDS one day ;-)
[03:25] <bradb> heh heh
[03:25] <sabdfl> night all
[03:25] <kiko-zzz> night man
[03:25] <bradb> later
[03:26] <ddaa> kiko-zzz: YAAAAAAAAA
[03:26] <kiko-zzz> ddaa, what did I do now?
[03:26] <ddaa> finished the patch that fixes "renaming stuff breaks imports"
[03:26] <kiko-zzz> hah! that is rock on awesome!
[03:26] <ddaa> including the buildbot glue, and tested
[03:26] <kiko-zzz> dude our imports are looking like the rats ass
[03:26] <ddaa> now, putting it up for review
[03:26] <ddaa> and going on VACATION
[03:26] <ddaa> kiko-zzz: pardon?
[03:26] <kiko-zzz> err
[03:26] <kiko-zzz> I meant really slick
[03:27] <kiko-zzz> or something
[03:27] <ddaa> well, if you had meant "really ugly nasty, and attached to a mean sort of creature" I woud have agreed too
[03:27] <ddaa> it's more the vision I have of them, personally...
[03:28] <kiko-zzz> heh
[03:28] <LarstiQ> haha
[03:28] <LarstiQ> rats are cute!
[03:28] <LarstiQ> well, not the black plague typeps
[03:29] <ddaa> rats are mean
[03:29] <ddaa> not quite as mean as humans, but close
[03:30] <bradb> mdz: sfllaw confirmed that he can edit milestone, fwiw
[03:30] <ddaa> lifeless: david/launchpad/importd-publish-source now needs-review4
[03:30] <sabdfl> i think he meant that in the nicest possible sense of "rats ass" :-)
[03:30] <sabdfl> good work ddaa
[03:30] <ddaa> lifeless: no rush, but please have someone review it before I come back
[03:31] <sabdfl> seems like native bzr has really unleashed things nicely
[03:31] <ddaa> Thank you, I've just been working 11-12 hours/day since monday...
[03:31] <bradb> fabriqu en france
[03:32] <ddaa> Wanted to have this stuff nailed, because I know you guys won't leave me much breathing room when I come back
[03:32] <lifeless> ddaa: I'll allocate it today
[03:33] <lifeless> ddaa: when are you back ?
[03:33] <sabdfl> we will certainly be keen to rock even harder, even sooner :-)
[03:33] <ddaa> lifeless: Aug. 28th
[03:33] <lifeless> no worries
[03:40] <mdz> bradb: thanks
[03:40] <bradb> no prob
[04:18] <lifeless> spiv: so, coming wround?
[06:39] <dredg> any admins available to help me with a dupe account that 1) I have no access to the email address of and 2) has control of my WikiName?
[08:36] <carlos> morning
[08:51] <jamesh> hi carlos 
[08:52] <carlos> jamesh: hi
[08:52] <carlos> so, did they broke your computer?
[08:52] <jamesh> nope
[08:53] <jamesh> so I don't need to find out if the travel insurance would have covered such a breakage
[08:54] <carlos> let's hope they decide it before our next trip
[08:56] <sivang> morning!
[10:15] <danilos> carlos: ping?
[10:15] <carlos> danilos: pong
[10:43] <SteveA> good morning
[10:49] <sivang> re
[11:31] <jordi> hey
[11:31] <jordi> carlos: can you assign ubuntu-l10n-dz to Ubuntu translators?
[11:32] <jordi> danilos: ping
[11:32] <danilos> jordi: yes?
[11:32] <carlos> sure
[11:32] <danilos> btw jordi
[11:32] <carlos> jordi: will you have time for a meeting at 16:00 ?
[11:32] <danilos> :)
[11:32] <jordi> danilos: UTC?
[11:33] <jordi> er, carlos
[11:33] <danilos> jordi: nope, "our" time :)
[11:33] <carlos> jordi: local time
[11:33] <jordi> ugh, today's a bad day
[11:33] <carlos> jordi: and a bit later?
[11:33] <jordi> for some value of "bit", yes :)
[11:33] <jordi> like 17:30?
[11:33] <jordi> maybe earlier
[11:34] <jordi> I could log in from my father's computer
[11:34] <carlos> danilos: ?
[11:35] <jordi> danilos: so you added Somali plurals
[11:36] <carlos> jordi: ubuntu-l10n-dz added
[11:36] <F415> hi
[11:38] <jordi> danilos: my mail had 2 more, though
[11:39] <carlos> F415: hi
[11:39] <danilos> jordi: ah, sorry
[11:39] <danilos> jordi: I'm fine with a bit later as well
[11:39] <danilos> jordi: I'll look at that, and submit the others as well :(
[11:39] <jordi> ok, no worries
[11:39] <danilos> need to go out for a minute
[11:40] <jordi> ok
[12:21] <carlos> mpt: hi, around?
[12:46] <mpt> carlos, yo
[12:46] <carlos> mpt: I'm implementing TranslationReview, I just wanted to know how to add an icon button
[12:46] <carlos> but I found how to do that
[12:46] <carlos> don't worry
[12:47] <mpt> ok
[12:54] <SteveA> jordi: hi
[12:55] <jordi> hello stevea
[12:59] <danilos> jordi, carlos: what did you decide for our meeting today?
[12:59] <carlos> danilos: 17:30 CEST
[01:01] <danilos> carlos: ok, thanks
[01:02] <jordi> carlos: heh, we both replied to neil
[01:02] <carlos> :-P
[01:02] <carlos> seems like we want to close it as soon as possible, right?
[01:02] <carlos> :-)
[01:02] <jordi> danilos: when do you think you can send those plural forms to stub?
[01:02] <jordi> definitely
[01:03] <jordi> I'm a bit bored about all that issue :)
[01:04] <carlos> jordi: he already sent it
[01:04] <jordi> the other two?
[01:04] <jordi> there were 3, I only saw somali
[01:04] <LarstiQ> plural forms sound like tons of fun
[01:05] <jordi> the fun is that they never stop coming
[01:06] <LarstiQ> can't deal with them a single instance?
[01:06] <mpt> oh, jordi, that's not true, there are only 5000 languages in the world
[01:06] <carlos> LarstiQ: every language has their own plural forms
[01:06] <carlos> jordi: look at the reply to stub's email
[01:06] <LarstiQ> carlos: plural/single
[01:07] <carlos> LarstiQ: I didn't get it ;-)
[01:07] <mpt> The frequency of plural forms requests should follow a Poisson distribution over time
[01:07] <LarstiQ> carlos: as I said, it is a baaad joke ;)
[01:07] <LarstiQ> mpt: with a cutoff though?
[01:07] <jordi> heh
[01:08] <jamesh> at one point daf did a branch to allow editing languages through the web
[01:08] <jamesh> I wonder what happened to it
[01:09] <jordi> danilos: we need to talk about that KDE wiki
[01:09] <jamesh> it would have removed the need to bug stub
[01:09] <carlos> jamesh: we wrote a spec later about it
[01:10] <carlos> and the branch was never finished as far as I know
[01:10] <jordi> carlos, danilos: oh, I saw it.
[01:10] <carlos> jordi: which KDE wiki?
[01:10] <jamesh> carlos: I remember reviewing a branch to add the feature
[01:10] <jordi> carlos: the KDE wiki talking about KDE & Rosetta danilos pointed at in the lp mailing list
[01:10] <carlos> jamesh: oh, did he manage to run it thru review queue?
[01:11] <LarstiQ> where did daf go anyway?
[01:11] <carlos> jordi: I'm a bit behind...
[01:11] <jamesh> carlos: I don't think it ever got merged.  There were only a few small issues with it at the time
[01:11] <carlos> jamesh: then it should be a bazaar branch, I will try to get it and reuse as much as possible when we implement the language spec
[01:11] <carlos> jamesh: no, it was not merged
[01:12] <jamesh> carlos: iirc, it was an arch branch
[01:12] <carlos> LarstiQ: he left Canonical to work for a VOIP company (I don't remmember the name...)
[01:12] <jamesh> it was a while back
[01:12] <jamesh> telepathy
[01:12] <mpt> LarstiQ, no
[01:12] <carlos> jamesh: yeah, baz branch
[01:13] <jamesh> carlos: they call bzr branches "Bazaar branches" now :)
[01:13] <carlos> jamesh: yeah, it's a bit confusing...
[01:13] <LarstiQ> mpt: hmm
[01:13] <LarstiQ> carlos: sorry about that
[01:13] <LarstiQ> jamesh: ah ok, telepathy
[01:14] <danilos> jordi: all plural forms have been sent to stub
[01:14] <jordi> danilos: I saw it, sorry.
[01:14] <jordi> so there were four, not three
[01:14] <jamesh> LarstiQ: my mistake.  Telepathy is the product.  Collabora is the company
[01:15] <danilos> jordi: about KDE wiki, yeah, we definitelly need to answer to most of those points
[01:16] <danilos> jordi: would you care to take over help.launchpad.net/RosettaHighlights and see if it needs reorganizing, better structure, whatever?
[01:16] <LarstiQ> jamesh: I had heard about the product indeed.
[01:16] <danilos> carlos, jordi: I think essential-docs, as required by 1.0 specs is what RosettaHighlight should be
[01:17] <jordi> speaking of, mpt did have some gripes about the Rosetta FAQ, but I keep getting requests to add to it.
[01:17] <jordi> what should we do?
[01:17] <carlos> danilos: ok
[01:17] <carlos> jordi: if the FAQ is not a good source of documentation, we should add another kind of documentation
[01:18] <carlos> in the mean time, add FAQ entries
[01:18] <jordi> carlos: that's what I mean with "what should we do" :)
[01:18] <carlos> is better that than nothing
[01:18] <jordi> nod
[01:18] <danilos> jordi: we should probably document the basic usage on RosettaHighlights as well; or just the features? I am not sure on that one
[01:18] <carlos> well, help.launchpad.net was designed to cover 'what should we do'
[01:18] <carlos> danilos: RosettaHighlights should be just features
[01:19] <danilos> carlos: ok
[01:19] <carlos> jordi: add a new point in today's meeting about help.launchpad.net usage
[01:19] <carlos> so we know exactly how are we supposed to use it
[01:20] <SteveA> carlos, jordi: better to mail the list about that
[01:20] <SteveA> as proposing it for the agenda now will mean no one has prepared an answer
[01:20] <SteveA> stub: hello
[01:20] <stub> hi
[01:20] <carlos> SteveA: ok
[01:21] <carlos> stub: hi, I ran out of disk space again while testing Edgy opening
[01:22] <jamesh> carlos: the branch in question seems to be daf@canonical.com--2004/launchpad--language-admin--0
[01:22] <jamesh> would need to convert it before using
[01:23] <carlos> jamesh: sure, don't worry ;-)
[01:24] <stub> carlos: I'm removing the launchpad_test database from carbon so the Python demo will not be affected.
[01:25] <carlos> ok
[01:29] <sivang> anybody know how to reach Kinnison ?
[01:30] <sivang> (I mean, in real time, other then email)
[01:30] <LarstiQ> yes, he's on irc
[01:31] <stub> Meeting in 30 mins
[01:31] <sivang> LarstiQ: I don't really see his online anymore
[01:31] <LarstiQ> sivang: he's in #bzr
[01:31] <sivang> ah
[01:31] <sivang> LarstiQ: thanks
[01:32] <mpt> jordi, in effectiveness, making Rosetta require less process stuff > making the process stuff easier > providing instructions on the Rosetta pages themselves > adding stuff to the FAQ > not doing anything
[01:32] <stub> carlos: You happy with the translations copying? Or do you need to do more tests?
[01:33] <carlos> stub: well, I would like to test a full run on carbon, but seems like hard disk requirements are too high...
[01:33] <stub> carlos: I can create a db on jubany we can test against.
[01:34] <carlos> stub: isn't it production server?
[01:34] <stub> carlos: Yes
[01:34] <carlos> stub: wouldn't that be bad for our production server
[01:35] <carlos> remember that is an expensive operation
[01:35] <stub> carlos: But other wise we either need to run without tests, or put testing off until tomorrow when Carbon grows more disk and the real run off until next week.
[01:35] <carlos> if you think is not going to be a problem, please, go ahead
[01:35] <stub> jubany can cope, and I'm around to watch it.
[01:35] <carlos> If is possible, I would prefer not to delay it again
[01:35] <carlos> then, go ahead, please
[01:36] <carlos> danilos: you have my ok on what you have done for the highlights
[01:37] <jordi> SteveA: do you think we can get a final statement on the licensing stuff for rosetta?
[01:37] <jordi> I'd like to announce something at some point
[01:40] <danilos> carlos: ok, I'll have some more things to do
[01:40] <SteveA> jordi: not today
[01:41] <carlos> danilos: ok
[01:45] <jordi> SteveA: didn't mean today
[01:54] <mpt> I won't be at the meeting, bbl
[01:58] <SteveA> mpt did agree this with me just now
[01:59] <SteveA> it wasn't a random statement of absence
[02:00] <stub> Meeting time
[02:01] <stub> == Agenda ==   * Roll call  * Agenda  * Next meeting  * Activity reports  * Actions from last meeting  * Oops report (Matsubara)  * Bug report report (mpt)  * Production and staging (Stuart)  * Launchpad 1.0 status reports  * Sysadmin requests ----  * Python demo status update (James H)  * Approving new bug tags (Brad)  * Unusual rollout requirements (Stuart)  * LaunchpadFormView (jamesh)  * VoiceTimeSlots - everyone to schedule a 1hr vo
[02:01] <stub> Who is here?
[02:01] <malcc> me
[02:01] <cprov> me
[02:01] <sivang> me
[02:01] <matsubara> me
[02:01] <spiv> me
[02:01] <SteveA> um
[02:01] <SteveA> stub, that line was cropped
[02:01] <stub> appologies from mpt and robert
[02:01] <jamesh> me
[02:01] <BjornT> me
[02:01] <SteveA> at "a 1hr vo"
[02:01] <carlos> me
[02:01] <SteveA> me
[02:01] <bradb> me
[02:01] <stub>  * VoiceTimeSlots - everyone to schedule a 1hr voice call window a day (SteveA)  * (other items) ----  * Keep, Bag, Change  * Three sentences
[02:02] <stub> ddaa is on leave I believe
[02:02] <salgado> me
[02:02] <SteveA> ddaa is on leave
[02:02] <stub> danilos: ping
[02:02] <SteveA> apolofies from mpool too
[02:02] <jamesh> I think the LaunchpadFormView bit is a left over from last week's agenda
[02:02] <stub> kiko-zzz: ping
[02:03] <jamesh> forgot to remove it from the proposed items last week
[02:03] <stub> francis around?
[02:03] <bradb> stub: on holiday
[02:04] <stub> Next meeting same time same channel?
[02:04] <LarstiQ> SteveA: mpool or mpt?
[02:04] <stub> Objections?
[02:04] <SteveA> yes, both
[02:04] <stub> 5
[02:04] <carlos> stub: it's fine for me
[02:04] <stub> 4
[02:04] <stub> 3
[02:04] <stub> 2
[02:04] <stub> 1
[02:04] <stub> Ok. Meeting next Thursday 1200 UTC
[02:05] <stub> Activity reports. Who is up to date, who isn't?
[02:05] <bradb> up to date
[02:05] <stub> I'm up to date
[02:05] <kiko-zzz> hello there
[02:05] <SteveA> on a sprint
[02:05] <kiko-zzz> up to date
[02:05] <BjornT> up to date
[02:05] <cprov> I'm up to date
[02:05] <SteveA> so, not up to date
[02:05] <malcc> up to date
[02:05] <salgado> up to date
[02:05] <matsubara> not up to date
[02:05] <jamesh> not up to date.  I'll send a summary for this week
[02:05] <spiv> up to date
[02:05] <carlos> I started again on Monday
[02:06] <danilos> me
[02:06] <danilos> sorry sabout it
[02:06] <danilos> I'm not up to date
[02:06] <danilos> missing one for yesterday, have all the others for this week ready
[02:07] <stub> I think that is everyone? Getting good on this front, james winning the wooden spoon as our most regular repeat offended
[02:07] <stub> der
[02:07] <stub> No action items from last week I believe
[02:08] <SteveA> yes, true
[02:08] <stub> So OOPS report with our host matsubara
[02:08] <matsubara> Today's oops report is about OOPS-228B817, OOPS-228C774, OOPS-228B99 and NotFound errors on {launchpad,gnome} project page. I'll try to reproduce and report all of them after the meeting.
[02:08] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B817
[02:08] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228C774
[02:08] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B99
[02:08] <matsubara> OOPS-228B817 is a bug in the advanced bug search form. bradb could you take a look at it?
[02:08] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B817
[02:08] <matsubara> OOPS-228C774 is a bug in the +queue page. cprov, you triggered that one, so you're aware of the bug. Are you working on it?
[02:08] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228C774
[02:08] <bradb> matsubara: sure
[02:09] <matsubara> OOPS-228B99 is a bug in an shipit page, but I think it's related to the login workflow. salgado, can you take that one?
[02:09] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B99
[02:09] <cprov> matsubara: yes, it requires RF 3917 on production. stub any ETA ?
[02:09] <matsubara> What happened to these pages: https://launchpad.net/projects/launchpad and https://launchpad.net/projects/gnome? Both are 404ing.
[02:10] <stub> cprov: If that is the patch you requested cherry picked, hopefully tomorrow morning
[02:10] <matsubara> thanks bradb 
[02:10] <stub> (around 0900 UTC)
[02:10] <matsubara> cprov: ok
[02:10] <cprov> stub: yes, ok, thanks 
[02:10] <malcc> matsubara: Pillar names, they're now at ...-project
[02:11] <SteveA> how about we get elmo to add a custom redirect for these
[02:11] <SteveA> for a short while?
[02:11] <SteveA> worth it or not?
[02:11] <stub> I think we can cope. Don't know if gnome cares or not.
[02:11] <SteveA> matsubara: how many oopses of 404 for gnome were there?
[02:11] <jamesh> or even get the Navigation classes for ProductSet and ProjectSet to do redirects for "-product" or "-project" suffixes
[02:11] <SteveA> or, how many per day?
[02:11] <matsubara> SteveA: 19
[02:11] <carlos> stub: GNOME is not yet using launchpad/Rosetta
[02:11] <SteveA> don't worry about it then
[02:12] <carlos> so I guess is not a big deal
[02:12] <SteveA> jamesh: we'll be fixing the nav classes up for teh move to /$name rather than /projects/$name
[02:12] <matsubara> ok
[02:12] <jamesh> for Gnome, it'd probably be better to give the project the short name
[02:12] <carlos> jamesh++
[02:12] <stub> salgado: So you were taking OOPS-228B99 ?
[02:12] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B99
[02:12] <salgado> stub, not really
[02:13] <SteveA> matsubara: was there a referer on those 404s?
[02:13] <salgado> I have no idea what it is about
[02:13] <SteveA> matsubara: I mean, do people type in that URL, or do they get linked from somewhere?
[02:13] <SteveA> we can correct the link in the source, perhaps
[02:13] <matsubara> SteveA: 15% from search bots, 73% referred from local sites
[02:13] <matsubara> SteveA: haven't checked each one of them that have a local site as referer
[02:13] <SteveA> matsubara: later, please take a look at a few of the local site refereres
[02:14] <matsubara> SteveA: I will and report it if needed
[02:14] <stub> So OOPS-228B99 looks like a general login problem and needs a bug opened on it I think
[02:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/228B99
[02:14] <SteveA> thanks matsubara 
[02:14] <SteveA> chinstrap?
[02:14] <SteveA> ah, Ubugtu needs to be taught to use devpad
[02:15] <matsubara> stub: I'll report that one after the meeting and find someone to work on it.
[02:15] <matsubara> stub: I'm done here. thanks
[02:15] <matsubara> thanks everyone.
[02:15] <jamesh> those URLs are redirecting through to devpad
[02:15] <stub> mpt isn't here, so no bug report this week
[02:15] <stub> Production and staging.
[02:15] <niemeyer> Hey folks
[02:16] <matsubara> hi niemeyer 
[02:16] <SteveA> I'll ask mpt to mail the bug report later
[02:16] <kiko> jamesh, is there a gnome product? that's crack. let me see
[02:16] <jamesh> kiko: it's marked inactive
[02:16] <kiko> grumble
[02:16] <SteveA> ah, cool
[02:16] <jamesh> kiko: but I can still see it here: https://launchpad.net/projects/gnome-project/gnome :)
[02:16] <SteveA> so we can fix that
[02:16] <stub> Staging server is running normally, with periods of slowness when Carlos has been stressing the server. We really need to move language pack exports off there. I suggest a purpose built database on carbon if we can't run it on the production system safely.
[02:16] <kiko> fixing
[02:17] <kiko> stub, will it happen the production systems?
[02:17] <carlos> stub: the language pack script needs some optimization work
[02:17] <kiko> language pack generation being done on staging is broken, and I asked that to be changed years ago
[02:17] <stub> Production is running fine. The code update was delayed until Wednesday for no reason in particular.
[02:17] <carlos> it locks the database too much so we cannot move it into production as it's now
[02:17] <stub> The update was a bit wobbly, with the vhosting updates biting us. This is all running correctly now.
[02:18] <carlos> kiko: I started to prepare it for production and then, I noticied the performance problem
[02:18] <kiko> carlos, no email followup?
[02:18] <carlos> hmm
[02:18] <carlos> I think I did
[02:18] <carlos> not sure
[02:19] <stub> Hopefully there will be two hours downtime tomorrow at around 0800 UTC for kicking off the edgy translations.
[02:19] <stub> This is pending final testing of the code and approval from mdz, so no downtime announcements have been sent.
[02:20] <danilos> stub: that's not too good, no? :(
[02:20] <stub> Because of the wobbly rollout this week, I've added a section to the LaunchpadProductionStatus wiki page to mark revisions that need special attention when being rolled out.
[02:20] <stub> danilos: It should be fine
[02:20] <stub> danilos: People want the translations open, so I don't think there will be complaints when the alternative is delaying it until the next week.
[02:21] <danilos> stub: ok, but I think we should have announced it earlier
[02:21] <jamesh> is this full Launchpad downtime or Rosetta downtime?
[02:21] <danilos> stub: sure, agreed on that point
[02:21] <SteveA> we should use a special "down" page then
[02:21] <danilos> jamesh: entire launchpad, afaik
[02:21] <malcc> stub: Did you also inform the authors of the offending revisions? I mean to say, it wasn't me was it?
[02:21] <stub> danilos: If it was announced earlier, it would have been for Tuesday and we would have had to cancel ;)
[02:21] <jamesh> okay
[02:21] <SteveA> that explains the downtime
[02:22] <stub> malcc: I approved the particular patch that bit us
[02:22] <danilos> SteveA: right
[02:22] <stub> It was vhosting stuff, and we had neglected to do the preparatory work with the apache configs.
[02:22] <SteveA> i just cleaned up the rest of it with elmo, btw
[02:23] <stub> jamesh: It is full Launchpad downtime, inc. wiki auth.
[02:23] <spiv> stub: hmm.
[02:23] <spiv> stub: how hard would it be to point the authserver at a cutdown backup to keep the wikis going?
[02:24] <stub> spiv: I'll look into it.
[02:24] <jamesh> spiv: like staging?
[02:24] <spiv> jamesh: yeah I guess, although we don't want it to be able to do any writes.
[02:25] <jamesh> spiv: maybe get it to log in with a read-only account.
[02:25] <spiv> jamesh: right.
[02:25] <stub> I think that is all. Any questions?
[02:26] <stub> We can discuss authserver after. We could probably keep the authserver running during the work, but I don't want to risk it.
[02:26] <stub> Pointing it at another db should be fine, even if password changes and similar get lost during that 2 hour period
[02:26] <stub>  * Launchpad 1.0 status reports
[02:26] <spiv> stub: I'm worried about things like createBranch
[02:27] <danilos> Rosetta 1.0:
[02:27] <danilos> - opening edgy for translation: scheduled for Friday
[02:27] <danilos> - firefox import/export: slow progress due to other activities
[02:27] <danilos> - oo import/export: blocked on firefox
[02:27] <danilos> - translation review: specification started
[02:27] <danilos> - essential docs: sabdfl assigned to danilos, need to discuss with jordi
[02:27] <danilos> - outstanding issues: danilos needs help with bug 30602
[02:27] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  https://launchpad.net/bugs/30602
[02:27] <stub> spiv: ok. We can discuss it after meeting or tomorrow morning.
[02:27] <bradb> tell me when you're ready for Malone 1.0
[02:27] <malcc> Soyuz 1.0: We're making good progress on design and specs for PPA, and fixing critical bugs, other 1.0 goals are on standby for now.
[02:28] <bradb> Malone 1.0:
[02:28] <bradb> Release management: Good, but slow progress, in part because I diverged from the spec for approving and declining. Have had several discussions re: implementation and UI along the way. Showed the UI to both mdz and kiko, and both approved.
[02:28] <bradb> Guided filebug: Haven't had time to work on it since London. About 40% along.
[02:28] <bradb> Malone documentation: Tweaked https://help.launchpad.net/MaloneXMLRPC, after confirming it works in production. Of course, this is an amazingly rough draft but can be folded into the official documentation.
[02:28] <bradb> Bug tags: Bjorn added displaying counts beside tags in the portlet. Decided to pursue a confirmation UI for new tags. One UI would confirm on a separate screen, one would confirm in the notification area. Went with notification area option, mostly done.
[02:28] <bradb> Keeping bugs concise: Bjorn hasn't done anything this week. kiko has made some tweaks to collapse duplicate comments, and not show the first comment by default, instead showing a link under the description to the original, if it was changed. Status "Deployment" should be clarified.
[02:28] <bradb> (fin)
[02:28] <SteveA> infrastructure 1.0: vhosting landed.  menus up to date, and being css styled by the experts.  pillar names... stu needs to do more work there.  page layout: good work happening here.
[02:28] <SteveA> (pillar names, like 50% complete)
[02:28] <SteveA> (and I guess I'll be involved in the navigation changes)
[02:29] <kiko> salgado?
[02:29] <salgado> Question tracker 1.0 (and some other random ones)
[02:29] <salgado> I'm currently working on landing support-tracker-karma (which has been reviewed already), karma-context has been deployed this week, person-creation-rationale is not yet started (BTW, kiko, https://launchpad.canonical.com/PersonCreationRationale has some outstanding issues pointed by SteveA, can you check them?) and direct-person-registration is not started and is not on track --I didn't know it was assigned to me, and we don't even
[02:29] <salgado>  have a page for it on the wiki.
[02:29] <stub> SteveA: I need to do more work on PillarNames?
[02:30] <salgado> - New views (pending implementation of new workflow)
[02:30] <SteveA> stub: someone does anyway
[02:30] <SteveA> stub: I guess the database part is done
[02:30] <salgado> - Localization has been dropped as a 1.0 target.  I need to rearrange this into other specs so that we can decide what will be a 1.0 goal and what's not
[02:31] <SteveA> we can sort out what happens next in the infrastructure call next week
[02:31] <stub> SteveA:  I think everything specced was implemented
[02:31] <SteveA> stub: we don't have /$name yet
[02:31] <SteveA> just /thing/$name
[02:31] <SteveA> so, much URL reorg, with redirects
[02:31] <SteveA> using fancy Navigation things
[02:31] <salgado> kiko, last week, the New workflow was stalled pending further review of the spec by you.  I didn't check with Francis what's the status of that now
[02:31] <stub> SteveA: That wasn't specced. That was left for later specs.
[02:31] <SteveA> stub: oh poo.
[02:32] <stub> action item: update infrastructure specs if /$name is needed for 1.0
[02:32] <SteveA> action item for whom?
[02:32] <kiko> pas moi!
[02:32] <SteveA> MeetingAction: SteveA to update infrastructure specs if /$name is needed for 1.0
[02:33] <stub> That everyone?
[02:34] <stub>  * Sysadmin requests
[02:34] <kiko> yes
[02:34] <stub> Anything outstanding?
[02:35] <stub> matsubara: Your voip sorted yet?
[02:35] <danilos> yes, 14579 (voip), four weeks and going
[02:35] <matsubara> stub: My voip?
[02:35] <stub> Argh
[02:35] <danilos> probably mine :)
[02:35] <kiko> stub, I have 3 requests up for stuff to do with email.
[02:35] <kiko> two users who don't get email from us
[02:35] <kiko> one user whose ubuntu.com redirect is stuck in a loop
[02:36] <stub> As far as I'm aware, there has yet to be a case of Launchpad email not reaching the end user that has been a problem at our end (which is good)
[02:36] <stub> kiko: Need anything from us on those rt issues, or are you on top of it?
[02:37] <stub>  * Python demo status update (James H)
[02:37] <kiko> stub, I'm bothering people..
[02:37] <kiko> SteveA, can we please please pretty please get the ubuntu-com-alias script in RF?
[02:38] <kiko> SteveA, no tests! I will do the tests myself!
[02:38] <jamesh> The Python infrastructure committee invited the contacts for all the trackers entered to their mailing list this week
[02:38] <SteveA> kiko: I dont know what that is.  would you privmsg me about it?
[02:39] <jamesh> They have started looking at the entered trackers and deciding what features they feel are important.  I sent an email earlier today outlining some of the things they've identified so far
[02:40] <kiko> jamesh, saw it, will answer
[02:40] <jamesh> One of the features they wanted custom fields for we already supported (marking bugs as having a patch), the other could be done in an ad-hoc way but is worth investigating further (recording earliest version a bug occurs in)
[02:41] <jamesh> they would also like to include some custom instructions on the bug submission page, which we already have a bug open on
[02:41] <jamesh> that's about all I've got to say so far.
[02:41] <stub>  * Approving new bug tags (Brad)
[02:41] <stub> This was an old one?
[02:41] <SteveA> recurring
[02:41] <SteveA> for a while
[02:41] <SteveA> so, looking at the page...
[02:42] <kiko> can the people approving them please move them to the approved section?
[02:42] <SteveA> I'm in favour of: soyuz-upload, soyuz-publish, soyuz-build
[02:42] <SteveA> bradb: I don't find the example compelling.  maybe come up with a few more examples?
[02:42] <danilos> off all the proposed, I'm only hard-on about 'trivial'
[02:42] <kiko> I agree with trivial
[02:42] <kiko> sivang asked me yesterday for a few
[02:42] <SteveA> Im in favour of xmlrpc and email, but I'm not keen on the names
[02:42] <kiko> and I spent time digging some up
[02:43] <danilos> kiko: should add them to examples :)
[02:43] <SteveA> I disagree with the trivial ones listed as examples
[02:43] <bradb> SteveA: i'll try, though it's hard for me to remember now exactly what else he asked to be reported, because i couldn't track them before
[02:43] <stub> We can rename tags in bulk if we want (other people can't, but we can)
[02:43] <SteveA> the capitalisation one is not trivial -- it touches a lot of code, and involves tricky project communication
[02:44] <LarstiQ> bradb: the milestones one from +- 10 hours ago?
[02:44] <danilos> SteveA: hum, doesn't it affect only a single particular instance of capitalization?
[02:44] <bradb> LarstiQ: i tagged that one already :P
[02:44] <SteveA> so, i'd like to see some more examples of "trivial".  but, i'm happy for "trivial" to be used, and reviewed later.
[02:44] <LarstiQ> bradb: ah :)
[02:44] <bradb> LarstiQ: (and added it to the page)
[02:44] <SteveA> danilos: I don't think so, but if so, then yes, that would be trivial
[02:44] <kiko> SteveA, which capitalization one? oh. yeah, it's controversial
[02:44] <SteveA> can we have launchpad-email and launchpad-xmlrpc ?
[02:44] <SteveA> well, maybe just email and xmlrpc
[02:44] <danilos> SteveA: anyway, lets postpone decision on trivial until we list more worthy examples
[02:44] <kiko> SteveA, what does the prefix help us with? :)
[02:44] <SteveA> I'm concerned that tags are global
[02:45] <SteveA> for when we do descriptions of them
[02:45] <kiko> SteveA, they aren't really.
[02:45] <SteveA> but anyway, +1 to email and xmlrpc
[02:45] <SteveA> +1 to trivial
[02:45] <SteveA> -1 to sabdfl until I see more evidence
[02:45] <kiko> thanks
[02:45] <SteveA> -1 to search
[02:45] <SteveA> so far
[02:46] <SteveA> as for extra time... anyone not okay with 15 mins extra time?
[02:46] <kiko> I'm fine with it
[02:46] <SteveA> speak now
[02:46] <SteveA> 6
[02:46] <stub> bradb: If tags grow meta data, that will be a requirement I think
[02:46] <SteveA> 5
[02:46] <SteveA> 4
[02:46] <SteveA> 3
[02:46] <SteveA> 2
[02:46] <SteveA> 1
[02:46] <SteveA> 0
[02:46] <SteveA> ok stub, 15 mins more
[02:46] <stub> Done with tags for now?
[02:46] <SteveA> yes.
[02:46] <stub>  * LaunchpadFormView (jamesh)
[02:47] <SteveA> bradb: please update the tags page
[02:47] <stub> (Or was this the old one?)
[02:47] <bradb> yeah, doing so
[02:47] <jamesh> that was an old item.
[02:47] <SteveA> thanks bradb 
[02:47] <stub>  * VoiceTimeSlots - everyone to schedule a 1hr voice call window a day (SteveA)
[02:47] <SteveA> and bradb, please put approved ones in alphabetical order
[02:47] <bradb> SteveA: sure
[02:47] <SteveA> ta
[02:47] <SteveA> yeah, so
[02:47] <danilos> how do we go about that? (I hate crappy phone lines, not phones :)
[02:48] <SteveA> I haven't seen much use of pre-implementation calls
[02:48] <SteveA> or the [p=name]  in checkins
[02:48] <SteveA> I think the calls were useful, when the occurred
[02:48] <kiko> SteveA, I had one yesterday
[02:48] <kiko> so I don't think I agree
[02:48] <carlos> SteveA: oh, finally, I didn't find the email about p=name and teh wiki is not documentating it
[02:48] <SteveA> kiko: was there a note on the mailing list
[02:48] <SteveA> ?
[02:48] <SteveA> kiko: was it useful?
[02:48] <kiko> SteveA, obviously, yes, there was
[02:48] <carlos> so I thought it was my imagination...
[02:48] <kiko> and yes it was useful, though we only kicked it off on the phone and then moved to IRC
[02:49] <SteveA> cool
[02:49] <SteveA> I want to get the code review team talking with the app developers more then is currently happening
[02:49] <SteveA> this was highlighted in this week's review meeting
[02:49] <SteveA> so, I'm looking for ways to get this to happen
[02:49] <SteveA> suggestions welcome
[02:49] <danilos> I think I'd find voip accounts really, really helpful with this
[02:49] <kiko> SteveA, people need to write each other more. 
[02:50] <kiko> it's really unfortunate that people choose to coordinate through IRC
[02:50] <kiko> because we end up chasing each other across timezones
[02:50] <SteveA> a suggestion discussed in the review meeting was for people to advertise a 1hr daily slot when they're very open to voice calls
[02:50] <kiko> and the important issues are not discussed in email as they should be
[02:50] <SteveA> about code
[02:50] <SteveA> kiko: I agree with you.  I have two additional issues where I think voice is very useful
[02:50] <kiko> SteveA, if those calls are about teaching and mentoring people, that's great
[02:50] <SteveA> 1. finding out about things that should be discussed, but which won't be otherwise
[02:50] <danilos> about code or about designs? pre-implementation calls sound much more like design-oriented
[02:51] <kiko> but if they are about solving design issues, then keeping it off the mailing list is a net loss
[02:51] <SteveA> 2. ensuring that the communication is really happening, that understanding is complete on both sides
[02:51] <kiko> I mean look at how many things are decided without any mail at all? 
[02:51] <SteveA> often emails can miss both those
[02:51] <kiko> so I agree
[02:51] <SteveA> as can irc
[02:51] <SteveA> kiko: let's you and I discuss this offline
[02:51] <kiko> sure.
[02:52] <SteveA> and work out a good strategy
[02:52] <SteveA> meanwhile, take advantage of voice calls to discuss code and designs
[02:52] <SteveA> poarticularly with the review team
[02:52] <SteveA> done
[02:52] <stub> * Kiko wants to nag people about email usage
[02:53] <danilos> already started as part of previous point :)
[02:53] <kiko> yeah.
[02:53] <stub> Or did you hijack Steve's topic for everything you wanted to mention?
[02:53] <stub> ok
[02:53] <stub>  * Keep, Bag, Change
[02:53] <stub> 10
[02:53] <stub> 9
[02:53] <stub> 8
[02:53] <stub> 7
[02:53] <stub> 6
[02:53] <stub> 5
[02:53] <stub> 4
[02:53] <stub> 3
[02:53] <stub> 2
[02:53] <stub> 1
[02:53] <stub>  * Three sentences
[02:53] <mpt> BAG: Annoying bzr pqm-submit bugs
[02:53] <malcc> Keep: Communication on IRC !
[02:53] <danilos> DONE: pqm-submit 44860, 1788; review/response on 2237; help.lp.net/RosettaHighlights, user assistance
[02:53] <danilos> TODO: bug 30602, ff-import
[02:53] <danilos> BLOCKED: no
[02:53] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  https://launchpad.net/bugs/30602
[02:54] <malcc> DONE: Landed process-upload-tidy, bug 55896->review, lots of PPA design/speccing.
[02:54] <malcc> TODO: Sprint next week. Lots more PPA design/speccing. Get started on bug 35965.BLOCKED: No.
[02:54] <Ubugtu> Malone bug 55896 in soyuz "Archive symlink constraint being broken" [Critical,In progress]  https://launchpad.net/bugs/55896
[02:54] <Ubugtu> Malone bug 35965 in soyuz "exceptions in process-upload not communicated to uploader" [Critical,Confirmed]  https://launchpad.net/bugs/35965
[02:54] <sivang> DONE: Sent revised patch for malone #52038 , sabdfl had to resolve conflicts manually as it was against out of date rf.
[02:54] <Ubugtu> Malone bug 52038 in blueprint "Please rename "Braindump" state to "New"" [Wishlist,In progress]  https://launchpad.net/bugs/52038
[02:54] <sivang> TODO: Wait patiently to be set up with rf access agaig, check out the bugs kiko sent me.
[02:54] <bradb> DONE: Upstream status search UI changes. Reviewed some patches. Verified xmlrpc working in production. Release management.
[02:54] <bradb> TODO: Further tweaks to upstream status search UI. Update my milestone/importance permissions patch based on yesterday's launchpad.Drivers rant^Wdiscussion.
[02:54] <bradb> BLOCKED: No.
[02:54] <salgado> DONE: Fixed a bunch of things on shipit, replied to some code review and fixed things suggested by reviewers, reviewed mark's blueprint-essential-subscribers branch and a few other random fixes
[02:54] <salgado> TODO: Land my branches that are pending review, fix some stuff on the mirror prober as per discussion last week, finish rearranging the specs related to localization of tickets, more code review and random fixes
[02:54] <salgado> BLOCKED: No
[02:54] <sivang> BLOCKED: Not really, as I have lots of patience :-)
[02:54] <malcc> BLOCKED: No
[02:54] <matsubara> DONE: back from sprint + holidays, catching up email, oops report analysis
[02:54] <BjornT> DONE: code reviews. finished off most of the bug tags implemenation.  some bug fixes.
[02:54] <matsubara> TODO: report new OOPS bugs, catch up with activity reports, email the list about the new oops format spec, fix some oops bugs.
[02:54] <matsubara> BLOCKED: no
[02:54] <cprov> DONE: PPA discussion and specification, soyuz critical bug fixing, DDTP & build-failure-notification rollout
[02:54] <cprov> TODO: fishing PPA plan, prepare to soyuz sprint
[02:54] <cprov> BLOCKED: no
[02:54] <BjornT> TODO: work on bug forwarding workflow. code reviews.
[02:54] <BjornT> BLOCKED: no
[02:54] <spiv> DONE: reviews, bzr smart server
[02:54] <spiv> TODO: reviews, bzr smart server
[02:54] <spiv> BLOCKED: no
[02:54] <carlos> DONE: Testing XaraLX product removals to move into production, Fixed a cache issue with distrorelease.txt, bug #56314 (Edgy translations), bug #80. Started TranslationReview
[02:54] <kiko> DONE: prepare report, many coding activities, keeping track of developments in all user-facing fronts, lots of end-user communication
[02:54] <carlos> TODO: TranslationReview, KDE plural forms support
[02:54] <carlos> BLOCKED: No
[02:54] <Ubugtu> Malone bug 80 in rosetta "cannot see who put in bad translation" [Wishlist,In progress]  https://launchpad.net/bugs/80
[02:54] <jamesh> DONE: code reviews, product release finder fixes/renaming, formlib work, Python
[02:54] <jamesh> bug tracker comp
[02:54] <jamesh> TODO: code reviews, Python bug tracker comp, look at OOPS system? spec out scheduler-in-launchpad a bit more?
[02:54] <jamesh> BLOCKED: no
[02:54] <kiko> TODO: ship off report, fix my part of KBC, more of the above
[02:54] <kiko> BLOCKED: no
[02:54] <SteveA> DONE: infrastructure meetings, UI meetings
[02:54] <SteveA> TODO: UI meetings, return home
[02:54] <SteveA> BLOCKED: no
[02:54] <stub> TODO: open edgy translations, name blacklist
[02:54] <stub> DONE: I forget. Various bug fixes in my activity reports
[02:54] <stub> BLOCKED: no
[02:55] <kiko> stub, you did great work this week on many fronts, really appreciated
[02:55] <stub> No blockers, so MEETING OVER
[02:55] <SteveA> please everyone, but particularly sivan and malcc and kiko, prepare you 3 sentences in a text editor, and paste them all at once
[02:55] <SteveA> it makes doing the meeting log easier
[02:56] <malcc> SteveA: I did, it just missed a newline, so I repeated the BLOCKED section.
[02:56] <SteveA> thanks for running the meeting stub
[02:56] <SteveA> malcc: i see.  thanks.
[02:57] <jamesh> re: mpt's problems with pqm-submit, perhaps I could look at getting the two pqm-submit bugs fixed
[02:58] <mpt> That would be luverly
[03:04] <kiko> hey stub
[03:04] <kiko> can you reactivate the gnome product for a second?
[03:06] <stub> kiko: Did you want to rename it, so gnome-project becomes gnome again?
[03:06] <kiko> yes
[03:06] <kiko> to bogus1
[03:06] <sivang> SteveA: sorry, I did mine in tomboy, but the paste didn't occur at once since it happens only when you have more then 7 lines to paste, and then irssi does it for you. 
[03:07] <stub> kiko: Renaming done
[03:07] <kiko> thanks stub 
[03:08] <salgado> spiv, around?
[03:09] <sivang> SteveA: will make sure it's pasted at the same time next round.
[03:09] <salgado> SteveA, my shipit-trivialities branch was assigned to you; it should be a quick review, since you've already reviewed the infrastructure bits of it... any idea when you'll have some time for it?
[03:09] <spiv> salgado: 
[03:10] <spiv> salgado: yes :)
[03:10] <salgado> spiv, have a moment to talk about that issue with the mirror prober?
[03:10] <spiv> salgado: yep
[03:11] <salgado> so, that sounds to me like a regression caused by the removal of the self.waiting check
[03:11] <spiv> Hmm.  I'm surprised by that.
[03:11] <salgado> since that's the failure I used to have before we added that check
[03:12] <salgado> it happened a few times in production (the AlreadyCalled error), but it doesn't happen always
[03:13] <salgado> that's why I didn't simply reverted that change to see what happen;  I wanted to make sure I know what's causing it and reproduce it in a test
[03:14] <spiv> It would be good to add a call to "twisted.internet.defer.setDebugging(True)" to the script so we get more info next time it happens.
[03:15] <spiv> (there's a small performance/memory penalty for turning it on, but I doubt it will be significant for this script)
[03:16] <spiv> In particular, it'll tell you what already called that Deferred, so we'll have a good idea what it was that failed to cancel the timeout call.
[03:18] <spiv> Can you reproduce the problem running the script by hand?
[03:22] <salgado> let me check
[03:22] <salgado> no, it didn't fail. let me try again with a shorter timeout
[03:23] <salgado> yay, got it
[03:24] <spiv> salgado: can you pastebin the output for me?
[03:24] <salgado> sure
[03:25] <salgado> spiv, https://sodium.ubuntu.com/~andrew/paste/fileMKR2gX.html
[03:26] <danilos> hey guys, use the devpad ;)
[03:26] <spiv> salgado: so, that's interesting.
[03:26] <salgado> does that mean succeeded and failed where both called?
[03:26] <spiv> danilos: you can paste non-launchpad stuff too ;)
[03:26] <spiv> salgado: right
[03:27] <spiv> salgado: first succeeded was called.
[03:27] <spiv> salgado: and what's supposed to happen is that the callback chain that triggers ought to stop the timeout call.
[03:28] <salgado> exactly. _cancelTimeout is the first in the chain
[03:28] <spiv> Ah, hmm.
[03:28] <spiv> I think I know the problem...
[03:29] <spiv> salgado: distributionmirror-prober.py adds callbacks to the callback chain before the timeout canceller.
[03:30] <spiv> salgado: and *those* callbacks include updateMirrorStatus
[03:30] <salgado> ouch
[03:30] <SteveA> salgado: please ask someone else to review.  I won't get around to it until sometime next week.
[03:30] <spiv> salgado: that does more probing and returns a Deferred...
[03:30] <salgado> it does that before calling probe()?
[03:30] <spiv> salgado: Right.
[03:31] <spiv> salgado: so, move line 74 of distributionmirror-prober.py up to line 66 and it should be fine.
[03:31] <salgado> SteveA, can you move the branch to the rejected queue then?  I'll find somebody to review it for me.
[03:31] <spiv> salgado: but, it would be nicest I think if things didn't access prober.deferred directly
[03:32] <spiv> salgado: and instead only dealt with the deferred returned from the probe method.
[03:32] <stub> carlos: I have a db ready on jubany we can test the translation copying on. What server/account do you need access from? (Or do you want me to run the script?)
[03:32] <spiv> salgado: i.e. the 'deferred' attribute of ProberFactory really should be private, so client code can't break these assumption.
[03:32] <stub> doh
[03:33] <spiv> salgado: so in addition to fixing this bug, I'd rename the 'deferred' attribute to '_deferred', to make sure nothing else is causing similar problems.
[03:34] <kiko> stub, did you actually rename /products/gnome? because projects/gnome-project still doesn't let me rename.
[03:36] <salgado> spiv, right, but I'd still need to use _deferred.add*() on that file.  or is there anything I could do to avoid that?
[03:36] <spiv> salgado: no, it can use the Deferred that ProberFactory.probe returns
[03:37] <stub> kiko: I've committed this time ;)
[03:37] <kiko> thanks.
[03:37] <spiv> salgado: which is guaranteed to have whatever callbacks ProberFactory needs to run first added first.
[03:37] <salgado> spiv, hmmm, how do I do that, if I don't actually call prober.probe, but pass it to semaphore.run() instead?
[03:37] <kiko> stub, for a moment I thought I had found a bug in pillarnames!
[03:37] <SteveA> bradb: thanks for updating the tags page.
[03:37] <bradb> SteveA: no prob
[03:37] <SteveA> bradb: it isn't quite right though.  I approved the soyuz-* ones.
[03:37] <SteveA> bradb: and the sabdfl and search ones should be in proposed still, pending more compelling examples
[03:38] <spiv> salgado: oh, right -- use the defer that semaphore.run returns :)
[03:38] <SteveA> sorry if I wasn't clear about that in the meeting
[03:38] <SteveA> would you update it with this?
[03:38] <bradb> ah, crap, sorry, i missed that. i saw your +1/-1 lines, but missed that line
[03:38] <bradb> yeah, updating now
[03:40] <spiv> salgado: I was forgetting about that piece of indirection :)
[03:40] <spiv> salgado: also, that means my suggestion above about just moving the line isn't by itself enough, but changing things so that ProberFactory.deferred becomes private will be.
[03:41] <salgado> spiv, ah, cool. I thought semaphore.run() wouldn't return anything because it wouldn't call prober.probe at that time
[03:42] <spiv> salgado: right, it doesn't call it at the time -- but it lets you know when it does by returning the Deferred :)
[03:44] <bradb> SteveA: changed page, with message: approve soyuz-*; move sabdfl and search tags back to proposed
[03:44] <spiv> s/the Deferred/a Deferred/
[03:44] <salgado> I thought it added prober.probe to a queue and then returned imediatly
[03:44] <spiv> salgado: correct
[03:45] <salgado> so, it doesn't return the same deferred returned by prober.probe()?
[03:45] <SteveA> help.launchpad.net is *very* slow for me, reading, today
[03:45] <spiv> No, sorry if I was unclear.
[03:45] <salgado> ah, right, now I got it. :)
[03:46] <salgado> (or at least I think I did :)
[03:47] <spiv> salgado: one more thing
[03:47] <spiv> salgado: in addition to making _deferred private, it's tempting to create it in ProberFactory.probe rather than __init__
[03:48] <lifeless> SteveA: hi, are you too busy for reviews at the moment, or is it that specific review ?
[03:48] <SteveA> lifeless: too busy, until next week
[03:49] <lifeless> ok
[03:49] <spiv> salgado: hmm, although that doesn't really gain anything... it'd be a step towards a ProberFactory that you can call probe on multiple times, but thinking about it that's probably a YAGNI.
[03:49] <lifeless> SteveA: start of or end of ?
[03:49] <SteveA> lifeless: not sure yet.
[03:50] <lifeless> ok
[03:50] <salgado> spiv, right, I won't do it, then
[03:51] <salgado> lifeless, maybe you'd like to review that for me? (it should be pretty quick :-)
[03:51] <lifeless> actually I've given it to bjorn
[03:51] <spiv> salgado: one thing that occurs to me is that someone less familiar with Twisted idioms than me should do some reviewing of this code
[03:51] <lifeless> cause I'm about to go to sleep
[03:52] <salgado> lifeless, fair enough, sleeping is good every once in a while. :)
[03:52] <lifeless> :)
[03:53] <spiv> salgado: because while I quickly recognise familiar Twisted patterns in this, there aren't many comments to help other people less fluent -- e.g. how the timeout and timeout cancellation stuff is done probably isn't obvious without a comment.
[03:53] <salgado> spiv, you mean, reviewing the whole code or just this change?
[03:54] <spiv> salgado: for now, just this change I think.
[03:54] <spiv> salgado: while I enjoy reviewing code using Twisted like this, it's probably good to get different opinions occasionally :)
[03:54] <salgado> agreed
[03:55] <salgado> I'll add a note that it shouldn't be assigned for you (or anybody with deep twisted knowledge) to review
[03:55] <spiv> salgado: well, I think the main point is probably "someone else" rather than "someone unfamiliar with twisted".
[03:57] <spiv> salgado: it's also that I helped design how bits of this code work in the earlier reviews, so I remember how it works quite well without needing comments, so it's easy for me to not notice they're missing.
[03:57] <salgado> yeah, I see your point
[04:02] <salgado> spiv, is it possible to check the what's the first callback of the chain, in a deferred?
[04:03] <salgado> hmmm, no. it can't be on connect()
[04:05] <mwh_> Hi, how can I delete a launchpad account?
[04:05] <kiko> hey mwh_ 
[04:05] <salgado> the real problem is with callsites adding callbacks to the chain before calling probe(), but I think that's almost impossible now, since we made deferred a "private" attribute
[04:05] <kiko> mwh_, why would you want to do such a thing? :)
[04:06] <mwh_> I made a test user to check out some stuff
[04:06] <mwh_> and now I don't need it anymore
[04:06] <mwh_> I would like to clean  up my own mess :)
[04:06] <kiko> mwh_, okay, 2 things
[04:07] <kiko> mwh_, a) you can use staging.launchpad.net for tests whenever you like. the data there is a copy of the real data
[04:07] <kiko> mwh_, b) you can just merge the test account into your own account.
[04:07] <mwh_> okay
[04:07] <mwh_> how does the merging bit work?
[04:08] <kiko> mwh_, you just need to request a merge.. let me get you a link
[04:08] <mwh_> okay
[04:08] <kiko> https://launchpad.net/people/+requestmerge
[04:08] <kiko> you enter your test account first
[04:08] <kiko> then your real account 
[04:08] <kiko> click go
[04:08] <kiko> and validate the email token
[04:08] <kiko> easy!
[04:09] <salgado> you just need to enter your test account
[04:09] <mwh_> so, will my account then have two email addresses?
[04:09] <salgado> mwh_, yes, but you can delete any of them afterwards
[04:09] <mwh_> okay
[04:09] <kiko> mwh_, and only one of them will be "preferred"
[04:09] <kiko> the preferred email address is the one which launchpad uses to send you notifications.
[04:10] <kiko> mwh_, do this while logged in as your /main/ account, ok?
[04:10] <mwh_> I can't seem to use staging .. to test if I can use Rosetta .. Rosetta seems to want a user
[04:10] <mwh_> okay
[04:12] <mwh_> kiko, works beautifully .. many thanks!
[04:12] <kiko> mwh_, "want a user"?
[04:12] <kiko> cool.
[04:18] <SteveA> hi mwh_ 
[04:18] <SteveA> are you using launchpad, or the python demo launchpad?
[04:18] <kiko> SteveA, it's not mwh. it's mwh_. :)
[04:18] <mwh_> kiko, yes .. to be able to translate one has to log in
[04:18] <SteveA> mwh_: you're not mwh?
[04:18] <mwh_> anyways hi SteveA
[04:18] <mwh_> SteveA, I'm a mwh
[04:19] <SteveA> do you climb rocks?
[04:19] <kiko> SteveA, what sort of question was that?
[04:19] <mwh_> I think i've lost my nick mwh :( 
[04:19] <SteveA> I guess mwh will have it
[04:19] <kiko> mwh_, mwh is the nick for michael hudson, a core python developer
[04:19] <mwh_> anyways thanks everybody for your help .. ill better get back to work
[04:19] <SteveA> anyway, welcome mwh_ 
[04:19] <mwh_> ah
[04:19] <mwh_> its the initials for my name
[04:19] <mwh_> Martin Willemoes Hansen
[04:19] <mwh_> bye
[04:24] <spiv> salgado: you can, by poking at private attributes
[04:25] <salgado> spiv, do you think it would be of any value? (see my comments right after the message directed to you)
[04:25] <spiv> salgado: I'm not sure it makes a good test; it's kind of equivalent to testing that "a = b" happens as the first statement in a function.
[04:26] <spiv> salgado: it's possibly an argument for moving the "self._deferred = Deferred()" line into the probe method after all :)
[04:27] <spiv> salgado: I'm not sure it's an entirely bad idea, but I don't think I'd do it.
[04:27] <spiv> (write that test, that is)
[04:27] <spiv> salgado: personally, I'd be satisfied with just making the attribute private.
[04:28] <spiv> salgado: if other code is diddling with private attributes, then all bets are off :)
[04:28] <salgado> yeah, after thinking a bit I came to that same conclusion
[04:28] <salgado> I added a comment explaining why we want to make it private, just to make sure it won't ever be turned into a public attribute
[04:29] <salgado> (not sure if it's neccessary, but better safe than sorry)
[04:29] <spiv> Fair enough.
[04:34] <salgado> stub, have you re-enabled the mirror prober for archive mirrors on production?
[04:34] <stub> I never disabled it - it started working on its own
[04:35] <stub> Failed for two or three days but started working again before I disabled it.
[04:35] <salgado> BjornT, bradb, so, if I'm the assignee of a private bug, should I get mail notifications?
[04:35] <SteveA> stub: want to do the blueprint -> features switch?
[04:35] <salgado> stub, well, I asked because I saw a "== Distribution mirror prober disabled ==" in yesterday's nightly.sh output
[04:35] <stub> I'll double check
[04:37] <bradb> salgado: you should, but you won't
[04:37] <stub> Ahh... I was disabling them but only backed out the changes of one of the invokations
[04:37] <bradb> you get bugmail from private bugs only if you're subscribed to the bug
[04:37] <salgado> bradb, is there an open bug for that? should I file it?
[04:37] <bradb> there is, yeah
[04:38] <salgado> ok, just wanted to make sure. thanks bradb!
[04:38] <bradb> salgado: bug 757
[04:38] <Ubugtu> Malone bug 757 in malone "Assignee should be CC'd when assigneed to a private bug" [Medium,Needs info]  https://launchpad.net/bugs/757
[04:53] <kiko> matsubara, /projects/gnome is back in place
[04:54] <matsubara> kiko: I noticed. thanks.
[04:54] <kiko> you're most uberly welcome
[05:01] <SteveA> stub: features?
[05:01] <stub> yeah, yeah
[05:01] <stub> Running rosetta stuff atm
[05:04] <stub> SteveA: Can blueprint_hostname accept a comma seperated list like main_hostname?
[05:04] <SteveA> stub: yes
[05:05] <SteveA> stub: want to get it done while elmo is here and I'm here
[05:05] <SteveA> so we can get urgent admin stuff easily if needed
[05:10] <stub> SteveA: Done. Seems to be working.
[05:11] <SteveA> looking good
[05:11] <SteveA> i'll ask james to do a redirect from blueprint for a bit then
[05:14] <SteveA> stub: it is done
[05:15] <stub> blueprint should continue to work anyway
[05:15] <jordi> stub: thanks for adding all of those plural forms requests!
[05:19] <jordi> carlos, danilos: are we here?
[05:20] <carlos> jordi: yes, we are
[05:20] <danilos> jordi: yup
[05:20] <jordi> let's rock on
[05:21] <jordi> #cm?
[05:21] <carlos> sure
[05:21] <salgado> kiko, have you had time to check https://blueprint.launchpad.net/products/launchpad/+spec/person-creation-rationale?  it has some questions for you. :)
[05:21] <kiko> I know, but I'm very busy this morning. please ping me again in the afternoon
[05:23] <stub> Wah. Something is eating my pqm emails :-(
[05:25] <kiko> stub, that happens when you use the wrong host I think
[05:25] <kiko> or do they never even hit the server?
[05:25] <kiko> salgado, ^^^
[05:26] <stub> pebcak
[05:26] <salgado> ?
[05:26] <kiko> hoho
[05:26] <kiko> salgado, <kiko> I know, but I'm very busy this morning. please ping me again in the afternoon
[05:27] <salgado> kiko, ah, right.  I used the 'Request feedback' link, so I expect you'll get an email about it. :)
[05:27] <kiko> salgado, I'm drowning in email right now
[05:27] <kiko> ---Mutt: /var/mail/kiko [Msgs:487 Post:1 Inc:17 58M] ---(date-received/date)----------------(end)---
[05:28] <salgado> that's good, you'll probably reach this one in the afternoon.  but I'll ping you again if you don't. :)
[05:47] <SteveA> stub: launchpad seems kinda slow from here -- large pause before loading a page
[05:47] <SteveA> is it very busy?
[05:47] <kiko> same here
[06:03] <SteveA> stub: I'm seeing timeouts now
[06:04] <bradb> BjornT: ping
[06:05] <stub> SteveA: On production?
[06:06] <stub> Seems to be ok to me
[06:06] <SteveA> seems better now
[06:06] <SteveA> did you do anything?
[06:07] <stub> Nope
[06:07] <SteveA> how odd
[06:09] <kiko> jamesh, ping?
[06:09] <jamesh> kiko: pong, but won't be round much longer
[06:09] <kiko> jamesh, could you post your bzr blog before leaving?
[06:09] <kiko> jamesh, I'd love to link to it from our bi-weekly announcement
[06:09] <stub> Jubany doesn't seem to be straining - disk io, but not too bad
[06:09] <kiko> and I had text introducing it ready
[06:09] <jamesh> okay.
[06:11] <kiko> thanks
[06:18] <kiko> jamesh, how could I could how many branches have been registered on launchpad? and mirrrored on the SM?
[06:21] <jamesh> kiko: http://blogs.gnome.org/view/jamesh/2006/08/17/1 <- posted
[06:21] <kiko> you rock!
[06:22] <jamesh> kiko: on staging, we have 1204 branches registered total
[06:22] <kiko> how did you find that out?
[06:22] <jamesh> issued a count query
[06:22] <kiko> heh
[06:22] <kiko> "statistics for people who can SQL <tm>"
[06:22] <jamesh> 798 of them are supermirror push branches (i.e. have no URL to pull from)
[06:24] <jamesh> actually, that 798 number includes vcs imports
[06:25] <jamesh> so we've got 543 upstream VCS imports
[06:25] <jamesh> 255 supermirror push branches
[06:26] <jamesh> 406 pull branches (where people have registered the URL where they publish their branch and we mirror it)
[06:26] <kiko> right
[06:26] <kiko> those are pretty impressive numbers, you know
[06:27] <jamesh> we might have some of these stats in the cricket instance, by the way
[06:27] <LarstiQ> how many of those are closely ubuntu/canonical related?
[06:28] <kiko> good point
[06:28] <kiko> LarstiQ, well, look at https://launchpad.net/bazaar/+all-branches
[06:30] <LarstiQ> the first couple of pages are dominated by the said group
[06:30] <LarstiQ> bzr has a fair couple ;)
[06:31] <kiko> there are some cool ones that are kinda unrelated
[06:31] <LarstiQ> yes, like bitlbee
[06:32] <carlos> stub: ok
[06:32] <jamesh> kiko: looks like those numbers I provided are in cricket.  You can see the "hosted branches" and "mirrored branches" numbers increase since we started collecting the data middle of last month
[06:32] <kiko> jamesh, thanks
[06:32] <kiko> stub, carlos: staging down?
[06:32] <stub> carlos: -d ubuntu -r dapper took 14 minutes after I removed the bit that updates the distro
[06:32] <stub> stats
[06:32] <carlos> stub: -d ubuntu -r edgy will take a bit more time
[06:32] <LarstiQ> kiko: I'd be impressed if there were more branches by entirely unrelated people. (Never having even posted a comment to an ubuntu bug, etc)
[06:33] <carlos> kiko: don't know
[06:33] <stub> carlos: Bug -d ubuntu -r edgy is still running after 50 minutes. So two hours might have been optimistic :-(
[06:33] <carlos> stub: which table is being copied atm ?
[06:33] <stub> 15:18:04 INFO    Filling POSubmission table with active submissions...
[06:33] <carlos> kiko: staging is working here
[06:34] <carlos> stub: that's the bigger one
[06:34] <stub> (which was over 1 hour ago)
[06:34] <carlos> stub: and only one more to go
[06:34] <carlos> POSelection
[06:34] <stub> carlos: Yup. I was hoping to go to bed knowing that everything was working and two hours would give us time to spare ;)
[06:35] <kiko> carlos, can I see the spec on the edgy opening?
[06:36] <carlos> kiko: sorry, I forgot it completely....
[06:37] <kiko> carlos, our end-users are pretty upset and I can't just say "it's uhhh late, but almost there". I need to cough up some technical issues.
[06:37] <kiko> because you guys didn't openly discuss this on the mailing list
[06:37] <carlos> kiko: I thought that was the point behind the email I sent to you...
[06:37] <kiko> carlos, your email doesn't say anything very technical
[06:37] <carlos> I mean, I see the spec more an internal thing than something to point our users to...
[06:38] <kiko> it just says "we're late because.. "
[06:38] <kiko> carlos, I'm not going to point our users to it, but I don't know what the issues are myself
[06:38] <kiko> so I can't give them a decent explanation
[06:39] <carlos> well, I really think that for our users the fact that we missed the migration of translations between distro releases is the most technical issue we should tell them
[06:39] <carlos> is not a bug in our side, we could open Edgy like we open Dapper
[06:39] <kiko> a technical issue that explains the delay would be good.
[06:39] <carlos> is just that we wanted to give them more content and save them some work...
[06:40] <carlos> kiko: well, I could give you an excuse... but I think that just saying that we didn't have the migration implemented is a good reason
[06:40] <kiko> and it took 2 months?!
[06:40] <kiko> that sounds kinda.. wrong
[06:41] <kiko> anyway, try and send me the spec
[06:41] <kiko> don't need to overdo it
[06:41] <kiko> just a simple outline of what needed doing and how it was done.
[06:41] <carlos> one month between testing, a sprint, a week of holidays (danilo doesn't have the needed rights to do the needed checks)....
[06:42] <carlos> I started with this task later than I should
[06:42] <carlos> kiko-fud: so that's your way to say 'I need more than what you sent me' ;-)
[06:43] <carlos> just say that directly and I will be happy to prepare something else for you :-)
[06:43] <kiko-fud> I'm trying to explain why I need it though :)
[06:46] <carlos> ok
[06:46] <danilos> kiko-fud: well, it turned out not to be so simple to do testing and everything with that amount of data
[06:54] <carlos> will be back in one hour or so
[06:56] <sfllaw> bradb: Ping.
[06:56] <stub> carlos: https://sodium.ubuntu.com/~andrew/paste/fileX52tKs.html
[06:57] <sfllaw> bradb: Malone seems to collapse whitespace.  This is not so good...
[06:57] <sfllaw> https://launchpad.net/distros/ubuntu/+source/apt/+bug/56125
[06:57] <Ubugtu> Malone bug 56125 in apt "doesnt look like a cow" [Unknown,Unconfirmed]  
[06:57] <stub> Looks like tomorrow won't be a go
[07:02] <carlos> :-(
[07:08] <stub> carlos: Is that a new one, or was I running with an old tree?
[07:09] <stub> (should have been up to date - was running from the staging tree)
[07:09] <carlos> stub: well, if it failed at that point, I think it's a new one
[07:10] <carlos> stub: the fact that staging takes so much time to do this data copy is not helping at all :-(
[07:10] <stub> carlos: You have access to launchpad_test on jubany from both the launchpad and carlos accounts on asuka
[07:10] <carlos> ok, thanks
[07:11] <carlos> I will use it to debug this problem
[07:11] <carlos> stub: how long did it take to raise the problem?
[07:11] <stub> As the ro and rosettaadmin users - that enough?
[07:11] <carlos> if it's the same as the rights I had in carbon, it's enough
[07:12] <stub> 0 - 10 minutes into the  Filling POSelection table step
[07:13] <carlos> I mean since the whole process started
[07:13] <stub> All the times up to that point are in the pastebin
[07:13] <carlos> ok
[07:13] <carlos> right
[07:14] <carlos> well, from that output, we know that we will need more than 2 hours...
[07:14] <carlos> stub: does it mean that we also need the Rosetta Read Only mode ?
[07:15] <carlos> SteveA: ^^^
[07:15] <SteveA> hello carlos
[07:15] <stub> Should be ok. We want to land this soon, so I'd rather avoid more coding
[07:15] <SteveA> stub knows the score, so if we can do it in reasonable downtime, we should
[07:15] <stub> Looks like 2.5 - 3 hours - will know after we test
[07:16] <carlos> stub: well, the process would take at least 3 hours ....
[07:16] <carlos> ok, if that's still fine...
[07:16] <stub> Fix code, test and time, then we make the call.
[07:16] <carlos> stub: I will work on a fix today, perhaps, if I get a full run tonight we could do something tomorrow....
[07:18] <stub> fix + tests + confirming it worked? You would be lucky or trying to do the confirmation when too tired I imagine.
[07:18] <stub> I'd rather not schedule a 3 hour downtime window only to find we are not ready or we need 4 hours.
[07:20] <carlos> stub: well, I think I will try to get this fixed tonight, even if I go to sleep late
[07:20] <carlos> stub: If I don't get a full run
[07:20] <carlos> without errors
[07:20] <carlos> I'm not going to ask to shutdown launchpad
[07:21] <bradb> sfllaw: pong
[07:22] <carlos> SteveA: at least if you agree with that. 
[07:22] <bradb> sfllaw: what problem am i looking for on that page, specifically?
[07:23] <sfllaw> The whitespace has been munged.
[07:23] <sfllaw> I suppose it's not important for ASCII art.
[07:23] <kiko-fud> sfllaw, no
[07:23] <sfllaw> But is probably more important for copy-past patches.
[07:23] <sfllaw> paste
[07:23] <kiko-fud> sfllaw, it hasn't been munged. your browser munges it
[07:24] <kiko-fud> because whitespace is collapsed in HTML
[07:24] <kiko-fud> even when using a fixed-width font
[07:24] <sfllaw> I suppose substituting &nbsp; is uncool?
[07:24] <kiko-fud> I'm not sure, but I added a launchpad task and sic'd mpt on it
[07:25] <bradb> kiko-fud: dude, that bug doesn't affect launchpad! :P
[07:25] <kiko-fud> bradb, it sort of does. it doesn't look like a cow in launchpad either! :)
[07:25] <bradb> haha
[07:26] <kiko-fud> that was kinda illegal
[07:26] <kiko-fud> but it was fun!
[07:26] <kiko> as most illegal things are
[07:26] <bradb> indeed
[07:27] <kiko> such a geeky thing to be joking about though
[07:28] <kiko> 489 emails
[07:28] <kiko> wtf have I done to deserve this
[07:30] <mdz> why are we now mailing notifications to edgy-changes of every binary build?  previously it was only source uploads and that was exactly what we wanted
[07:30] <mdz> (speaking of excessive numbers of emails)
[07:30] <kiko> mdz, that's a bug, I just r=kiko'd malcc's patch
[07:30] <mdz> ok
[07:30] <kiko> it should go live shortly after hitting RF
[07:31] <kiko> with a test and an assertion.
[07:31] <mdz> did that come in with the build-failure-process stuff?
[07:31] <mdz> (which I'm very excited about btw)
[07:31] <kiko> it comes in the same batch
[07:31] <kiko> and that's one of the things I would like to talk to you about
[07:32] <kiko> mdz, let's see if you and I can chat in 1h
[07:32] <kiko> I need to send this release off.
[07:32] <mdz> kiko: I'm expecting a call from mark around then
[07:32] <mdz> and will need to leave for the airport not long after
[07:32] <mdz> but I will answer if I am available
[07:32] <kiko> hmmm
[07:33] <kiko> I'll try and make it before that then
[07:35] <kiko> carlos, btw, have you given end-users a request to test edgy translations on staging? or won't that work?
[07:37] <carlos> kiko: well, given the fact that doing that on staging would take around 8-9 hours (even more)
[07:38] <kiko> carlos, it would be nice to have them up there for testing
[07:38] <jordi> carlos, danilos: my desktop, which is my main work box, just died with a fun xfs error message
[07:38] <kiko> or are you 100% sure that nothing bad will happen in the edgy opening?
[07:38] <carlos> and just in case you didn't see it, latest test by stuart failed again (a bug that is not covered by our tests)
[07:38] <carlos> is a bit hard...
[07:38] <kiko> carlos, I saw, I saw
[07:39] <carlos> kiko: well, I don't think we are going to have any data lose if that's what you suggest
[07:39] <kiko> carlos, or data imported in the wrong place.
[07:39] <carlos> kiko: well, that kind of test is covered by our tests
[07:40] <carlos> in fact the only problem we are having seems to be with having more than one potemplate with the same potemplatename
[07:40] <stub> I don't mind disabling staging db updates for a few days or a week while people checkout the migration
[07:40] <stub> And on that note...
[07:41] <carlos> which cause duplicated rows if the queries are not right
[07:41] <carlos> stub: good night
[07:43] <kiko> carlos, how good is our test coverage, though? I am surprised we have crashes in the process...
[07:43] <carlos> kiko: we have crashes by duplicated entries
[07:43] <carlos> that depend on real data 
[07:43] <carlos> kiko: I discussed the testing phase with a preimplementation call with Andrew
[07:44] <carlos> and what we do is to export .pot and .po files
[07:44] <carlos> and get a diff
[07:44] <kiko> I see.
[07:44] <kiko> that's a good idea.
[07:44] <carlos> between the parent distribution and the new one
[07:44] <kiko> we haven't done that yet, right?
[07:44] <kiko> would that be the next step?
[07:44] <carlos> so we should get no changes or just the changes we forced
[07:44] <kiko> if this process hadn't failed?
[07:44] <carlos> kiko: it's done
[07:44] <kiko> ah, really?
[07:44] <kiko> well, done with what data?
[07:44] <carlos> otherwise we wouldn't get that code in rocketfuel
[07:44] <kiko> not with production data.. right?
[07:45] <carlos> no, with sampledata
[07:45] <kiko> that test should be done with production data, ideally.
[07:45] <kiko> sampledata is rubbish
[07:45] <kiko> the real data, that's where the bugs come out
[07:45] <carlos> I could do such test, yes
[07:45] <carlos> but I don't really know the amount of time it would take
[07:45] <carlos> let me fix the queries first
[07:45] <kiko> that could avoid us having to come in and patch the broken data afterwards.
[07:45] <kiko> sure.
[07:46] <carlos> and once it's done I will prepare such tests (it's a matter of getting what we have in our doctests)
[07:46] <kiko> good man
[07:47] <carlos> later!
[08:19] <kiko> https://sodium.ubuntu.com/~andrew/paste/filew4uOPs.html
[08:19] <kiko> feedback appreciated!
[08:39] <LarstiQ> kiko: all I can say is, devpad!
[08:39] <kiko> I like chemistry
[08:41] <LarstiQ> on account of not having access anyway, it's the same to me.
[08:42] <kiko> LarstiQ, are you offering to review?
[08:47] <LarstiQ> kiko: I'm willing to look at it, but I don't know what it is beforehand.
[08:47] <LarstiQ> And I'm sure you know I'm not an lp dev
[08:47] <LarstiQ> so, I'm not promising I'm competent to do so :)
[08:48] <kiko> LarstiQ, one sec
[08:52] <kiko> http://pastebin.de/11073
[08:53] <kiko> LarstiQ, ^^^
[08:53] <kiko> Seveas!!!
[08:53] <Seveas> kiko!!!
[08:53] <kiko> Seveas, ubugtu must be in a world of spam by now!
[08:53] <Seveas> oh my
[08:53] <Seveas> what did you do?
[08:54] <kiko> I did what I said I was going to do
[08:54] <kiko> send launchpad bugs to it!
[08:54] <Seveas> nice
[08:54] <kiko> it's not doing anything with them though. I think.
[08:54] <Seveas> correct
[08:54] <Seveas> it currently knows bug 999999 to be the latest
[08:54] <Seveas> so I'm going to see what the latest is ;)
[08:55] <kiko> heh
[08:56] <Seveas> I did that on purpose or it would have been flooding A LOT when you switched it on
[08:57] <kiko> really? 
[08:57] <Seveas> yeah
[08:57] <LarstiQ> 'and doing acceptance testing the results.' Is there a word missing there?
[08:58] <Seveas> it can't really tell new bugs from old bugs (hard to do with current bugmail format), so it remembers the number of the last bug
[08:58] <Seveas> but when you switch it on it receives all bugmail, also replies to older bugs ;)
[08:58] <Seveas> anyway, it should now work -- I'll file a test bug
[08:59] <LarstiQ> kiko: and 'causing uploaded packages to be processed 30% less time.' ITYM 'in 30% less time'?
[08:59] <kiko> LarstiQ, yep
[08:59] <kiko> Seveas, let's just wait
[08:59] <kiko> it'll happen... :)
[08:59] <Seveas> hehe, ok
[08:59] <kiko> well
[08:59] <kiko> unless you have a bug to report!
[09:00] <Seveas> yeah
[09:00] <Seveas> bugmail spam!
[09:00] <LarstiQ> kiko: this is more verbose than your usual report to l-u, this is for a different audience? (also considering a link to the list, probably)
[09:00] <Seveas> actually, soyuz spam, all uploads are spammed several time (for every binary)
[09:00] <kiko> LarstiQ, it will go to l-u. it's the "new" report. :)
[09:01] <kiko> Seveas, I just reviewed a fix for that
[09:01] <LarstiQ> kiko: overall it is a good read, though in some places it suddenly switches topic
[09:01] <kiko> LarstiQ, it's just the highlights
[09:01] <Seveas> kiko, I expected it to be filed already ;)
[09:01] <kiko> there's 200 lines of changes under it
[09:01] <kiko> Seveas, yeah, it is
[09:02] <LarstiQ> kiko: anything specific you'd want me to check?
[09:02] <kiko> LarstiQ, just if it's interesting
[09:03] <LarstiQ> sure, but I'm not the most representative user
[09:03] <Seveas> @config channel plugins.bugtracker.bugreporter
[09:03] <Ubugtu> /home/dennis/ubugtu/data/bugmail-lp
[09:03] <LarstiQ> kiko: the per application domains hint makes me thirst for more :)
[09:04] <kiko> LarstiQ, that's the intention! dehydrate our users!
[09:05] <LarstiQ> kiko: on the edgy translations, I think the explanation is sufficient to calm people.
[09:30] <kiko> LarstiQ, thanks for saying that.
[09:31] <LarstiQ> kiko: well, it would be for me.
[09:32] <LarstiQ> kiko: we'll see how it goes, but I have confidence this is good
[09:32] <kiko> :)
[09:40] <Keybuk> who does rosetta translation tarball exports?
[09:44] <kiko> Keybuk, do you mean non-automatic ones?
[09:45] <Keybuk> yeah, upstream ones
[09:45] <kiko> I think end-users just request them and an offline process generates them
[09:45] <Keybuk> right, I mean who maintains that bit of code
[09:45] <kiko> Keybuk, oh! carlos.
[09:45] <Keybuk> sorry
[09:46] <Keybuk> thanks
[09:46] <kiko> Seveas, no bugs so far! we rock!
[09:46] <carlos> Keybuk: danilos and I maintain it
[09:47] <Keybuk> carlos: you don't use the template comments and stuff from the package/
[09:48] <carlos> Keybuk: the ones inside the .pot file?
[09:48] <Keybuk> yeah
[09:48] <carlos> Keybuk: we use them
[09:48] <Keybuk> in Makevars
[09:48] <carlos> oh
[09:48] <Keybuk> hmm, the generated one here doesn't have them
[09:48] <carlos> that ones
[09:48] <carlos> we don't read Makevars
[09:49] <carlos> we just get the .pot files that the .deb build generate for us
[10:38] <rodarvus> hi
[10:38] <rodarvus> I'm trying to push a bzr branch into a group I recently created, but it seems to fail:
[10:39] <rodarvus> rodarvus@wakko:~/work/glib/glib-objc$ bzr push --create-prefix sftp://bazaar.launchpad.net/~glib-objc/trunk
[10:39] <rodarvus> bzr: ERROR: Permission denied: u'~glib-objc': [Errno 13]  Branches must be inside a person or team directory.
[10:39] <rodarvus> rodarvus@wakko:~/work/glib/glib-objc$
[10:39] <rodarvus> do I need to give LP some time to acknowledge the team was created, or I'm just doing something wrong?
[10:39] <salgado> rodarvus, looks like the path is wrong
[10:39] <LarstiQ> rodarvus: you are missing a branch name
[10:39] <LarstiQ> or team
[10:40] <salgado> rodarvus, what's the team name?
[10:40] <rodarvus> team name is ~glib-objc
[10:40] <rodarvus> sorry, glib-objc
[10:40] <LarstiQ> a product then :)
[10:40] <rodarvus> oh, I need to add a product, dang
[10:40] <rodarvus> :)
[10:40] <salgado> ~glib-objc/product/branch, yes
[10:40] <LarstiQ> sftp://bazaar.launchpad.net/~teamname/productname/branchname
[10:41] <rodarvus> hmm, no
[10:41] <rodarvus> bzr push --create-prefix sftp://bazaar.launchpad.net/~glib-objc/glib-objc/trunk fails too
[10:41] <kiko> rodarvus: http://blogs.gnome.org/view/jamesh/2006/08/17/1
[10:41] <rodarvus> kiko, I'm following jamesh's blog instructions :)
[10:41] <rodarvus> (but I probably missed something)
[10:42] <LarstiQ> rodarvus: glibc-objc as team name, or glib-objc?
[10:42] <rodarvus> glib-objc
[10:42] <LarstiQ> rodarvus: the registrant for product/glib-objc seems to be glibc-objc
[10:42] <rodarvus> https://launchpad.net/people/glibc-objc
[10:43] <LarstiQ> rodarvus: right, so don't forget the c
[10:43] <rodarvus> LarstiQ, the 'c' shouldn't be there :)
[10:43] <rodarvus> thanks guys
[10:43] <LarstiQ> rodarvus: I admit I found it a bit confusing :)
[11:00] <Ubugtu> New bug reported: Malone bug 56747 in soyuz "Special handling for "single custom" uploads is an abomination" [Untriaged,Unconfirmed]  https://launchpad.net/bugs/56747
[11:04] <Seveas> kiko!!
[11:04] <Seveas> it appears to work
[11:04] <kiko> OMG!!!
[11:05] <kiko> who is filing these abominations!!!
[11:05] <Seveas> hehe
[11:05] <kiko> make them stop Seveas 
[11:06] <Seveas> Hmm, you can poke Malcolm once he gets back from showering
[11:07] <LarstiQ> does it make sense to put the reporter on that too?
[11:07] <LarstiQ> 18:50:41 < SkitIDet> Mantis: dangertools modified bug #1003: Javabindings rebuilds without new changes | http://bugs.xmms2.xmms.se/view.php?id=1003
[11:07] <Seveas> i don't think so
[11:07] <Ubugtu> Malone bug 1003 in launchpad "projects +search page 404" [Medium,Fix released]  https://launchpad.net/bugs/1003
[11:08] <LarstiQ> is what I'm used to from xmms2
[11:08] <Seveas> heh
[11:08] <Seveas> I am NOT going to spam all bug modifications
[11:08] <Seveas> kiko will kill me if I do that
[11:09] <LarstiQ> right, I couldn't find an instance of a new bug so quickly
[11:09] <Seveas> I'm now just doing it quite lazy
[11:09] <LarstiQ> but that occurs a lot less
[11:10] <Seveas> I figure out the bug number from the incoming mail (mailaddress) and simply use the already existing functionality to grab a bug summary/status 
[11:11] <Seveas> anyway, it's apparently working so enjoy the spam -- I'm off for the night
[11:11] <LarstiQ> slaapze
[11:11] <Seveas> dank
[11:14] <kiko> LarstiQ, definitely, include the reporter's displayname
[11:15] <kiko> LarstiQ, but not email address please
[11:16] <kiko> anyway not ABD
[11:31] <doko> kiko: have to raise my karma ;-P do I get the same amount for rejecting and releasing a fix for a report?
[11:33] <kiko> doko: I'm not allowed to tell you. :)
[11:40] <LarstiQ> haha
[11:44] <sabdfl> night all
[11:44] <LarstiQ> night sabdfl 
[12:00] <DarkMageZ> is there a way to subscribe to a source package to get notifications on when a new version is released?
[12:01] <kiko> DarkMageZ, not yet, no
[12:01] <kiko> best way is to look at edgy-changes right now
[12:01] <DarkMageZ> yeah, i've been checking daily manually :)
[12:02] <DarkMageZ> but is it planned?
[12:03] <kiko> DarkMageZ, it definitely is planned
[12:05] <DarkMageZ> sweet :) ty