=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [01:02] kiko: hmm, what about subsections of bugtrackers, are they possible too? [01:03] LarstiQ, what do you mean? [01:06] reacting on your bugtracker mail to l-u [01:06] kiko: registering that a certain product uses a bugtracker [01:07] hmja === LarstiQ needs to put more thought into this [01:07] LarstiQ, yes, I realize, but what do you mean by "subsections of bugtrackers"? :) [01:08] kiko: bugs.debian.org/package, but I guess the bugnamespace is the same regardeless [01:08] 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 === LarstiQ nods [01:09] kiko: for some reason I keep thinking of wikis with subpages, but I'm not aware of a bts using that [01:09] :) [01:09] so just disregard that question then :) [01:09] how about distributed ones though? :) [01:09] like Bugs Everywhere [01:10] BjornT: ping [01:10] heh === Fujitsu [n=Fujitsu@203.23.49.35] has joined #launchpad [01:53] jamesh, where are you going to post that blog post? [01:56] kiko: drive-by for bug 56618? [01:56] Malone bug 56618 in malone "Milestone restrictions are too restrictive for Ubuntu" [Critical,In progress] https://launchpad.net/bugs/56618 [01:56] bradb, argh, not tonight, i've been at the wheel for 10h [01:56] ok, can i give you a url for now? [01:57] bradb: i'll take it [01:57] https://sodium.ubuntu.com/~andrew/paste/fileEHhd0F.html . first come, first serve! [01:58] on me, then [01:58] woohoo [01:59] bradb: do you know about launchpad.Drivers? [02:00] sabdfl: I know about the drivers attribute on IDistribution and IProduct. I don't know what exactly launchpad.Drivers refers to. [02:00] launchpad.Drivers is a permission, like launchpad.Edit, which a person can have on a series or distrorelease [02:00] it means "i can target work to this puppy" [02:00] ah [02:00] "i can drive the goals and bugs" [02:01] so when you are doing nomination and approval of bugs to distrorelease/series, please use launchpad.Drivers [02:01] noted [02:02] and in this case, use launchpad.Drivers on milestone.productseries or milestone.distrorelease [02:02] however, please file a bug that this is only temporary [02:02] once you have nomination and approval of bugs for series/distroreleases, drop restrictions on milestone targeting [02:03] ok [02:04] you'll need to add a test that the driver can do this [02:04] right [02:04] you may want to discuss with kiko if you should s/bugcontact/driver/, or just add driver as well === jml [n=njml@203-217-8-89.perm.iinet.net.au] has joined #launchpad [02:04] subscribe me to the bug, and then r=sabdfl === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [02:05] i like the fact that we're starting to do conditionally-editable form fields, btw, nice work [02:05] we need to generalise that so it's less of a behind the scenes hack [02:05] will you work with the LAZR team on how it should feel, as a developer? [02:05] sabdfl: I thought that, using launchpad.Driver permission, would mean including the bugcontact in the checker? [02:06] sabdfl: sure, that'd be cool [02:06] 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] bugcontact should not have launchpad.Driver [02:06] I think it's no /problem/ to make it drivers as well but that will be pretty obscure [02:06] agreed entirely on that [02:06] oh, that is indeed a conflict then with what the bug report asked for [02:06] kiko: really? was that not requested before mdz understood the drivers? [02:07] is it not trivial for him to get it right on his side? [02:07] why entrench the wrong thing in the code, just because of that request? [02:07] sabdfl, mdz didn't update the bug report, nor did he request us change the rationale, so... [02:07] I'm not sure it's actually wrong, though [02:07] bugcontact is not "i decide when work gets done", is it? [02:08] sabdfl, it's currently "I decide what importance something has". [02:08] which is a group that is good enough for mdz right now [02:08] we need to have a formal approach to "new roles on objects" [02:08] hah, agreed entirely [02:08] it's not good enough for me, i'm afraid [02:08] i don't want to entrench things that are not right [02:08] i'd rather fix them [02:09] bug contact is bug contact, drivers is a role that determines priorities and go/no-go [02:09] that's well defined, and there's lots of code that uses it consistently that way in blueprint [02:09] well... [02:09] it's straightforward to get it right, now, in malone [02:09] 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] yes, exactly [02:10] 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] if we want to go ahead and start using drivers for this now [02:10] ddaa: did you copy and paste an existing branch on pending-reviews ? [02:10] kiko: that's not true, i'm afraid, we discussed drivers in the docklands at some length [02:11] 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] it may have been discussed. it was never posted to the list, nor is there any paper trail of the new role [02:11] lifeless: no, I cut it from work-in-progress and pasted it in pending-reviews [02:11] and without a paper trail, we all forget [02:11] ok [02:11] cool [02:11] lifeless: I should reset the date when I do that? [02:11] and there is no way to bind people together around what we need to do [02:11] review team are going to go 'whoa' today [02:11] 5 new reviews [02:12] https://sodium.ubuntu.com/~andrew/paste/fileHm1pQb.html [02:12] kiko: ^ [02:12] I've got another 1800 lines monster almost finished. [02:12] ddaa: if you can make them smaller, but more frequent, I'm sure that would be appreciated [02:12] I want to keep my reviewers busy while I'm away :) [02:12] there was also extensive discussion between stevea and myself about the new permission [02:12] sabdfl, that's not developer consensus, though [02:12] I agree it's in our codebase [02:12] lifeless: in try usually, but in the case of those patches, it was not really possible [02:12] but that fact that it's in there and some developers don't know they are meant to use it [02:12] that was just two important, large, and hard to split features [02:12] means we didn't take a good approach to defining and using the new role [02:13] I feel very strongly about this! I hate to find things out through landings! [02:13] and I'm also zzz tired [02:13] come on, kiko, we discussed it AT LENGTH in the docklands, and it's very well documented [02:13] lifeless: one in making branch/+edit not suck anymore, the other is basically adding a new component in importd. [02:14] (sabdfl: i subscribed you to bug 56650) [02:14] 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] ddaa: they've been assigned ot reviewers now [02:15] I'll ping you for the new one if I finish it before leaving [02:16] kiko, sabdfl: please confirm whether this fix should change to use launchpad.Drivers or remain as is, when you're ready === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [02:26] 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] kiko: will do [02:27] actually [02:27] grumble [02:27] ? [02:27] bradb, I'm not sure if drivers makes all the sense for importance. this is annoying. [02:27] i think drivers needs an unambiguous name [02:28] I can call matt, give me a moment [02:28] if we were saying release_managers, i'd know what we were talking about [02:28] yeah, could be. === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [02:30] bradb: didn't use release_manager because that will be used for tarballs / cd images [02:30] or are ems a d-inq has them: http://liw.iki.fi/liw/log/2006-08.html#20060816b [02:30] 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] sabdfl: though we've been using release management to describe targeting bugs to things [02:31] yes === freeflying [n=freeflyi@ubuntu/member/freeflying] has joined #launchpad [02:32] 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] driver = Choice( [02:32] title=_("Driver"), [02:32] description=_( [02:32] "The person or team responsible for decisions about features " [02:32] "and bugs that will be targeted to this release of the " [02:32] "distribution."), [02:32] pretty clear on the web form, though ;-) [02:32] sabdfl: on the web form is says "Driver": https://launchpad.net/distros/ubuntu [02:33] well, web page [02:33] where people would most likely first encounter that term [02:33] 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 === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad [02:33] 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] that's why we don't use launchpad.Edit [02:34] I don't care what role is used for it so long as it isn't overloaded with ridiculous privileges [02:34] we have a distinct permission [02:34] it was specifically created to deal with this [02:34] mdz, what of other things that the drivers can do, such as targeting specs to releases? and targeting bugs to releases? [02:34] it is logical to me for it to be a QA role but I am not interested in arguing, only in fixing the problem === bradb throws out "planners" into the air [02:34] kiko: don't care [02:34] kiko: backport commitments [02:34] right [02:34] release_planners [02:34] I will gladly pay that price [02:35] please, let's stick with drivers till we can have a face to face on it [02:35] mdz, perhaps you could explain how you importance and milestone are managed to make it clearer [02:35] s/how you/how your/ [02:35] bradb: well, I see drivers as the driving force for direction [02:35] LarstiQ, bradb: [ot] for now [02:36] kiko: I am not interested in arguing about what i think is the correct solution. that is a losing battle [02:36] at this point I only care about fixing the bug [02:36] removing the access control entirely is 100% OK with me [02:36] in order to fix the immediate problem [02:36] would that avoid this discussion? [02:37] removing it entirely would be easiest [02:37] and i could close a bug :P [02:37] mdz: you'll have a zillion bugs targeted to edgy before you know it [02:37] mdz, one question: is the bug that the bug /assignee/ cannot set the milestone? [02:37] sabdfl: it will be less work for me to fix those by hand than to argue this [02:38] kiko: no. the bug is that the development team cannot set the milestone [02:38] can i make a proposal? [02:38] aha. [02:38] as written in the bug report [02:38] I just wanted to disambiguate. [02:38] mdz: do you want anyone in the distro team to be able to set the importance and milestone on ANY bug? [02:38] or just on the bugs they are assigned? [02:38] sabdfl: absolutely yes [02:38] to the first question [02:38] on any distro bug, yes, that's what he just said. [02:39] ok, then make them drivers [02:39] on edgy, not dapper [02:40] done [02:40] hm, will using launchpad.Driver mean a project can't do release management if they don't have a driver set? [02:40] I can't test whether the problem is fixed now though [02:40] er, now there are two drivers. how do I remove the old one? [02:40] bradb, we fall back to the owner. [02:40] bradb: no, it falls back to the distro/product/project owner [02:40] ok, cool [02:40] yes ;-) [02:40] one trick [02:40] there is a distro/distrorelease attribute ".driver" [02:41] don't use that [02:41] sabdfl: how do I remove a driver from the list? [02:41] i can check_permission launchpad.Driver easily enough [02:41] use "for driver in distrorelease.drivers: if user.inTeam(driver) return True" [02:41] bradb: yes, that will do that correctly [02:41] 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] oh [02:42] use a team if you want more control [02:42] the display is a bit confusing [02:42] that it is, yes [02:42] it said Ubuntu Drivers before, and now it says Ubuntu Drivers and Ubuntu Core Development Team [02:42] sabdfl, what distrorelease, exactly? [02:42] which made me think it was a set [02:42] i recommend a small team on distro (you and core, trusted folks) and then a bigger team on the current dev release [02:42] bradb, check_permission on what? [02:43] on stable releases, use a tight backport-oriented team, like [pitti, kees] [02:43] bradb, on IBugTask.target? [02:43] bugtask.target [02:43] sabdfl, well, he will need to add the security wrappers then [02:43] that can be a distributionsourcepackage though too...will that work? [02:43] hmm... no [02:43] because there is none for Distribution or DSP. [02:44] i was thinking distrorelease, distribution, product, in that order [02:44] mdz: did you set a driver on the Distro? [02:44] (and productseries, when i land that support with RM) [02:44] if drivers is set, is the registrant no longer allowed to drive? Or should it also be displayed in the union? [02:44] sabdfl: I did not [02:45] 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] I don't know what that will do and have no immediate problem to solve by doing so [02:45] cute [02:45] LarstiQ: the registrant is responsible until (s)he delegates this to a driver [02:46] if the registrant wants to stay in that loop (s)he can be on the team set as a driver === LarstiQ nods [02:46] sabdfl: so the display is correct, but the intent wasn't clear. ok. [02:47] mdz: setting a driver on the distro will allow that team to driver ANY release [02:47] so keep it tight [02:47] sabdfl, kiko-zzz: so, launchpad.Driver for both importance and milestone? [02:47] I have no reason to set one [02:47] bradb, even if you add the security wrapper I don't see how that will work [02:47] well [02:47] mdz: you have an implicit one in the Distro.owner anyhow, which is the techboard [02:48] unless mdz sets the drivers of the distribution to be his dev team [02:48] one day it would be nice to have a document explaining the privileges associated with these various roles [02:48] instead of a document it might be better if launchpad itself made it clear in the UI === bradb agrees [02:48] is there any way I can test whether the original problem is fixed? [02:48] 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] sabdfl, but seb128 isn't on the tech board [02:49] and these bugs are on a distro, not on a distrorelease [02:49] https://help.launchpad.net/BlueprintRoles [02:49] mdz: not tonight, unfortunately. the patch is still being cooked. [02:49] see "Project drivers" [02:49] so launchpad.Driver(distribution) won't work.. [02:49] bradb: ???!!! [02:49] I was told to do this in order to solve my problem [02:49] kiko-zzz: hence, i'm suggesting that mdz set a driver on the distro [02:49] but seb128 is in core-dev, which is now the edgy driver [02:49] sabdfl, right, I missed that then [02:50] sabdfl, but even being the edgy driver, will that give them launchpad.Driver on the distribution? [02:50] does the distrorelease driver have permission to set milestones on bugs, now, in production, or do we still need a patch? [02:50] kiko, mdz: see that doc, it explains it in some detail [02:50] you still need a patch [02:50] sigh [02:51] the only way to solve is tonight is mess with owners [02:51] how about if I add everyone to techboard instead? [02:51] I think that would fix it [02:51] that would work, yes [02:51] sabdfl, did you answer that question I posted above? [02:52] (given what i understand of the code, from reviewing the patch to fix it :-)) [02:52] kiko-zzz: sorry, no, it won't [02:52] just on the release [02:52] mdz: you can even set up your drivers team correctly, then add that to the owner team [02:52] 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] sabdfl, so that doesn't solve our problem, does it? [02:52] mdz: add core-dev to techboard [02:53] sabdfl: what privileges do I grant them by doing that, apart from setting milestones on bugs? [02:53] 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] EVERYTHING [02:53] you guys are crazy [02:53] can you be more specific? what's the worst case scenario? [02:53] creating releases [02:53] not [02:53] distro.owner can https://launchpad.net/distros/ubuntu/+addrelease [02:53] hmm... no [02:54] he can't [02:54] i think that's locked down to launchpad.Admins [02:54] it's ok then [02:54] DOIT [02:54] ok, so launchpad.Driver for *both* importance and milestone? [02:54] yes please [02:54] 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] the only way I can see this working is him setting drivers for ubuntu [02:55] it won't which is why i recommended a short term fix of adding core-dev to techboard [02:55] what's the proper fix? [02:55] sabdfl: and it should be checked on 1. distrorelease, or if None, then 2. distribution, or if None, then 3. product? [02:55] techboard is distro.owner, therefor has launchpad.Edit, and should meet the current code's requirements [02:55] changing the owner seems cleaner than adding to techboard [02:55] sabdfl, on target. [02:55] bradb: sounds right [02:55] do I change the owner of ubuntu or ubuntu/edgy? [02:55] err [02:55] sabdfl: ok, thanks [02:56] bradb, on target, and add the specific security wrappers? [02:56] jesus [02:56] hrm [02:56] this is crazy [02:56] mdz: don't change the owner, just add them to techboard [02:56]

what's the proper fix? [02:56] they aren't members of techboard and I can't be sure where else in launchpad techboard is granted privileges [02:56] I repeat, what is the proper fix once the patch is rolled out? [02:56] techboard is owner of a bunch of teams, for example [02:56] kiko-zzz: so, yeah, i could define launchpad.Driver for IDistributionSourcePackage and ISourcePackage [02:56] kiko-zzz: I have pulled my ejection handle on that discussion, I'm sorry [02:56] ok, then make core-dev the distro owner [02:57] confirm: distro, not distrorelease? [02:57] mdz: only bradb can confirm, he knows the current code, but i think so, yes [02:57] distro [02:57] bradb: confirm: distro, not distrorelease? [02:57] kiko-zzz: the proper fix is to have drivers setup appropriately, and code check that at appropriate times [02:57] so: [02:57] mdz: for what, sorry? [02:58] - core senior dev's have driver on distro (they can drive ANY release) [02:58] bradb: to grant privileges for setting milestones on bugs [02:58] mdz: yeah, distribution.owner [02:58] - most or trusted devs have driver on current development release (edgy) [02:58] DONE [02:58] - security team have driver on stable releases [02:58] sabdfl, but these tasks are on pure ubuntu. they are not on any release. [02:58] so, mdz can approve a bug to be fixed in a stable release [02:58] so can pitti [02:59] mdz can approve a bug to be fixed in edgy [02:59] so can any edgy dev [02:59] I understand the idea, but how does this allow mdz to do what he wants now? [02:59] hmm... interesting, because it was designed for approvals of nominated bugs, and on DISTRO tasks there is no nomination [03:00] that's why i think bugtask.assignee should be able to set importance too [03:00] so core trusted devs have driver on distro and therefor can set importance, as can folks on their own bugs [03:00] the aggregate would be correct [03:00] drivers can override assignee at any time? [03:01] mdz, is this just core devs, or any devs? [03:01] lalalala, I can't hear any of this [03:01] 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] mdz: did you read the documentation i pointed out? [03:02] I glanced at it only long enough to determine that it was not relevant to the problem I was trying to solve [03:03] well, have a read there, then i think it will be clearer how this should work [03:03] 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] not sure i follow you [03:04] 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] sounds like customisable fields, to me [03:05] 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] is there any way I can test whether my latest change has had the desired effect? [03:05] ubuntu-core-dev is mostly asleep or away except for me, and I have additional privileges [03:05] 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] mdz: hang on, i'll give you a way once i look at the config... [03:05] bet [03:07] sabdfl, how would we solve that bet? [03:07] 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] 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] Malone bug 21574 in linux-source-2.6.15 "sound gone after resuming from sleep on hp nx8220" [Medium,Confirmed] [03:08] mdz: from there, just canvas people in https://launchpad.net/people/ubuntu-core-dev to see if they can too [03:08] 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] in this case, that would seem to solve the problem [03:08] sabdfl, yes, it may solve the problem nicely in that case. [03:09] 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] though I'm not sure the implementation of that is straightforward [03:09] and in general, mdz wants the whole team to be drivers of the devel distro release [03:09] mdz: er, hm, mostly asleep eh... [03:10] kiko-zzz: betcha it's less than 15 lines of code ;-) [03:10] bradb: even though I'm a launchpad admin and god knows what else? [03:10] mdz: you can add then remove me from that time too, and i can check [03:10] 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] yeah, that's the trnouwtrouble [03:10] s/that time/that team/ [03:10] I'm sorry if that's not the case, but that's what it appears to be [03:11] the trouble here is that there are two incompatible points of view represented here [03:11] I don't think mdz wants seb to be need to approve nominated edgy bugs or specifications. [03:11] I think he does however want seb to be allowed to set importance/milestone. [03:11] one regards launchpad's model for permissions regarding distributions [03:11] the other is the present workflow of the people working on the distribution [03:12] let's get this on a whiteboard, and i'm confident we can work it out [03:12] i will say this, hippies, BLUEPRINT IS CLOSEST to what you need now ;-) [03:13] 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] I propose that we hold a discussion at a later time on each of these topics [03:13] and then attempt to reconcile them [03:13] wiesbaden it is [03:13] I would very much appreciate for my opinions and experience to be represented in both discussions [03:13] that is all [03:13] you'll be in wiesbaden? [03:14] I will be in Wiesbaden from August 20th-25th [03:15] i think ill be there 22-23 [03:16] bradb: I can't actually remove you from the team afterward, I don't think [03:16] only deactivate you [03:16] 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] I'll mail seb and ask him to test in the morning [03:16] since it was he who raised the issue with me [03:17] mdz: i can leave the team too [03:17] +leave, etc [03:17] but whatever, your call [03:17] I've mailed seb [03:17] ok, cool [03:20] bradb: are you serious? *release management* by the wisdom of crowds? [03:21] 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] with some interesting side-by-side views of each, for good measure [03:23] 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] sure, we're on that path now, so i think it's best to close the deal [03:25] bradb: we are even going to do TAG CLOUDS one day ;-) [03:25] heh heh [03:25] night all [03:25] night man [03:25] later [03:26] kiko-zzz: YAAAAAAAAA [03:26] ddaa, what did I do now? [03:26] finished the patch that fixes "renaming stuff breaks imports" [03:26] hah! that is rock on awesome! [03:26] including the buildbot glue, and tested [03:26] dude our imports are looking like the rats ass [03:26] now, putting it up for review [03:26] and going on VACATION [03:26] kiko-zzz: pardon? [03:26] err [03:26] I meant really slick [03:27] or something === kiko-zzz goes find a pillow [03:27]