[00:01] lifeless: if you kick up in te next few hours and want to look at some subunit things I'll be around [00:01] hi [00:01] I'm here [00:01] trunk subunit and testtools are, AFAICT, ready for releases [00:01] Damn, I wanted to grab tres [00:08] we didn't explictly change subunit to use the unicode path though right? just relied on the __str__ behaviour now giving utf-8 [00:12] subunit depends on unicide exceptions no [00:12] w [00:13] if someone has it fail, we can say 'your exception isn't serialisable safely, see testtools for helpers, or hey, use testtools [00:39] hey folks. a developer in my team has been using a branch bound to the server (IE, only using checkout, update, and commit), but also often uses the --local flag on commit and then commits to the server in a batch. she recently experienced a situation where she is missing some local commits, and can't find them in the repo OR her local code. she suspects that this is because she did a pull at some point in bettween local commits and server commits [00:40] how can we start investigating what happened? i suspect this code is hiding out in one of the "hidden" branches that bazaar keeps around... i can't remember the name of that concept [00:48] i suppose this is a mailing list -grade question [01:14] fwiw, seems like i had the same problem as this guy http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx [01:16] johnjosephbachir: sounds strange [01:16] johnjosephbachir: it would be good to have a bug report with as many details as possible [01:16] alas i probably don't have the time to do that === mnepton is now known as mneptok [01:17] morn morn [01:26] ah, lifeless back again [01:26] see my name in lights on planet debian, thanks ;) [01:28] spiv: thanks-- code saved! [01:38] mgz: :) [01:38] mgz: and on planet.python.org [01:38] johnjosephbachir: great! [01:38] so, my subunit question boils down to if we want to something before release about: [01:38] http://bazaar.launchpad.net/~subunit/subunit/trunk/revision/125/python/subunit/__init__.py [01:38] your check-and-mention testtools suggestion sounds fine to me [01:38] hello mgz, spiv, lifeless [01:38] something like getattr(self, "_exc_info_to_unicode", None), then fall back to self._exc_info_to_string and complain if it's not ascii [01:38] hey poolie [01:38] mgz: we could derive from testtools [01:38] is a goal to avoid an explict testtools depedency though? [01:38] no [01:38] it has an explicit one already [01:38] okay, in which case, just using the testtools class and maybe a version check would do [01:39] -garh [01:41] mgz: see my last commit to testtools :P [01:42] ha! [01:43] my fault too, didn't get as far as testing attempt 2 on py2k [01:43] *3 [01:49] I'm trying to use bzr import on a tarball, but I get a 'tree is malformed' error. Any ideas? [01:51] maybe something like: http://paste.ubuntu.com/458088/ [01:59] mgz: sorry I had already pushed :P [01:59] ah! I'll pull. [01:59] aaron01: please file a bug? Not sure what is wrong there. [02:00] Seems like adding a top level dir (that will be stripped) fixes the problem [02:00] but now getting it trying to import that dir into another branch :( [02:00] s/it/the same error [02:00] spiv does bug 600636 [02:00] Launchpad bug 600636 in Bazaar "bzr ci crashes after a bzr break-lock (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/600636 [02:00] look to you like just another issue of a connection drop causing "too many concurrent requests" [02:01] it does to me [02:01] lifeless, poolie: do you know why when submitting a bug with bzr, you get the option to set the priority, etc? [02:01] I don't see that for Meliae, or Loggerhead, or fastimport or any other project, and I miss it [02:01] okay, yup, your rev is a less borked version of the same [02:01] anyway, back to family time, just curious if it was an option that needs setting somewhere [02:03] jam it's something to do with permissions [02:03] i'm not sure which thing controls [02:03] it [02:03] perhaps whether you're in the bug control team [02:04] ask in #launcphad [02:04] poolie: oh wow [02:04] poolie: the commit code path was meant to be fixed ages ago. Interesting! [02:04] mm? [02:05] It does seem plausible that a connection drop is involved. [02:05] Hmm, likely even. [02:05] there is a message about it [02:06] Oh right. [02:07] jam: I think its driver permission [02:07] most things don't have driver set [04:32] poolie: Hey hey, do you have a second? [04:33] hi, i do [04:33] poolie: Great, let me remember what I needed to chat with you about.... [04:34] poolie: Oh, right. So, it sounds a bit from the discussion with Francis and the way things are gong on the list that I am in fact actually sort of going to end up owning loggerhead. Is that right? [04:34] \o/ [04:34] poolie: I mean, with oversight from you and the bzr team. [04:34] that sounds good to me if it's ok withy ou [04:34] poolie: Yeah, it's totally okay with me, but it will probably require an adjustment in the way that the contract works. [04:36] poolie: Should I discuss that with you first and then Francis, or should Jolie just discuss it with Francis? [04:37] with me first [04:37] it's up to you and jolie which of you wants to be involved from your side [04:37] this is because it's expanding the scope of your work? [04:37] let's talk in private [04:37] Okay. [04:47] poolie: I have a request; please document in doc/developers/testing.txt how to make bzr selftest run on a ramdisk. [04:47] poolie: I think many folk would benefit. [04:48] I can file that as a bug if you would like. [04:50] no i'll just do it [04:52] thanks! [07:17] poolie: http://pastebin.com/rULLkF29 [07:24] vila: --config please, not --conf [07:25] --conf is a strange abbreviation [07:25] c = config.LockableConfig(lambda : location) [07:25] reads really strangely [07:25] perhaps the LockableConfig constructor should be different [07:27] vila: I *really* wish you would not mix changes to imports with test changes [07:27] vila: it makes the patch about 4 times harder to review. [07:27] lifeless: I don't want to break the chain of constructors, I can add a def get_filename if you prefer [07:28] vila: its like a massive whitespace change *just because* [07:28] vila: and as far as I can tell no actual changes to many tests. [07:29] vila: so I'm going to push this back to you [07:29] lifeless: yeah, jam complains about that too, but we won't get the import problem addressed until 1) we all stop importing symbols, 2) we fix all remaining wrong imports [07:29] get me a diff that shows the *actual* test changes, and I'll happily review it. [07:29] vila: be tolerant of what you accept, and strict in what you output - wonderful IETF principle. [07:30] vila: it applies here - accept difference in files you are editing. Make what you write be up to scratch. [07:30] lifeless: this one goes both ways :) That was my reply to jam :-D [07:30] vila: I don't think you're considering the impact on the reviewer enough. [07:30] We're here to think about the change, about what it is meant to accomplish, and we're having to go line by line through noise. [07:30] I do, but the alternative is to postpone these fixes endlessly [07:30] +1 [07:32] vila: 'the import problem' is approximately 0% of our bugs. [07:32] vila: a bad review can easily let a new bug in, or fail to see a structural issue. [07:32] vila: I really want you to think about the relative costs and merits here. [07:33] vila i think lifeless has a point there [07:34] I really wish to feel less alone to realize that our actual tests serve as examples, get copy/pasted and decrease the overall quality which as an impact on our productivity because it makes them harder to modify :-( [07:35] i think i agree with you on that too :) [07:36] does importing the module make much difference in tests? [07:36] presumably we don't care much about laziness? [07:36] or is it just for the sake of consistency and examples? [07:37] vila: I really don't see that the changes you're making make stuff easier or harder to modify. [07:37] Just different. [07:38] not importing symbols has a specific benefit when we want to use lazy_import, but that does not apply to tests [perhaps it should, but the general import in tests is TestCase*, which can't be lazy imported anyway) [07:41] being consistent makes it easier to move code from one file to another or even inside the same file sometimes [07:42] I don't like doing 'from bzrlib import trace' in tests, because in tests you normally want a test object of the class, and that can't be called trace, so it has to be 'from bzrlib import trace as _mod_trace', and thats ugly. [07:42] not being consistent means you never know where a symbol is coming from and in this particular case prefixing with the module makes it 4 times easier to read [07:43] lifeless: <1% of the cases [07:44] Look, there are two things here. [07:44] a) when we do cleanups [07:44] b) whether they are better or worse. [07:44] Put (b) to the side; I'm tired, have a different opinion anyway, and *I was not complaining about b before*. [07:45] I, and John, are both complaining about mixing code changes with cleanups-to-code. [07:46] if everytime you touch a module, you want to put in a separate branch to clean it up, it would not take much more-or-less of your time [07:46] it could be reviewed totally separately to the *actual thing* you are working on. [07:47] and your colleagues wouldn't be feeling that reviewing your changes is hard [07:52] hi [07:52] what's the best way to convert cvs repo to bzr? appears to be a few different ways? [07:55] lifeless: 1) I got vaccines yesterday and that makes me grumpy 2) I've made separate branches in the past for cleanups and that raised discussions anyway so I grew tired of doing that on top of feeling alone cleaning this up 3) the import thing sounds like spurious spaces changes, yet, reviews are either a) not pushed back when they introduce them b) pushed back when they are VWS [07:55] the end result is that spaces are still there and the problem is not addressed [07:56] Outlander: what are the ways? I only know of cvs2bzr [07:57] the imports are more important than spaces and there has been associated problems with them (I encounter one when trying to monkey-patch transport.get_transport, another one was people were importing symbols already imported from another module which broke when the symbol went to a different module or were fixed to not being imported as a symbol) [07:58] on whitespace - when it gets in the way of review, it gets pushback from me; when it doesn't, it doesn't. [07:58] the changes here are big fraction of the total patch. [07:59] its an 800 line patch, for a 200 line change, or something like that. [07:59] * vila tells his vaccines that they don't have to make it grumpy and come in the way to progress [07:59] lifeless: that's unfair, please check [07:59] I did [08:00] 822 lines of diff [08:00] 1) s/file/infile/ trivial to filter on reading [08:00] 542->669 are the actual new tests (I think, my eyes are glazing over so I may be missing other semantic changes) [08:01] add 426-> 448 [08:01] and 300 lines at the start; so 420/822 [08:01] ok, 440/822 [08:01] and thats exactly my point [08:01] in all the excess I couldn't see an important part of the change. [08:04] so, basically, you're saying that you should not cleanup, but you did so in many proposals and I supported that because it's part of keeping the code in good health, 324->333 for example is not required but the cleanup version make it easier to see what is happening here (and avoid useless calls) [08:05] He's saying: consider the audience (which is good advice for any kind of writing) [08:05] So where is the limit on cleanups ? [08:05] There is a balance; I may have gotten it wrong in the past, and for that I'm sorry. [08:06] I'm sorry too but that doesn't address the problem :) Let's put emotions aside and focus on solutions [08:06] If you make a diff that seems unnecessarily hard for a reviewer to review, expect them to be a bit grumpy about it. [08:07] yup, I was expecting that. I was hoping that people were rejoicing about cleanups progressing instead of staling though :) [08:07] So either try to make easier-to-review diffs, or perhaps take other steps to ease the burden, e.g. point out the lines of the diff with the interesting changes. [08:08] I (and I think others) have been daunted in many occasions... [08:08] vila: There are two sorts of cleanups here: code clarity ones, and 'import style'. The former I rejoice at, the latter are entirely mechanical, and have caused bugs in the paste. I do not rejoice at those. [08:08] There's no fixed limit, it really depends on the details of each patch. [08:08] which bugs ? [08:09] we've had import cleanups break due to shadowed names [08:09] they are not risk free. [08:09] true, [08:09] They are also not reviewer time free. [08:09] (e.g. a 90% cleanups patch might be fine if the total patch is only 10 lines long :) [08:10] they are not time free for me either, but some tests are so unclear that I spend time deciphering them too [08:11] I'm saying that the cost and benefit need to be weighed; neither side is 0, and neither side is aleph-0 [08:11] or aleph-1 [08:11] on the overall, I consider that importing symbols is easier to *write* but harder to *read* and leads to more symbols staying around after they are not being used [08:12] and since code is more often read than written, the weight is more important too [08:12] vila: I don't see why symbols that aren't used is a maintenance problem; what does it make non-trivial that is trivial otherwise ? [08:12] review is *part* of the readers but not the only part [08:12] (I like a lean import list btw, don't get me wrong) [08:12] false positives when grepping or even thinking about the module [08:12] vila: something you can do in cases like this is filter the diff [08:13] and only show the bits that are relevant [08:13] andrew has done that in the past and its very nice [08:13] lifeless: ha, nice one [08:13] vila: but really, it all comes down to what has been said before [08:13] consider what the people you ask to review are going to be reading. [08:14] you know what a long repetitive patch is like to review. [08:15] the problem with that is that we tend to *never* address some problems [08:15] and we also said before that we are supposed to clean up things when we modify close enough parts [08:16] I've got nothing more to offer. [08:16] I'm sad. [08:17] so, hmm, looks like I will get back to the two branches approach but there was some concerns about polluting the active review queue with such cleanups too [08:17] and landing them without review was also frowned upon [08:17] I think that that concern is a reflection of this [08:17] vila: so, my opinion is that opportunistic cleanups of nearby code is fine, but not at the cost of significantly worse diffs [08:17] lifeless: I don't want to make you sad because I [08:18] lifeless: I don't want to make you sad because I'm cleaning things up which should make you happy, that's counter-productive :) [08:18] vila: If it e.g. makes a smallish diff large and repetitive I'd rather get two separate diffs. [08:19] so, how about a cleanup branch as a pre-requisite that gets automatically approved if not vetoed when the main branch is approved ? [08:19] Um, [08:20] more work, but I'm ready to do it if it means we progress here [08:20] Perhaps that's ok, although it seems like a solution to a problem we don't have yet? [08:20] Is it really that hard to get approval for cleanup-only branches? [08:20] we have a problem: our code base is not consistent [08:20] I haven't found that to be the case, but I also have not tried to land a large one recently. [08:21] To be clear: a pre-req branch sounds fine to me [08:21] It's the "automatically approved" part that I'm unsure about. [08:22] Also, I think we still have the notion that an unreviewed branch can "time out" and just be landed, although we don't exercise it very often. [08:22] Which would seem to cover that case (but I would hope we still do not exercise it very often). [08:28] spiv: I think that's the crux of the problem: do we want cleanups, do we want to review them ? [08:30] Yes, and yes. [08:30] In my opinion :) [08:31] I might let poolie have his office back. [08:31] then it boils down to not mixing them up with actual fixes [08:31] The review will often be easy: read the explanation in the cover letter, and then eyeball the diff to feel secure that it is fine. [08:31] Right. [08:32] vila: thats all I asked for [08:33] lifeless: good, I'll try harder then [08:40] lifeless: and sorry for starting grumpy on this subject [08:44] FINISH HIM! [08:44] (sorry. couldn't resist.) [08:45] we hadn't noticed :-) [08:45] i love you, too :) [08:45] mneptok: so how's the new job going since you abandoned us all? [08:48] mneptok: cavemen in mountain fortresses shouldn't throw spears. [08:49] spm: it goes well. busy as hell. long days. but quite rewarding. [08:49] excellent! [08:49] lifeless: i'm touched you noticed my brow-ridge. [08:50] touché! [08:50] mneptok: I've seen the photos [08:50] I went blind. [08:50] :) [08:51] lifeless: you know, i recently got another photo from the same day the "mnep the gigolo" photo was taken. this one onvolves a camisole, a top hat, and clown shoes. [08:51] _LOL_ [08:52] oh, and grandma underwear [08:52] this is a family rated channel [08:52] grandma's part of the family. [08:53] and until i finish chewing through this leash, so am i. ;) [08:55] /m/m lifeless http://mneptok.com/kvf-clownshoes.jpg [08:55] gah [08:55] tab complete fail [08:55] ah well, don't click that if you're under 18 or value your sanity [08:56] I've menepolo'd before. how bad could this be..... [08:56] AAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaa [08:57] * spm reaffirms the desire to NOT click on any menptok.com urls to images again [08:58] am i not hot? [08:59] um... [09:00] 01:45 < mneptok> i love you, too :) [09:00] hahahaha [09:06] * mneptok rm's before Google decides to index that [09:08] Google. Knows. All. Google. Sees. All. [09:09] that's exactly what stephenconroy needs to save us from [09:09] apparently [09:11] Bing knows and sees all, but the Executive Oversight Committee For Strategic Use Of Internet Data And Applicability For Increased Market Penetration can't get the data on their Zunes. [09:12] EOCFSUOIDAAFIMP ? [09:12] gesundheit [09:13] thank you === FryGuy_ is now known as FryGuy- === lifeless_ is now known as lifeless === lifeless_ is now known as lifeless [10:51] poolie_: your _ is showing. [10:57] heh [10:57] as nethack says "you are being punished" [10:58] i think that's actually a _o [11:06] yah ball n chain === lifeless_ is now known as lifeless [11:34] hello === lifeless_ is now known as lifeless === lifeless_ is now known as lifeless [12:19] I'm trying to set up an Hudson instance to build emacs from bzr [12:19] the Hudson bzr plugni tries to do this: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk /var/lib/hudson/jobs/emacs-trunk/workspace [12:19] but its really slow [12:20] jave, is there any reason it needs the full history [12:20] jave: do 'bzr init-repo /var/lib/hudson/jobs [12:21] well, I want it to be compatible with the hudson-bzr plugin, will it work if I do it by hand? [12:21] yes [12:21] lifeless: stuff that has nothing to do with bzr lies in /var/lib/hudson/jobs [12:22] jave: you're right [12:22] add --no-trees to the command [12:22] hmm ok [12:22] thought that may cause it to not work [12:22] ok [12:22] I'd really just do what I initially suggested [12:23] ok, but what happens if I have different jobs with different bzr urls? [12:27] I think I will need special workspace configuration for hudson [12:27] no [12:27] honestly [12:27] just init-repo at the jobs level [12:27] its what everyone does. [12:30] ok === khmarbaise_ is now known as khmarbaise === lifeless_ is now known as lifeless [14:28] * bialix waves at GaryvdM [14:29] Hi bialix [14:29] Hey Gary! [14:29] Thank you for doing release [14:30] Sure - Want it to get into the win installers [14:30] yeah :-) [14:30] how's footbal 'raound you? [14:30] how's football around you? [14:31] Ah - cool. I don't watch it much [14:31] Do you watch it? [14:32] GaryvdM: sometimes. last weeks was a crunch for me :-/ [14:35] GaryvdM: I'm planning to be on vacation in second half of July. And we need to release 0.19 final till August for Maverick. It means I have only 2 weeks for any QBzr development [14:36] GaryvdM: do you have any specific things in mind that I should look at? [14:36] bialix: I'm also planing on taking a weeks leave soon. [14:37] bialix: It would be cool if they were in sync [14:37] so maybe we should release 0.19 final till our vacations? [14:37] bialix: I want to try get at least qcat and qdiff to have a toolbar like qannotate [14:38] for 0.19 [14:38] hmmm [14:38] yep, it would be cool [14:38] I will try to look at qlog labels again [14:38] we have one special case here: bzr qlog colo: [14:39] I've been chipping away at the threads branch. [14:39] I want to see labels as colo:trunk, today it's shown as colo:/trunk [14:39] chip away? what do you mean? [14:41] bialix: It's a saying - If you want to cut through a log, you chip away at it with a axe [14:42] bialix: work on it in small chunks.. [14:44] that means you have slow progress, correct? [14:45] bialix: slow, but steady [14:46] morning GaryvdM, bialix, and vila [14:46] mornign jam [14:46] Hi jam [14:46] heya jam! and bonjour vila! [14:46] bialix: privet :) [14:46] :-D [14:47] bialix: brasil - netherlands should be a nice one ;-) [14:47] Hey vila [14:47] vila: yep, I've heard comments and prognosis [14:48] jam: lp:~garyvdm/bzr-windows-installers/maybe [14:48] jam: I committed rev 119 with --author "John ... - I hope you don't mind [14:49] jam: Please could you do a quick review of rev 120 [14:49] * vila feel depressed, 2.1.0 and 2.1.1 have a test failure: bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures does that ring anyone bell ? [14:50] and 2.1.2 too [14:51] jam: I'm now stuck with a can't find zlib.h build error. Maybe I need to adjust so env var. [14:51] GaryvdM: well, for 2.2 we shouldn't need it at all [14:51] maybe setup.py needs updating? [14:51] or something is importing it that shouldn't be [14:51] I thought mgz tracked those down [14:52] vila: I haven't seen it before [14:52] jam: me neither 8-( [14:52] add 2.2 [14:52] jam: building _chk_map_pyx.c [14:53] GaryvdM: other than not needing zlib.h, the original goal was that the build script would download zlib and put it in the path [14:54] jam: pass in trunk at least (which kind of rules out a weird setup here) [14:54] GaryvdM: so the issue [14:54] is again that igc's new code doesn't grab a tag [14:54] it grabs the latest in a branch [14:55] and lp:bzr/2.2 hasn't been updated [14:55] http://pastebin.org/375070 [14:55] so it is still trying to build old code [14:55] jam: Ah - let me try build bzr.dev [14:55] GaryvdM: _chk_map_pyx.pyx has "cdef extern from 'zlib.h':" [14:55] which shouldn't be in 2.2b3 [14:55] GaryvdM: it looks like we need to do more direct work on ian's code [14:56] and possibly get ahold of him to determine what he had in mind [14:56] vila: does it fail when tested in isolation (and succeed in bzr.dev in the same case)? [14:56] yup: ./bzr selftest -s bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures --no-plugins [14:57] with extensions compiled in all cases (but that shouldn't be relevant) [15:00] fails here, too.... [15:00] makes me think it is a test-tools issue [15:00] jam: forget it, sorry for raising it, unless pqm yelles at you , yeah, ne too [15:01] vila: len(result.failures) == 1 [15:01] I have the feeling one testtools considered something a Fail [15:01] and one considered it an Error [15:01] definitely raises a bell now that you mention it [15:01] so I would say the test should become something like [15:01] assertEqual(1, len(result.errors) + len(result.failures)) [15:01] with a big: [15:02] # Testtools sometimes considered this an Error, and sometimes a Failure [15:02] # so make sure to trap for bothe [15:02] vila: I seem to remember being worried that relying on a 3rd party tool for the test suite would cause spurious failures and lock-step versioning issues [15:02] I'm pretty sure lifeless did a patch very close to that [15:03] total_failures = result.errors + result.failures [15:03] if self._lock_check_thorough: [15:03] self.assertLength(1, total_failures) [15:03] yep [15:03] in bzr.dev [15:03] albeit without the snarky comment against testtools [15:04] hmm, I think I asked for a comment, whatever the content was :) But fater the landing [15:04] after [15:05] anyway, we know how to fix it, back to regular schedule [15:14] vila: feedback on https://code.launchpad.net/~vila/bzr/525571-minimal-lock-bazaar-conf-files-2.1/+merge/29086 [15:19] * vila holds his breath... [15:24] anyone know what might cause this error message when doing a bzr fast-import? [15:24] "bzr: ERROR: The file id "TREE_ROOT" is not present in the tree ." [15:25] vila: sent to the list [15:25] sorry, breathe again [15:26] deep shudder [15:28] jam: a = AtomicFile() ; a.write(data) ; a.commit() ; a.close() ? [15:33] vila: well, a = AtomicFile(filename); but yeah, something like that [15:33] IIRC LocalTransport uses AtomicFile for put() [15:35] GaryvdM: what else is in the environment that you need to copy? (It seems ok, I just wanted to check) [15:37] anyone know if the 2.1.2 installers are looking good? I'm thinking I should extract a nonadmin version [15:38] jam: It was failing like this. http://pastebin.org/371858 [15:39] jam: I thought it would be easy to just copy the env rather than play wack-a-mole [15:40] *easier [15:40] GaryvdM: so the concern is accidentally having an env var like CFLAGS suddenly change your build (and it starts working/failing surprisingly) [15:40] however, I probably agree with you [15:41] I'm fine with just copying [15:41] given that everything else that builds just uses the existing env vars [15:41] we just want to *add* ones for tbzr [15:41] jam: ok [15:48] jam: I think we could maybe extend Project, Plugin, and Application in bazaar_releases.py to include revision specs. [15:49] jam How do we allow for differences in revision specs, with out duplicating all other details? [15:50] jam: Maybe copy and modify? [15:50] GaryvdM: what do you mean duplicating all the other details? [15:51] Are you thinking to have the same code base do multiple builds? [15:51] jam: Differences in plugin version between distributions [15:51] traditionally we just had separate branches for this [15:51] afaik that isn't planned [15:51] but I could be wrong [15:51] I also really don't know the plan for the distribution stuff [15:52]