[12:05] Will there be one project with multiple groups working around it, or does every developer group and distro create a new project and setup everything from scratch? [12:06] I don't understand where these four teams co-operate, and where they don't. [12:08] If Mozilla developer community, Netscape, Ubuntu and Suse all used launchpad to develop mozilla. [12:08] How would it work [12:08] It is not a problem [12:08] sivang, yes, I've been back in NZ for about a month [12:08] I just don't know yet how Launchpad works. === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [12:09] cyberix, none of those would be projects, in the way Launchpad uses the word projects [12:10] the Mozilla developer community's one would be a product [12:10] and the various distros would have packages of that product. [12:11] Could Netscape then setup a team to work on the product? [12:11] no, because Netscape is closed-source and Launchpad is for open source :-) [12:12] but in general, you can set up teams in Launchpad for whatever you like [12:12] Neither products nor packages are formally associated with teams in Launchpad [12:13] Rosetta understands teams, because it has translation teams with special permissions [12:13] but other parts of Launchpad don't use teams, afaik [12:13] How does patch management work then? [12:14] You can attach a patch to a bug report, just as you can in Bugzilla [12:14] I'm not an expert on that area, but I *think* Launchpad aims to encourage branches rather than patches [12:14] But who gets to decide wether a branch or a patch is included? [12:15] Well with branches this is ofcourse no problem [12:15] The maintainer of the product or package [12:15] e.g. I might come up with a branch for Firefox that puts the toolbar at the bottom of the window [12:16] and the Ubuntu maintainer might say "ok, that's cool", and merge my branch, and maintain it in Ubuntu Firefox [12:16] while the Mozilla developers say "that's crack" and never merge it [12:16] so Mozilla Firefox and Ubuntu Firefox and SuSE Firefox can be maintained in parallel [12:17] and in the distant future, Launchpad will be able to show you how closely related various branches are [12:18] But what, if mozilla product maintainer refuses to confirm a (public domain ;-) branch created by Netscape [12:20] Then no packager can include it. [12:20] Netscape might have their own packager. [12:21] And this could be a spy-ware branch [12:21] So, it'll be the same as my toolbar branch [12:21] Mozilla product maintainer would refuse to accept it for ethical reasons [12:21] it'll be included in Netscape but nowhere else [12:21] But Netscape maintainer would still want to include it. [12:21] and they would. === SnakeBite [n=SnakeBit@212.25.63.226] has joined #launchpad [12:22] But how and where would their branch be hosted? [12:22] on Launchpad [12:22] They would have "mozillawithspyware" product there? [12:22] https://launchpad.net/people/somenetscapeperson/+branch/name-of-branch [12:22] With maintainer from Netscape? [12:22] not a product, just a branch [12:23] But isn't the product just a bunch of branches then? [12:23] yep [12:24] So what are products needed for? [12:24] can't we just have packages that collect a bunch of branches? [12:24] to say what a branch is a branch *of* [12:25] so I can say "this funny toolbar branch is a branch of Firefox", and Netscape can say "this spyware is a branch of Firefox", and they can appear on the Firefox product's Branches page [12:25] So products are named places of forks then [12:26] then someone wanting to package Firefox can say "I'd like that branch, and that one, but not that one, and I'd like fries with that" [12:26] So prducts are just names for branch collections so it is easier to talk about them. [12:27] It's like the Linux kernel -- Linus's branch is in the center, but only because he makes good decisions [12:27] pretty much, yes. [12:27] Ok. I'm starting to get this. [12:27] -- back to reality -- [12:28] Products are also useful things for handling translations and bounties and support requests. [12:28] handling -> categorizing === sivang thinks this should be written up somewhere, if not already is, for the future launchpad-user-docs [12:29] I'm not sure about the current status of gnunet and gnunet-gtk packages. [12:29] They are auto(?) included from Ubuntu [12:29] But I can't work on the translations [12:30] I'm also interrested, if they get somehow synced with gnunet svn [12:31] I'm just not sure what to do. I can't add them because they are there already, right? [12:31] Mail rosetta-users, or talk to jordi when he wakes up [12:31] jordi's our translation organizer person [12:33] I mailed, but used different email than my launchpad account so the email got stucked for moderation. [12:33] How long will this moderation take. Should I send another email from the right address? [12:33] hello cyberix [12:34] jordi: :-D [12:34] jordi: good morning [12:34] (except it's 00:34 here ;) [12:34] hey jordi , also working in different timezone? [12:34] jordi: good earlyish morning [12:35] sivang: nope, West Europe TZ [12:35] cyberix: what's up? [12:35] jordi: Can you set gnunet and gnunet-gtk packages up for translation [12:35] cyberix: are you the author? [12:35] No [12:36] I'd just like to translate them to Finnish [12:36] They tell me "No translatable templates available" [12:36] cyberix: have a look at this [12:36] https://wiki.launchpad.canonical.com/RosettaNewImportPolicy [12:36] Both packages should have such. [12:37] cyberix: or you can translate the ubuntu templates, after joining the Finnish team [12:39] cyberix: have you found the templates in rosetta? [12:39] the ubuntu ones [12:39] nope [12:39] https://launchpad.net/distros/ubuntu/breezy/+source/gnunet/+pots/gnunet [12:39] is this it? [12:40] I'd like to translate the dapper one [12:40] oh [12:40] The version in Breezy is very outdated anyway [12:40] dapper isn't yet imported. It will, but you'll have to wait until February [12:40] you could start working on it on breezy, and then merge your breezy file in dapper [12:41] I could start working on the development template [12:41] I assume most of it would be valid [12:41] it is very close I think [12:41] yes [12:41] They can/will be merged when the dapper one starts to work? [12:41] can be merged [12:42] not automatically yet, that will happen in the future [12:42] How are the translations committed to upstream svn? [12:42] by hand? [12:43] yes [12:43] when you finish, you can export your file and send it upstream [12:43] mpt: thanks for highlighting the channel :) [12:43] mpt: I was going to close this [12:44] I hope this will be automated one day [12:44] to avoid redundant work [12:44] it can't be fully automated, but we will export bzr branches so upstreams can get he updates very easily [12:45] even automatically [12:45] but they need to agree of course [12:46] How can I get permission to upload the dev-templates for gnunet and gnunet-gtk? [12:47] is the breezy version very different? [12:47] cyberix: you should ask the authors if they are ok with it. [12:48] breezy version is comlpetely different I think [12:49] 0.6 -> 0.7 was almost complete rewrite in architecture [12:49] and if they are? [12:52] if they were, you could work on those and then merge with the new version, when dapper is imported in Febrauary [12:52] but if talk to upstream about this, I can import GNUnet devel as you wish. [12:53] The only problem I can think of is that they are Gnu projects, so they might 1) want people to use the Gnu translation system and, 2) refuse because Launchpad/Rosetta is non-free software. [12:53] yes [12:54] I know, that's probably going to be a problem. [12:54] waiting for the dapper import seems a good idea in the end [12:54] But 1) People could still use that one [12:54] 2) no-one has to install non-free software to use Lauchpad/Rosetta [12:55] cyberix: the rpoblem with importing against their will or knowledge is that if the GNU Finnish team is also working on it, you'll duplicate work. [12:55] I think FSF is more against installing non-free software than using hidden non-free software e.g. in an ATM machine. [12:55] Well I've done more Finnish translation work for GNUnet than the Gnu translation team. [12:56] :-) [12:56] hehe, yeah [12:56] http://www.iro.umontreal.ca/translation/registry.cgi?domain=gnunet-gtk [12:56] this is good news [12:56] they don't require the translation disclaimer [12:56] cyberix: I need to go to bed. [12:56] good night [12:56] (actually me too) [12:56] Should we talk abot this in the morning? Like in 9h from now [12:56] or mail me [12:57] nite [12:57] night [12:57] I'll get back to you === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad === ajmitch_ [i=ajmitch@203.89.167.29] has joined #launchpad [02:01] jamesh: ping on the story review for me [02:25] lifeless: just about to send the review. Unless I'm mistaken, this would make it impossible to run an individual page test from pagetests/standalone/, right? === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #launchpad === Topic for #launchpad: launchpad.net | developer meeting: Thur 19 Jan, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 === Topic (#launchpad): set by SteveA at Thu Jan 12 13:08:50 2006 === mick__ is now known as mick_home === LaserJock is now known as LaserJock_away === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === mpt [n=mpt@219-89-137-219.jetstart.xtra.co.nz] has joined #launchpad === mick_home [n=mick@adsl-153-192-12.mia.bellsouth.net] has joined #launchpad [07:33] stub: there is a bug report referencing an OOPS ID that doesn't seem to be available on chinstrap. Are there any OOPS reports that wouldn't be getting sync'd? [07:36] jamesh: I don't think the rsync jobs are sorted yet. The OOPSs should be in /srv/launchpad.net, but arn't. The old location might still be active but won't have OOPS from servers 3 and 4 [07:39] stub: okay. [07:40] the oops in question was OOPS-18A428 [07:41] looks like the last OOPS for the 18th on chinstrap is from around 12:41 [07:41] Without a checksum, we have no way of ensuring the code was transcribed correctly. [07:57] hmm [07:58] 7 bits should be more than enough [07:58] just add one more digit [08:00] Would somebody with breezy mind checking the version of postfix they have for me? [08:01] jblack: should be 2.2.4-1ubuntu2 [08:01] thanks [08:02] 2.1.3: warty, 2.1.5: hoary, 2.2.4: breezy, 2.2.8: dapper [08:02] which fits what's in the archive === lamont sleeps [08:02] whoo. mail! === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad [08:11] jblack: just for giggles, if you want to see if 2.2.8-4 works, that'd be neat [08:11] (works for me on an hppa/dapper box) [08:12] I could give that a try tomorrow [08:23] jblack: https://launchpad.net/distros/ubuntu/+source/postfix should also give you the answer about the version numbers === Den [n=Den@boalt-wlan2-427.AirBears.Berkeley.EDU] has joined #launchpad === southfoxargentin [n=fox@200-122-35-171.dsl.prima.net.ar] has joined #launchpad [08:42] Any launchpad developers/ maintainers here? [08:45] _anyone_here? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [08:49] Den, ask your question and hope, or try the mailing list === mpt_ [n=mpt@219-89-152-206.jetstart.xtra.co.nz] has joined #launchpad === jinty [n=jinty@Gb081.g.pppool.de] has joined #launchpad === mpt_ is now known as mpt [09:00] jamesh, what happened to all the Documentation and Websites bugs from bugzilla.ubuntu.com? [09:02] mpt: nothing [09:05] that's bad, isn't it? [09:05] the Ubuntu Documentation team were using Bugzilla fairly heavily [09:06] to do a migration, I'd need to know how to map the bugs [09:08] argh you didnt move those/ [09:08] ?? [09:09] and now we can't use them? [09:09] we would need to migrate them before use [09:09] you closed bugzilla before doing that? === mdke_ boggles [09:10] jamesh, all the Documentation bugs should be migrated to https://launchpad.net/products/ubuntu-doc/+bugs [09:11] mpt, distros/ubuntu/ubuntu-doc? [09:11] mpt: all in one product? [09:11] hmmmm [09:11] mpt, distros/ubuntu/ubuntu-docs sorry [09:11] maybe ubuntu-doc should be a project, and each document should be its own product [09:12] here are the existing components: https://bugzilla.ubuntu.com/describecomponents.cgi?product=Documentation [09:12] they don't exist upstream, only in Ubuntu [09:12] https://launchpad.net/distros/ubuntu/+source/ubuntu-docs [09:13] mdke_: having them as one or more products would make more sense in the LP datamodel. [09:14] mdke_: you can register bzr branches against products (if you want to use bzr to manage the docs). [09:14] we don't use bzr [09:14] mdke_, they could be used (with a few tweaks) for Ubuntu derivatives, which is why they make sense as products [09:14] k [09:14] ok, you guys can sort it. I'll just go and wonder how bugzilla can have been closed when not all the bugs were exported [09:14] website bugs are quite important too [09:15] mpt: well, if you tell me how you want the bugs mapped, I'll do the migration [09:17] heh, I was just about to suggest you and mdke sort it :-) [09:17] s/mpt/mdke/ then :) [09:18] mdke_, Bugzilla's been closed for nearly a week and you didn't notice? [09:20] kiko: Up by any weird twist of fate? === PenguinOfDoom [n=PenguinO@spleen.xzrq.net] has joined #launchpad [09:20] How do I specify that a bug applies to dapper? [09:21] Or is this not what "distribution" field is for? [09:21] PenguinOfDoom, once the bug is reported, click "Target to Release" and choose Dapper [09:23] Malone is byzantine :P [09:23] mpt: is there a clear separation between "admin request" website bugs and "content" website bugs? [09:25] mpt: given that the admins are using RT to manage requests now === koke [n=koke@ubuntu/member/koke] has joined #launchpad [09:35] mpt, mdke_: https://wiki.launchpad.canonical.com/BugzillaImportProcess/DocumentationProduct <- make a decision and fill in the table === southfoxargentin [n=fox@200-122-8-203.dsl.prima.net.ar] has joined #launchpad [09:45] jamesh, that depends on who's making the changes, I suppose [09:45] cyberix: hey [09:45] Except for the wiki, the Ubuntu Web sites aren't open source, so they don't really belong in Launchpad [09:46] cyberix: I don't see your rosetta-users post in the moderation queue [09:50] cyberix: oh, I see it as a bounce. There's something wrong with your post. [09:50] mpt: okay. We can leave out the website ones for now. Should be pretty easy to decide how to map the documentation bugs though [09:52] mpt, ubuntu.com is on a moin wiki too tbh [09:52] oh you mean the process isn't open source [09:53] mdke_: some of the websites product bugs are things like "SSL certificate broken for xxxx.ubuntu.com", which these days is more appropriate for RT [09:55] jamesh, sure, but that isn't advertised to the users, and they can't see it's been reported. In fact I was wondering myself if they were on that one [09:56] It's to need a Canonical password to see bugs about *.ubuntu.com [09:56] mpt, can you do the table? I've marked some as "not needed" because the documents don't exist. as for the others, I don't know how Launchpad targets work well enough [09:56] It's odd to need one, rather [09:56] mdke_, sure === mdke_ is now known as mdke [09:56] thanks [09:57] if you want to keep the current categorisation, please create the project and products as well as entering their names into that table [09:57] yeah, that is why I left them [09:58] we'll also need new ones for dapper: faq guide disappears and becomes "desktop guide" and "server guide" [09:59] mpt, actually wrt Documentation/Installation, you might ping Kamion, there is documentation for the debian installation program that people sometimes file bugs against, iirc [09:59] mdke: there is no migration issue for these new products though [09:59] mdke: anyone can create them [10:00] no, no migration issue [10:01] [08:18:15] < mpt> mdke_, Bugzilla's been closed for nearly a week and you didn't notice? [10:01] i kinda noticed that my bugs weren't there, but I presume they had been imported but didn't belong to me anymore [10:02] jamesh: so [10:05] lifeless: yes? [10:06] mdke: when you say "not needed" and "not needed yet", are you saying you want me to ignore those bugs? [10:06] and leave them in bugzilla? [10:07] jamesh, i mean the documents don't exist [10:07] so yeah [10:07] mdke: there are no bugs filed on them? [10:08] if there are, they are on the wrong component, I'll have to check === carlos [n=carlos@238.Red-83-55-105.dynamicIP.rima-tde.net] has joined #launchpad [10:09] jamesh: jamesh standalone page tests === PenguinOfDoom [n=PenguinO@spleen.xzrq.net] has left #launchpad [] [10:09] jamesh, there are some, perhaps we can pull them into where General goes? [10:09] jamesh: I think we should either make them really standalone with db reset and clearing [10:09] jamesh: or we should treat that dir as a story [10:10] mdke: https://bugzilla.ubuntu.com/buglist.cgi?product=Documentation&component=Admin+Guide&component=Installation+Guide&component=Quick+Guide&component=User+Guide [10:10] wowsers THATS a URL [10:10] yeah i see em [10:10] lifeless: I'm having difficulty with MockJobManager. Can you take a look at lib/supermirror/tests/testmirror.py? [10:10] lifeless: I agree. I'd suggest making them standalone [10:11] bblm [10:11] lifeless: there are 152 tests under pagetests/standalone/, and when working on a particular branch I usually want to run only one or two tests from that directory [10:12] running an entire story isn't so bad for the other page test stories, since they are a lot shorter [10:12] (and are intended to have order dependencies) [10:14] mdke: we can easily map multiple bz components to a single LP product if that's the issue [10:14] e.g. map the bugs in those components to the same one as the Documentation/General one [10:15] jamesh: ok. I'll mail lp to confirm this, and assuming its good do it [10:15] jamesh, good, I've updated the wiki page accordingly. i'll leave the others to mpt, I'd rather something who is more familiar with LP than me decide whether to go with the distros/ubuntu or products/ubuntu-doc approach === mdke gets all confused with the upstream/downstream relationship [10:25] jblack: be with you in a minute [10:25] ok === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === Nafallo_away is now known as Nafallo [10:50] jblack: ok [10:50] jblack: I art here [10:50] Thou are here! [10:50] Ok. so on chinstrap in the expected location, I have a current sm-ng [10:51] yup [10:51] if you look at lib/supermirror/tests, you'll find testmirror.py [10:51] in that, you'll find testDoublelock [10:51] testDoublelock is supposed to lock, then lock again, causing an error condition that I'm attempting to duplicate [10:51] why do you want a Mock manager here ? [10:52] Because I'm testing main [10:53] My idea is to make a mock manager, start up main, which will make another mockmanager. [10:53] well [10:53] I.E. Lock, then main tries to lock again. [10:53] that should fail, because its already locked, and I can make sure that main handles the exception properly [10:53] the mock manager was used so that we could test the ui without having stuff really happening [10:53] exactly. [10:53] so, are you testing the UI, or testing the manager ? [10:54] oh, I see [10:54] so you want to test that 'main handles a failed lock correctly' ? [10:54] Yup. [10:54] I'm trying to do this with a static attribute to emulate lockfiles. [10:54] You can see that in the mockmanager class... [10:54] except it doesn't work. [10:55] ah [10:55] see they are not really static when you access them like that [10:55] do 'MockJobManager.locked = True' [10:55] in the lock() method. [10:56] then it will behave like a static member [10:56] Ahh. What do I do with the.. for lack of a better phrase, declaration? [10:56] the declaration is fine [10:57] just dont ever assign to it as 'self.locked' or it will convert it to a member variable [10:57] for clarity, I suggest you never refer to it as self.locked at all [10:57] Gotcha. [10:58] if I understand it correctly this happens because 'self.FOO = bar' calls setattr(self, 'FOO', bar) [10:58] lifeless: that is correct. [10:58] spiv: first principles are wonderful things [10:58] And that takes precedence. I get it [10:58] jblack: exactly. [10:59] Whoo! Failures. [10:59] gotta love those failures. [10:59] Actually, I do. [10:59] I wouldn't say that it "converts" it to a member variable, exactly. Just the instance attribute overrides the class attribute, just the same as a subclass can override a parent class's attributes. [10:59] oh I was being serious [10:59] Well, not precisely the same, I guess, but anyway... [10:59] Of course now all my mock tests fail now... :) [10:59] spiv: pedant. pedant pedant. see the pink icon in the corner [11:00] pink icon? [11:00] spiv: well panthers are endangered === triceratops [n=tricerat@dyndsl-085-016-021-027.ewe-ip-backbone.de] has joined #launchpad [11:01] thanks lifeless [11:01] lifeless: Ah. [11:01] I want to fill a bugreport against ipodder (universe) but it isn't registered in malone yet. [11:01] oh sweet. [11:01] https://launchpad.net/people/lifeless/+packages [11:02] that is damn useful [11:02] now if only it showed debian versions [11:02] Kinnison: is that planned ? ^^ [11:02] May someone please import ipodder in malone. [11:03] triceratops: https://launchpad.net/distros/ubuntu/+source/ipodder [11:03] triceratops: It seems to be there. [11:03] morning guys [11:04] triceratops: What did you do to look for it? [11:05] spiv: Strange, i searched for ipodder bugs via https://launchpad.net/malone and it says: "No products matching ipodder were found. You can register a new product." [11:05] triceratops: Ah, there's no ipodder product, but there is a package. [11:06] triceratops: So I found it by searching on https://launchpad.net/distros/ubuntu [11:06] hmm, perhaps /malone should search source packages too [11:06] daf: Yeah, I'm thinking that. [11:06] spiv: can we have a quick phone call ? [11:06] daf: Given that the majority of our users atm are looking for packages, not products... [11:06] lifeless: Sure. [11:07] spiv: exactly [11:07] spiv: ideally, it would also look through binary package names and return the corresponding source packages [11:07] spiv: I would asume that most people would look at https://launchpad.net/malone for bugs first rather than using your way [11:08] triceratops: Launchpad keeps track of both products (what upstream developers produce) and packages (deb or rpm versions of a product produced by a particular distribution) [11:09] triceratops: in this case, ipodder the product isn't registered with LP, but ipodder the Ubuntu package is. [11:09] spiv: I would bet for that most people will go from launchpad directly to malone by pressing the menu item bugs, didn't you think so? [11:09] ooh, I see that SelectResults.__len__'s days are numbered [11:11] lifeless: I'm not sure about the UI === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [11:13] jamesh: For novice users this is irritating due to the fact that most of them don't know about the difference between a product and a package. Plus, the menus in launchpad are the first starting point most people will choose the bug menu item which is offered at this place. So it's more a matter of usability / menu prompt. [11:13] triceratops: noted. there are plans to improve the UI [11:16] jamesh: Whilst we are on improvement... :) Is there a way to have a date listed when a bug was reported, better would be to sort the listed bugreports by date. I'm missing this a bit, its always needs a bit fizzeling to list all bugreports step by step to find a date... [11:18] triceratops: at the top of the bug list, there is a box where you can ask to sort them newest first or oldest first === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #launchpad === Topic for #launchpad: launchpad.net | developer meeting: Thur 19 Jan, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 === Topic (#launchpad): set by SteveA at Thu Jan 12 13:08:50 2006 === #launchpad [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup [01:49] (lifeless/#launchpad) so, the proposal is - standalone tests will become really standalone [01:49] (lifeless/#launchpad) pros: no more sideeffects between tests in that dir [01:49] (lifeless/#launchpad) cons: ~3 minute speed hit at this point I estimate [01:49] (kiko/#launchpad) lifeless, you said something about jamesh? [01:50] mpt: A bug contact is a person who gets email about all new bugs filed on something. There is zero or one for a product, zero or one for a distribution, and zero, one, or more for a package. Product/distro contacts are protected by permissions. Anyone can make themselves a package bug contact for any package. [01:50] kiko: the branch I have that makes running stories always work turned the standalone tests into a monolithic block. [01:50] kiko: jamesh likes running single tests from within the standalone group - quite reasonably. [01:50] kiko: so I want to support that use case. [01:50] jamesh, uhm [01:50] lifeless, uhm [01:50] I am totally NOT okay with regressing running-of-a-single-test in standalone/ if that's what we are talking about [01:51] that's one thing which saves me HOURS a day [01:51] kiko: relax dude [01:51] bradb, so a bug contact's bugs report is /people/someone/+bugs/contact or something like that? [01:51] cprov, spiv will send me what he has and I'll move on with the review [01:51] bugs for things you are a bug contact for [01:51] kiko: we are avoiding that regression [01:51] salgado: good idea [01:51] kiko: jamesh picked it up during review [01:52] lifeless, i'm surprised it even got to review there -- that's one of the most important use cases for the test suite. [01:52] (from a developer's point of view) [01:52] kiko: its a totally untested use case. [01:52] mpt: Maybe just one level deep like all the other reports, e.g. +packagebugs. [01:52] kiko: but thats beside the point, I am now special casing 'standalone' [01:52] okay === mpt 's brain hurts at the idea of making tests for the test suite itself [01:53] so the question is, is it special cased as 'each test has db setup/teardown', or it is special cased as 'well its a story that is able to be split into bits' [01:53] lifeless, I think the former. [01:53] the former has the pros and cons I listed above [01:53] if you are hip with them, I'll finish the new tests and punt it back for review [01:53] sweet. [01:53] right. [01:53] are there any other hidden regressions? [01:54] not that I'm aware of [01:54] I mean, what does your branch change in terms of the design? [01:54] of course, if there are other untested features, who knows [01:54] mpt: I'm guessing this report will show which packages the user is a bug contact for, and will allow per-package filtering. [01:54] is it conceptually just adding setup/teardown to each test? [01:54] bradb, if you use the table view, the user can decide on how he wants to group.. [01:54] at the ui level, stories are now directly addressable - === kiko votes for the return of the table view [01:54] me too [01:54] (optionally) [01:55] './test.py lib branches' will run the branches story end to end [01:55] sweet! [01:55] kiko, then organize the politics to unsqueeze our page layout, please :-) [01:55] './test.py lib xx-foo-bar.txt' will run xx-foo-bar.txt wherever it exists *except* if it is part of a 'story', because stories are now not able to be randomly split up [01:55] user liberation army revolt? [01:55] but, you don't need a table to sort bug lists by package [01:56] (that random splitting being the bug I am fixing) [01:56] lifeless, that's correct [01:56] just a checkbox as I said a few minutes ago [01:56] fancy mpt asking for additional checkboxes [01:56] okay [01:56] kiko: in underlying design terms it changes the stories from being testsuites to being testcases, which has the desired effect. [01:56] I see [01:56] and the standalones? [01:56] kiko: and that is where the standalone regression came in, which I am just fixing. [01:57] standalones will remaing a testsuite, but the contents will now be PageTest instances [01:57] I'll show you guys a prototype in a bit. I need to eat first, etc. [01:57] lifeless, okay, cool. [01:57] lifeless, anything else on this topic? [01:57] jblack, ping? [01:57] nope, I have what I need. [01:58] PONG [01:58] lifeless, I'll know when this lands, right? [01:58] Heh. Pong. [01:58] jblack, hey dude [01:58] jblack, I need an idea of what times your script failed to reach the server. [01:58] kiko: yes, I will be mailing the lp list when it lands, as people have to know to use such features [01:58] great. [01:58]