=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has left #launchpad [] [12:16] ychahibi: hmm, the problem with the oooo one is that i's a bit messy if I remember correctly [12:16] we need really good grammars, yes. [12:16] err, glossaries [12:16] salgado: hiya [12:17] jordi, sure [12:17] jordi, the OOo glossary contains many non IT terms [12:17] yes [12:17] jordi, it also has to be classed into categories so translation can be easier === lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad [12:21] jordi, such a unified glossary can be useful for i18n projects, specially in the open source participation development, where translation is made by many contributers. Thus,any new contributor should know which terms were used by any former contributor. === jinty [n=jinty@84.Red-83-55-199.dynamicIP.rima-tde.net] has joined #launchpad [12:26] ychahibi, rosetta already does that: it shows you every translation used for similar strings. That goes *some* of the way towards helping with that [12:27] I'd encourage you to use a mailing list/wiki page for now to coordinate about individual words, until Rosetta includes this functionality [12:27] mdke, yes. [12:28] mdke, won't it be better if the different languages used the same english terms database ? [12:28] what do you mean? [12:28] hey lifeless [12:29] mdke, it would be nice to have a list of english words for all the languages to populate the wikipages with their equivalents in different languages [12:31] ychahibi, you mean, technical words? [12:32] like computer, internet, hard disk ... related to computer sciences [12:36] ychahibi, that sounds like you'd be making a list to try and teach people English [12:36] mdke, no [12:37] mdke, something like http://l10n-status.gnome.org/HEAD/PO/gnome-glossary.HEAD.pot [12:38] i see [12:38] mdke, excuse my poor English : [12:38] :) [12:39] it's extremely good === poningru__ [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #launchpad [12:45] heh mtg [12:45] matsubara? [12:45] I would benefit greatly to have that card [12:45] kiko: ponigru quit message. [12:46] kiko: it's supposed to be a magic the gathering card. [12:46] yeah, I see [12:46] ng [12:46] sorry [12:47] poningru: there's nothing to be sorry about. I was just commenting about your quit message. I used to play a lot of mtg in the old days. [12:48] hehe [12:48] I was apologizing for the stray piece of 'ng' [01:21] hmm, carlos's gone [01:22] and it's only 1:30 AM [01:22] I am too :) [01:22] (but I have work to do -- more work!) [01:23] you're going to sleep? [01:23] what time is it in Sao Carlos? [01:24] jordi: 20:24 [01:25] oh man, he's like a 6 y/o! [01:25] like what? [01:26] six year old [01:26] late for swimming too [01:29] no swimming on thursdays [01:29] and it was even later last night anyway [01:29] and I couldn't sleep [01:35] oh well. I need some sleep. see you later jordi. === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [03:32] np zero666 === stub [n=stub@ppp-58.8.1.90.revip2.asianet.co.th] has joined #launchpad === mpt [n=mpt@219-89-153-137.jetstart.xtra.co.nz] has joined #launchpad === mpool [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad [05:00] Goooooooooooooooooooooooooooood afternoon Launchpadders! [05:08] good 4:08am :) === poningru [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #launchpad === stub [n=stub@ppp-58.8.1.90.revip2.asianet.co.th] has joined #launchpad [07:14] stub: I'm doing a test reconcile on balleny [07:14] stub: debugging the revno problem [07:15] stub: please not be killing bzr's :) [07:15] it wont affect pqm, except memory pressure === mpt_ [n=mpt@219-89-147-7.jetstart.xtra.co.nz] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === mpt__ [n=mpt@222-154-113-97.jetstream.xtra.co.nz] has joined #launchpad [07:55] lifeless: I'd like to merge in a backport of Twisted SVN r16671 to rocketfuel (for bug 41409) -- want to review or rubber stamp it? [07:55] Malone bug 41409 in launchpad "initial push of a knit branch errors" [Critical,Confirmed] http://launchpad.net/bugs/41409 [07:55] spiv: please [07:55] (review) [07:58] lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileSoLGjF.html [08:21] r=lifeless [08:22] Thanks. [08:22] I've also added a related branch to the review queue, I have a diff ready if you don't want to wait for pending-reviews. [08:22] sure [08:23] oh there was one thing [08:23] if you care to you could add a deprecation warning about the backend sending the bad exception [08:24] Yeah, that's a good idea. [08:25] I seperately need to refactor that exception handling, because it's starting to be duplicated in a few places in that class, so I think I'll hold off until I do that. (Besides, I just sent the merge request a second before you suggested it ;) === mpt [n=mpt@222-154-181-110.jetstream.xtra.co.nz] has joined #launchpad === mpool [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad [08:32] spiv: so where is this diff ? [08:32] lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJQJkfg.html [08:33] spiv: you can put the deprecation warning in twisted sv [08:33] lifeless: Yep, I'll do that tonight. [08:36] how did you find setting up the interface based testing ? [08:38] lastly, I think you might be leaking test????.tmp dirs [08:38] as we aren't using the bzr test runner. Could you check for that ? [08:38] Yes, I am. [08:39] + self.local_branch = self.make_branch('.') [08:39] + tree = self.local_branch.bzrdir.create_workingtree() [08:39] I would do [08:39] tree = self.make_branch_and_tree('.') [08:39] self.local_branch = tree.branch [08:39] I feel like the test_suite function is a bit more awkward than it needs to be, but I very much like the fact the facility exists. [08:39] I looked at make_branch_and_tree, I forget why I didn't use it. [08:40] I think probably for no good reason :) [08:41] so, fixing the test leakage involves more cargo culting [08:41] look in bzrlib/tests/__init__.py [08:41] I'd really like a way to say directly, "run this TestCase with X, Y and Z formats", rather than having to muck about with iter_suite_tests and stuff directly. [08:41] yup [08:41] its on my todo to refactor this [08:41] It could even hide the adapter from me, perhaps. [08:42] Cool. [08:42] Please consider this another data point for your refactoring :) [08:42] so one possibility is an AdaptingTestSuite, whose run method clones on demand [08:42] there are a number of possibilities :) [08:42] At the moment I think the minor ugliness is more than worth it for the benefits it gives, so I'm happy. === stub [n=stub@ppp-58.8.1.90.revip2.asianet.co.th] has joined #launchpad [08:43] In the past, I've done this sort of thing with ad-hoc TestCase subclasses (which are then automatically discovered). [08:43] anyhow, to remove the test????.tmp dirs, you need to remove TestCaseInTempDir.TEST_ROOT and reset it to None [08:43] this is a wart [08:43] Which is sort of simpler, but a bit dirtier. [08:43] spiv: it seems to me it would be nice for test suites to declare [08:44] (by remove, I mean shutil.rmtree [08:44] (e.g. there's twisted's FTP client test case with a [08:44] "I want to run again all implementations of IFoo", or "the default IFoo", or "all that support something" [08:44] 'pasv' flag, and a trivial subclass than just sets the flag the other way). [08:44] lifeless: ok (re. balleny bzr processes) [08:44] spiv: right. [08:44] (or overrides a single simple method or something, I forget :) [08:45] mpool: I think that when I make the scenario concept an object it will become simpler to use [08:45] lifeless: Ok, I'll do that. [08:45] spiv: look at bzrlib.tests.run_suite [08:45] mpool: because we can define precanned scenarios for those cases [08:46] lifeless: ta. [08:46] yep [08:46] lifeless: my other question about that branch is do you agree with my choice of formats I'm supporting? [08:48] spiv: format 6 + all registered metadir formats - yes [08:50] stub: I'm starting to plan the knit transition for launchpad [08:50] https://wiki.launchpad.canonical.com/RocketfuelToKnits [08:54] lifeless: "Sender not authorised to commit to branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/twisted/trunk/" === pingar [n=saltvik@m045g.studby.ntnu.no] has joined #launchpad [08:57] muhaha [08:57] doth it pass tests ? [08:57] remember, we dont run the twisted test suite, yet IIRC. [08:58] lifeless: Yes (not that http://twistedmatrix.com/buildbot/ really shows that, because of all the regular intermittent failures on every builder except full-2.4) [09:00] where is your branch ? [09:03] spiv: ^ [09:04] lifeless: sftp://chinstrap.ubuntu.com/home/warthogs/archives/spiv/twisted/twisted-malone-bug-41409 [09:06] spiv: and what commit message wouldst thou liketh ? [09:06] "[r=lifeless] Make the twisted.vfs SFTP adapter's removeFile method translate NotFoundError into the appropriate SFTPError." [09:06] done === carlos [n=carlos@105.Red-81-34-77.dynamicIP.rima-tde.net] has joined #launchpad [09:09] morning [09:09] morning carlos, how are you [09:09] http://matin.maapallo.org/site.pl/selain/?c=zits&i=439 [09:09] spiv: done [09:10] ruffneck: fine, thanks. And you? [09:10] lifeless: Thanks! [09:11] quite well; ) [09:17] http://mikseri.mpoli.fi/hifi/download.php?fn=portrait_-_morrimoykky.mp3 === pingar [n=saltvik@m045g.studby.ntnu.no] has joined #launchpad === mdke_ [n=matt@81-178-237-162.dsl.pipex.com] has joined #launchpad === poningru [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad === jmg [n=jmg@shinobi.thoughtcrime.org.nz] has joined #launchpad === zorglub [n=zorglub@194.146.226.84] has joined #launchpad === lifeless [n=robertc@dsl-43.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad === lamont [n=lamont@mib.fc.hp.com] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad === uniq [n=frode@ubuntu/member/frode] has joined #launchpad === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad === ajmitch [n=ajmitch@203.89.166.123] has joined #launchpad === poningru_ [n=poningru@n128-227-50-237.xlate.ufl.edu] has joined #launchpad === mitsuhiko [n=nnblackb@ubuntu/member/mitsuhiko] has joined #launchpad === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === uws [n=mathilda@scrat.hensema.net] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === mdke_ is now known as mdke === _stgraber [i=steph@xeon.stargate-server.com] has joined #launchpad === dsas [n=dean@host86-128-13-192.range86-128.btcentralplus.com] has joined #launchpad === sivang [i=sivan@muse.19inch.net] has joined #launchpad === BjornT heads out to do some errands === _stgraber is now known as stgraber === doko_ [n=doko@dslb-088-073-072-009.pools.arcor-ip.net] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:44] mpt: morning === mpt_ [n=mpt@219-89-153-12.jetstart.xtra.co.nz] has joined #launchpad [10:49] mpt_: morning === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [10:57] mpt_: ping === kagou [n=kagou@84.7.31.248] has joined #launchpad [10:57] anyone know how to remove calendar from https://launchpad.net/people/vetsel-patrice ?! [11:02] kagou: I don't think you can do it [11:02] so carlos should i report a bug ? [11:03] kagou: I don't think it's a bug... [11:03] kagou: but better ask jamesh, he wrote it [11:03] thanks carlos [11:04] kagou: there is no facility for removing a calendar [11:05] jamesh: you mark this problem in your todo list or do i report a wish bug ?! ;) [11:05] kagou: is there any particular reason you want to remove the calendar? [11:06] yes i'm not using it at all [11:06] and may be removing this saving cpu power/mem for the launchpad server [11:07] kagou: it isn't a problem from the LP server end [11:07] SteveA, pong [11:07] mpt_: to the menus channel please! === mpt_ dons his cape and mask [11:07] ok jamesh. Thanks === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === kagou [n=kagou@84.7.31.248] has left #launchpad ["Ex-Chat"] [11:28] hi ddaa [11:29] hi jamesh [11:30] didn't get the round tuits to look at your importd error reporting stuff [11:31] ddaa: I've got bzrsync refactored and passing the existing tests again. Just need to add the new tests you mentioned, and make sure they pass [11:31] been scrambling to fix an important missing db constraint, then got sick :( [11:31] so it now grabs the ancestry of the branch and imports all those revisions [11:32] and if the revision exists, it makes sure the parent IDs match and are in the right order [11:32] then goes through to synchronise the RevisionNumber objects [11:32] that's great :) [11:32] if it runs into a divergance, it truncates the history at that point [11:33] so it should work correctly with a (branchid, revisionid) constraint on the RevisionNumber table [11:33] I see, you truncate then recreate the revision numbers [11:33] yeah [11:33] it's not optimal, but it's the simplest way to deal with the new db constraints [11:34] that could possibly go nasty on some pathological cases [11:34] oh? [11:34] Imagine an Arch import, with revision history several thousand revisions long [11:35] with some missing ancestry [11:35] the missing ancestry gets filled, and all the history gets shifted [11:35] you have a divergence at the first revision in the history [11:36] so there would be one truncate from rev 1 on, and then it recreates the RevisionNumber objects [11:36] yup [11:36] the alternative is to make the constraint a relaxed constraint (i.e. it can be broken temporarily during a transaction) and update all RevisionNumber objects in a single transaction [11:37] although I'm not sure it will be a big deal in practice [11:37] Some could be optimised out by truncating in a single query, but then you still need N query to fill the history, so it's not a significant improvement in term of algorithmic complexity. Probably not worth the trouble. [11:38] jamesh: yeah, I was inappropriately concerned with long transactions. The branch-scanner is the only thing to update those tables, so there's no risk of lock contention. [11:38] one issue might be if we have foreign keys pointing at RevisionNumber [11:39] Mh [11:39] but I suppose if the history changes for a branch, you wouldn't want old pointers at the RevisionNumber record [11:39] there's a tension between me and sabdfl about that. [11:40] he wants to use foreign keys to revisionnumber or revision (not sure which) when we need to point to a revision [11:40] I suppose for things like bug branch linkage, it should use a Revision (even if it is displayed and entered in the UI as a revision number) [11:40] I want to just use revision ids. [11:40] Yeah, revision is much more robust. [11:42] I'll be looking at your recent work once I have dealt with the current scramble for the missing db constraint on Branch, and after updating on my current backlog of pending merges. [11:42] So if someone links (branch, revno) to a bug, it would actually store (branch, revision) [11:42] depends on the use case here [11:43] if revisions get renumbered, we could display the new revno (if it is still in the history), or indicate that it isn't in the revision history [11:43] if we just want to know that a revision has been merged, we can just need the revision-id (the revision if sabdfl insists on it), and the branch is only a help for display as you say [11:44] if we want to be able to checkout the given revision it's a bit more tricky, because we need a branch that does contain the revision in its repository. [11:45] Which conflicts with the ability to change history and allow garbage collection on repositories. [11:46] but that's a whole other can of worms [11:46] not of concern right now, but good to keep in mind for future developments [11:47] anyway. Asking bzrlib for the branch ancestry rather than keeping a pending_parents list resulted in a net simplification of the code [11:47] Ha, yes. That new bzrlib feature is really nice. [11:48] brb [11:50] sorry, not yet quite recovered, it's a realy PITA [11:51] jamesh: I'm very happy to see you getting more responsive, I really need your help to get the branch stuff going smoothly [11:53] let's recap what's on our plate [11:54] after the branch scanner fix, there's the InternalHTTPLayer removal [11:54] okay [11:55] Then we will see how fast is the branch scanner when doing fewer transactions. Then you may or may not need to put some optimisations there. [11:56] One thing I think would be nice to the user is to store the timestamp of the last scan in addition to the timestamp of the last pull, to account for the window where the branch mirorr is up to date but the listing is out of date. [11:56] right now it commits one transaction for each new revision + one transaction for each changed revision number === mpt__ [n=mpt@219-89-151-35.jetstart.xtra.co.nz] has joined #launchpad [11:57] good idea. [11:57] That same timestamp could be used to only scan branches which have been changed. [11:57] would that be a timestamp of when the last scan started, or when it last successfully completed? [11:57] jamesh: lifeless suggested just doing one transaction per branch. That should give some massive performance improvements. [11:58] jamesh: mh... I'd say time of commit. The branch scanner is not supposed to fail ever. [11:59] my branch adds a failure mode if the parent list for a branch changes. [11:59] s/branch/revision/ [12:00] jamesh: that's a data corruption case as far as we are concerned. The db model is no prepared to deal with it. [12:00] it's akin to what you get when you rm an Arch branch, then publish another branch by the same name. You are breaking model invariants. [12:00] if we do a full scan in a single transaction, then the question about whether the timestamp is for the start or end is moot [12:00] just use the time of the transaction [12:01] right [12:01] there's a few details to work out there too, for example avoid scanning branches which have never been successfully pulled. [12:02] that's more an issue of what goes in the branch pull list though, right? [12:03] jamesh: no, I'm thinking of removing all the BranchNotFound exceptions currently reported be the branch-scanner. [12:03] hmm [12:03] When will launchpad be able to track my 0.8 bzr branch? [12:03] They are all caused by trying to scan branches which have never been successfully mirrored. [12:04] uws: a knit branch? [12:04] https://launchpad.net/people/uws/+branch/anewt/anewt-uws is not updated anymore. jamesh: yes, I suppose tso [12:04] so* [12:04] uws: does "bzr info" say it is a knit format branch? [12:04] uws: hu... right... [12:05] lifeless has been pinging me about upgrading the bzrlib in launchpad so we can do that [12:05] control: Meta directory format 1 working tree: Working tree format 3 branch: Branch format 5 repository: Knit repository format 1 [12:05] there's a new problem there [12:06] uws: I think lifeless said that it is mainly an issue of upgrading the copy of bzr being used by the branch puller/scanner [12:06] namely, the branch puller should delete the mirror branch if it does not have the same repository format as the source branch, then pull anew, because conversion between weave and knit is very cpu intensive. [12:06] jamesh, ddaa: okay, when is that planned? I'd love to see the pages working again :) [12:07] uws: cannot give you a firm date, but it should be a matter of weeks. [12:07] ballpark: 2-3 weeks [12:08] bzr 0.8 is not gold yet, is it? [12:08] it isn't [12:08] ddaa: https://launchpad.net/products/launchpad/+bug/41414 <- lifeless created a bug for that issue already [12:08] Malone bug 41414 in launchpad "supermirror-branch-puller ignores format changes" [Normal,Unconfirmed] [12:09] jamesh: yup, that's it [12:09] good to know salgado as been designated volunteer [12:09] "designated volunteer" :) === ddaa subscribe to the bug [12:11] I'll take it that problem is under control, I really want to focus on clearing my backlog. [12:11] So, two steps for knit support: [12:12] 1. upgrade bzrlib, that should give knit support right away, but will let the mirror use the old format, which will hurt performance a lot [12:12] (and annoy users too) [12:13] 2. add logic to remirror on format change [12:14] 1 should be easy. I expect some minor breakage because as a rule we ignore deprecation warnings until they turn into errors [12:18] ddaa: I noticed one other weird issue in the bzrsync code: it was specifically checking if revision IDs were repeated in a revision's parents list, and only creating RevisionParent entries for the first occurrence (leaving gaps in the parent sequence numbers) [12:18] was there any particular reason for doing this, as opposed to mirroring the parents list as is? [12:18] Mh [12:19] There was probably some reason that made sense at the time... [12:19] there's a db constraint: "revisionparent_unique" UNIQUE, btree (revision, parent_id) === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [12:20] duplicate parents are a contract violation in my understanding [12:20] but that sort of shit does happen [12:21] jamesh: I'm not quite sure whether we should faithfully reproduce what we find in the branch or not. [12:21] it would be nice if you could check with lifeless or mpool about that. [12:22] okay === mpt__ [n=mpt@219-89-159-250.jetstart.xtra.co.nz] has joined #launchpad [12:24] OTOH, nothing is using RevisionParent, it would be painful to use as SQL is really not suited to graph walking [12:25] that information would be useful for revision display, like providing a bzrweb functionality in launchpad, but that would probably require an additional service on the supermirror anyway === jinty [n=jinty@244.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [12:25] so it's clear that RevisionParent is not a YAGNI [12:25] it's _not_ clear that... === stub goes for dinner before the meeting === mpt_ [n=mpt@219-89-134-107.jetstart.xtra.co.nz] has joined #launchpad [12:48] BjornT: hi, do you have sometime to help me with a template problem I'm having? [12:50] carlos: sure [12:52] BjornT: ok, thanks :-) [12:52] BjornT: I have this patch: https://chinstrap.ubuntu.com/~dsilvers/paste/file0tN8bJ.html === jinty [n=jinty@244.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [12:52] BjornT: it adds a new translation form for Rosetta [12:53] that is specific for one message instead of rendering 10 messages like the current one [12:53] I'm adding a new pomsgsetview but I'm reusing templates and views we are already using with the current translation form [12:54] but the code: [12:54] + [12:54] + + use-macro="view/@@+pomsgset-translate/pomsgset-view" [12:54] + /> [12:54] + [12:54] is giving me problems [12:55] I have something similar in the current translation form and it works, but here, seems like the define is not working [12:55] carlos: probably because the define causes 'view' to be called. if you really need the define, use define="pomsgset_view nocall:view" [12:56] well, the thing is that the macro wants a variable called 'pomsgset_view' [12:56] with the current translation form, it's defined as part of a loop [12:57] in this case, the own standard view is that pomsgset_view so we need to use an alias [12:57] ok. so does it work if you use nocall? [12:57] checking it now... [12:58] hmm, it failed again, let me revert another change I did to be sure the failure is not cause by that other change [01:00] BjornT: yeah, it works now [01:00] BjornT: thank you! [01:01] cool [01:04] but I don't understand exactly what's wrong to put there a view and get it 'called' it's just an object [01:04] so the call should do nothing unless you have the __call__ method, right? === cprov [n=cprov@201-43-145-181.dsl.telesp.net.br] has joined #launchpad [01:08] carlos: ku status? Erol's last comment to 41071? [01:09] good morning [01:10] doko: I saw it, don't worry I will take care of it [01:13] carlos: tal always call the last object it traverses (foo/bar/last_object) whenever you use tal:define, tal:replace, tal:contents. views have a __call__ method automagically, so the define caused pomsgset_view to be a string. [01:13] oh, I see [01:14] carlos: ok, a build is currently running, no ku translations from rosetta included [01:15] ok === mpt__ [n=mpt@219-89-134-107.jetstart.xtra.co.nz] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:44] ddaa: there is a bug open on that [01:47] meeting in 13 mins [01:51] lifeless: ack, commented and subscribed to that bug [01:52] ddaa: also see the support-repositories bug === bradb_ [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad [01:55] meeting in 5 [01:55] take a workrave now, or something === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:59] hey lifeless [02:00] it must be meeting time! [02:00] MEETING TIME [02:00] who's here [02:00] ? [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me === kiko pokes cprov === kiko pokes spiv (?) [02:01] mpt just had a hardware problem. he'll be back shortly === kiko pokes stub [02:01] spiv sends apologies [02:01] lifeless sends apologies also [02:01] me [02:01] Ouch [02:01] deserved! [02:01] == Agenda == [02:01] * Roll call [02:01] * Agenda [02:01] * Next meeting [02:01] * Activity reports [02:01] * Items from last meeting [02:01] * Launchpad oops milestone report [02:01] * Outstanding sysadmin requests [02:01] * Production / staging (stub) [02:01] * Decide who will be the bug contact for launchpad-dependencies. [02:01] * Keep, Bag, Change [02:02] * Three sentences [02:02] [02:02] next meeting -- same time next week everyone? === ..[topic/#launchpad:SteveA] : https://launchpad.net/ | developer meeting: Thu 4 May, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === stub shrugs [02:02] * Activity reports [02:02] me [02:02] yah, i suck -- i sent one this week :-( [02:02] anyone doing better than me? [02:02] I'm up to date === stub is up to date [02:02] I'm up to date === mpt [n=mpt@219-89-134-107.jetstart.xtra.co.nz] has joined #launchpad [02:02] up to date, but I've been batching them which is bad. [02:03] i'm up to date [02:03] here! [02:03] I'm up to date [02:03] and up to date [02:03] i'm up to date === bradb sends yesterday's now === kiko kicks matsubara the batcher [02:03] I've even caught up on a couple I forgot to send months ago :-) [02:03] not heard from everyone yet [02:04] i'm not up to date === kiko pokes salgado [02:04] up to date [02:04] jamesh: please send a summary [02:04] kiko, I'm up to date [02:04] really now [02:04] you're not paying attention, dude! [02:04] jamesh: please send a summary during this meeting [02:05] props and respect to all who are up to date! [02:05] okay [02:05] thanks to mpt for compiling the last summary [02:05] * Items from last meeting [02:05] * '''BjornT''' to make it possible for anyone to close a support request [02:05] BjornT: ? [02:06] not done [02:06] ok, so ItemForNextMeetingAgenda [02:06] that's less urgent now, because ... [02:06] but, what's the reason we're tracking this item? [02:06] because we were getting many Launchpad support requests [02:06] and often the reporter doesn't close them [02:07] what's changed? [02:07] ... because now we don't have the Launchpad support tracker links on the error pages any more [02:07] we don't? [02:07] So it's still a problem, but not a major Launchpad project problem [02:07] why was that link removed? [02:08] Because that's what we discussed at the meeting two weeks ago [02:08] i wasn't here... [02:08] please summarize [02:08] SteveA: I believe it was because we already get a notification in the form of an OOPS report [02:08] see the minutes :-) [02:08] And many of them were either duplicates, or "asdfasdf" [02:08] freelinexcd! [02:08] hmm [02:09] i think we may be leaving users with legitimate problems stranded [02:09] It now suggests mailing launchpad-users@ instead [02:09] that's a pain [02:09] because people need to subscribe [02:09] or it makes more work for the list admins [02:09] exactly [02:09] does it say "you need to subscribe before mailing that address?" [02:09] SteveA, we got /too/ many bogus reports [02:09] 99% of the reports were bogus [02:10] maybe we need a pre-filesupportrequest-from-error page [02:10] SteveA, I didn't give an address, I linked to the listinfo page for subscribing [02:10] spambayes, maybe? :) [02:10] (and I may be stretching it because I can't remember the 1%) [02:10] I can remember one that was an actual bug reported by someone outside Canonical [02:10] kiko: the legit 1% were "please remove dud object" requests IIRC [02:10]