[00:01] morning poolie [00:01] so much for showing up extra early :) [00:56] hi jam [00:56] heh, well, before 9 :) [00:56] i'll try to push that back to a bit eariler [01:04] i guess lifeless is away travelling? [01:04] so jam how are things for you? [01:08] poolie: things are going fine. I dug into one of the bugs a bit. Basically reconcile on stacked branches is just broken [01:08] mm i saw your mail [01:08] that sounds good to fix [01:09] is that already pointing at 2.2.0? if not you could target it [01:09] yes it is pointing at 2.2.0 (hence why I found it) [01:09] I'm actually targeting the 2.0 series for the fix [01:11] I think it is reasonable to do there, and reasonable to consider it worthy of a backport [01:12] poolie: I had an idea about python compatibility. What if we made 2.0-2.2 be compat back to py2.4, but then expected bzr2.3+ to have a higher cutoff. RHEL 6 is in beta now, so it is likely to come out soon and support python 2.6. Then the bzr versions that are available for RHEL5 will still be compat with py2.4 [01:12] but we will be able to have newer ones have a bit more freedom [01:13] that could work [01:13] so we'd skip 2.5 entirely? [01:13] maybe [01:13] I wasn't sure about going to 2.5 vs 2.6 [01:13] 2.6 would make it easier to support 3.0 [01:13] mm [01:13] at a cost of having our code more wildly diverge [01:13] i'd care a bit more about using 2.6 features than 3.0 at the moment [01:16] poolie: any specific features? [01:16] Context objects would be nice, but I think that is 2.5 [01:17] that's the only one that comes to mind [01:17] 'except Foo as e' is a bit less error prone [01:19] true [01:19] though we've already gotten it right for now :) [01:21] I nearly got that wrong just the other day, but I caught myself :) === nlisgo_ is now known as nlisgo === r0bby_ is now known as robbyoconnor === nlisgo_ is now known as nlisgo [02:19] poolie: hai [02:19] I has 3g gsm goodness [02:19] or something [02:19] hi there [02:19] and is it good? [02:19] want some lunch? [02:21] poolie: sorry [02:21] key doesn't work to the room, locksmith showed up [02:22] uhm yes, lunch could be good [03:19] jam: If you're around, I can debug the loggerjam^H^H^Hhead stuff with you. [06:48] poolie: hi [06:48] poolie: I'd like to treat production relation issues as high/critical [06:48] https://bugs.edge.launchpad.net/bzr/+bug/585126 prompts me to mention this; I want to move it out of 'new' [06:48] uh ok [06:48] Launchpad bug 585126 in Launchpad Bazaar Integration "sendbranchmail is eating memory (affected: 1, heat: 9)" [High,Triaged] [06:49] it seems like 'incomplete' for bzr, for now [06:49] but thats the status, not the importance field. [06:49] What do you think? [06:50] i think i set it to incomplete before the additional data was attached [06:50] if this is causing persistent pain to LOSAs and there's enough data to progress it, let's do something [06:50] its bzr task status hadn't been set. [06:50] are you asking how to triage it, or that you're actually planning to work on it? [06:50] I've just made it incomplete; I was proposing to set the importance too, to something other than medium. [06:50] the former [06:51] I think we would allocate engineer resources promptly to it, if it were actionable [06:51] and that high or critical is reflective of that. [06:51] I think I'm asking for high, not critical, on reflection. [06:51] ok [06:51] its not severe enough to block a bzr release, whatever it is. [06:51] i don't think it's critical unless a losa is actively complaining about it [07:08] I'd really like a 'user error' rather than 'invalid' bug status [07:08] because it might be very interesting to do data searches on em [07:08] and it might feel kinder [07:08] mmm, could be argued to be ui issues anyhow, I guess. [07:09] hi all [07:10] hi vila [07:21] lifeless: you could add a tag, I guess. [07:21] yes; little unsatisfactory [07:22] \o/ 1 bug to go [07:22] or is there... I might be done on this pass [07:24] spiv: is there a webnumbr for 'new' bzr bugs ? [07:24] cause its 0 [07:24] :> [07:24] hi vila [07:25] lifeless: yeah ! [07:25] lifeless: there's an lpstats graph [07:25] hey poolie [07:25] hey [07:25] poolie: yeah, but thats all like 80's UI and so on [07:25] those are some epic test suite patches [07:25] poolie: nice catch for the 2004 copyright [07:28] spiv, still here? [07:28] spiv, do you have any qualms about me merging the hpss flush() patch? [07:30] poolie: No qualms [07:30] poolie: hehe, yeah, epic ;) And I didn't even take some suggestions from spiv and lifeless into account yet (and I realized in the middle of the night that some minor changes haven't committed for windows (hackish workflow involving a babune slave)) [07:30] lifeless: not yet, feel free to make one. [07:30] vila are we there yet? [07:31] where ? [07:31] the proposed patches are a definitive step^W staircase to make the tests pass on windows [07:31] k [07:31] the proposed patches are a definitive step^W staircase to make the tests pass on windows [07:31] i guess that would be nice [07:31] grr [07:31] it would be nice to lock it in [07:32] the missing bits can come later or during review [07:32] it's not really a high priority goal for us atm though [07:33] I realized that, but on the other hand there are several demands for more features on babune which are not reasonable to implement if the test suite does not pass for windows [07:33] (python-2.4, plugins, installers, etc) [07:35] true [07:35] if it's not totally green it will slip back [07:35] thus my wondering how much more we'd have to do [07:35] yup, and the leaks were a total blocker [07:35] mm [07:36] with my patch we're down to 4/5 failures [07:36] i've seen them trying to run under tribunal too [07:36] on linux [07:36] i'm not sure why, but i suspect it causes different concurrency patterns between threads [07:36] if the main thread often blocks [07:36] lifeless: after that thread about python3 i think we should reject your merge [07:36] I've fixed so many different possible hangs that I can't even guess which one you're encountering :) [07:37] on the grounds that getting to a single codebase from 2.4 through to 3.1 probably won't work [07:37] is that ok with you? [07:37] :) [07:37] poolie: I'm ok with it being rejected given the wait and see approach that we seem to have settled on in the thread. [07:37] well [07:37] I disagree about 'probably' and 'won't' [07:37] :) [07:38] you think we certainly can get a single tree that works on 2.4 and 3.1? [07:38] 'would be fugly' [07:38] poolie: I'm quite certain its doable, I'm not certain its desirable. [07:38] 'single non-gross codebase' [07:38] poolie: :) [07:38] so i wasn't exactly proposing wait and see [07:39] but rather, get 'python -3' clean, and then try using 2to3 [07:39] poolie: It may be the lesser of two evils, all things considered, but I don't have enough info or practical experiments run with 2to3 to make an assertion about that. [07:39] as a though experiment [07:39] there is no syntax for octal ints that works on both [07:39] poolie: yes, thats the wait and see approach I referenced, and because of that I'm happy to reject that patch. [07:39] we can either rewrite them all to decimal [07:39] or, we can keep them in 0666 syntax and use 2to3 with only the octal syntax rewriter turned on [07:40] poolie: we need 2 octal ints I think; consolidate to osutils.USER_RWX and USER_RX, or something. [07:40] obviously this is a pretty tiny example [07:40] but my point is that the second seems at least possibly as good [07:40] poolie: or even use the constants in the os module, or wherever they are [07:40] sure [07:40] it's just an example [07:40] poolie: right [07:40] poolie: we lack data [07:41] poolie: all concerns aside, we have a plan to get more data. So lets do that. [07:41] great [07:41] poolie: We have different opinions about what the data is likely to tell us. [07:41] poolie: which is fine :) [07:45] int('666', 8) works in both 2.4 and 3.1 [07:45] evil... [07:45] heh [07:45] spiv: \o/ [07:46] I wouldn't want to put that in an inner loop :) [07:46] no [07:46] but when we're that much into tuning we get into function params etc anyhow [07:46] so we could do it there [07:46] but perfectly fine as osutils.o666 [07:47] sure [07:47] sheesh _example_ [07:47] though I'd name it better [07:47] _bike shedding_ ! [07:47] perhaps 'except Foo as e' is a better example [07:47] poolie: we're a fun company of non pedantic individuals [07:47] it's a purely mechanical transform [07:47] Hmm [07:48] I suspect you could write a [07:48] except:\ncatch(Foo, 'e') [07:48] that would work on all python versions. [07:48] and make folk cry if they ever read its internals. [07:48] probably [07:48] (not suggesting it!) [07:49] might be a bit messy if you needed multiple catch branches [07:49] so as far as automating code translation, my vote would be to target 2to3 while we support 2.4 and target 3to2 when we switch to support mainly 3.x [07:49] vila: I think that this is too early to talk about [07:49] we don't know if 2to3 will work well yet; we're going to gather data [07:50] sure, my bet is that we'll end up carrying our own 2to3 if only to take our idiosyncrasies into account [07:50] but I'll shut up now ;) [07:51] vila: I mean *even doing that* - pretty much every has to add fixers, its part of the design of 2to3 (to be an 80% solution, local knowledge fixes local gaps) [07:51] just wanted to mention I've done my share of automated conversions from os1 to os2, langugae1 to language2, db1 to db2, and so on [07:53] yup, the workload is always split across: fix the translator, fix the input [07:53] we have a big advantage here with our test suite... [07:53] make that BIG [07:58] poolie: oslocks [07:58] poolie: and dirstate [07:58] ob: must die [07:59] I've just been doing bug stuff :) - but I was reminded that while we *could* fix the concurrent use of st and diff with commit by moving to a separate stat cache - so we don't write to the dirstate when we run iter_changes [07:59] that wouldn't remove the os locks and the locks themselves are a cause of bugs with corrupt dirstates not being written to disk, bad out of space behaviour, and AFS/NFS issues. [07:59] morning all [08:00] poolie: so its rather solidified my opinion that we really do want the complexit of a pack-like structure for the dirstate, and the separate stat cache *at most* reduces the writer concurrency requirements on that structure. [08:00] vila: well yes, but its more nuanced than that ;) [08:01] hehe [08:01] it has a cost, we need to know what we're buying :) [08:06] i think i agree with that [08:06] not sure what you mean by "at most" though [08:13] lifeless, vila, https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/27582 is updated per your comments about using overrideAttr [08:14] thanks [08:14] looking [08:15] poolie: I mean that if split out the stat cache again, it doesn't fix the os locks or make the pack-like structure on disk for dirstate much simpler; it only removes one of 3 or so requirements [08:15] right [08:15] i don't think just splitting it out would be worth a format bump [08:18] i'm sending the hpss flush patch to pqm [08:20] kk [08:21] I'm 'waiting for bugs.edge.launchpad.net' [08:30] oh, foo, parthm is gone again [08:34] poolie: rereviewed [08:35] spiv: ping [08:36] spiv: I know its EOD, but hpss effort tests + foreign formats, could use some airtime [08:37] poolie: approved, oh lifeless reviewed it too [08:38] so, yeah, see https://bugs.edge.launchpad.net/bzr/+bug/597791/comments/1 [08:38] Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed] [08:39] the tests pass, I've just checked, TestActivityMixin.setUp() calls TestCase.setUp() so the code is right but ugly [08:39] losa ping; what version of testtools is installed in the balleny bzr pqm chroot please [08:40] I want to know what features are available :) [08:40] lifeless: 0.9.2-1~0.CAT.8.04 [08:40] thanks heaps [08:41] poolie: this patch will certainly conflict with my cleanup patch so it will be simpler for both of us if you land yours first and I'll address the conflicts with mine [08:41] lifeless: like the loom issue? [08:41] precisely and [08:41] I can solve that one easily [08:41] its rather specific [08:41] just convert to a matcher and provide an Or test in there [08:42] Perhaps related, it would be good to start thinking about extending the smart protocol in the loom plugin [08:42] spiv: I have been :) [08:42] e.g. maybe add a verb for set_loom_state? [08:42] Oh, great! :) [08:42] spiv: ignoring questions about what level to operate at, it raises questions about how to add the client side [08:42] the server is nicely extensible [08:42] the client side proxy rather less so [08:42] Right. [08:43] and I'm thinking perhaps the _real_format could add methods [08:43] make RemoteBranch more of a composite [08:43] anyhow, neither of those things would make the test better, because plugins will want to call different verbs [08:43] and we trace verbs [08:44] spiv: for loom it happens to be easy, but what about e.g. bzr-svn [08:44] spiv: if you have an svn repo [08:45] and access it via bzr push bzr+ssh://host/svn/repo/branch [08:45] > [08:45] Yes, what indeed. [08:45] I don't have answers [08:45] I suppose one answer would be to allow the plugin to set its own call-count requirements. [08:45] the test isn't structured quite that way, but we could rephrase it. [08:45] Another would be to say that this test is format specific [08:46] but that adds a burden if/when we rev formats [08:46] Or something like "here's the call trace core bzr expects, and core bzr will match that specific trace. Plugins can override that trace and/or matcher." [08:47] yeah that too [08:47] You could have extreme corner cases with e.g. inter-branch tests from one plugin format to another plugin's format. [08:48] definitely [08:48] so [08:48] I don't have any great ideas. I'd be very happy to start with whatever is needed for looms tests to pass without feeling too ugly. [08:48] I'm inclined to lowbrow it right now [08:48] +1 [08:48] and hard code in 'get is ok' [08:48] [a single get] [08:50] That's ok with me. For now the main concern is "confident the core is not regressing", followed by "loom can pass tests", I think. I think you can hard code and meet those goals. [09:02] spiv: what do you think: [09:02] http://pastebin.com/4XLwfMdJ [09:02] ...or merge loom into bzr-core [09:02] vila: that wouldn't help [09:03] vila: because the loom format would still behave differently. [09:04] lifeless: looking now [09:05] lifeless: I worry about the risk that the core could regress with that patch [09:05] lifeless: sure, but the issues will be easier to address, anyway, I don't think it's the right time for this, just mentioning it as middle term goal [09:06] other than that, it looks reasonable. [09:06] I think it's one more case where we want the parametrization to be more pluggable for plugins [09:07] vila: I really don't see it being easier [09:07] vila: different maybe. [09:07] spiv: anything I can do to mitigate your concern ? [09:07] spiv: scratch that. Anything *you want me to do to get +1* on the patch :P [09:08] core mentioning loom (an external plugin) is wrong, if it was in core it would be right [09:08] lifeless: perhaps some sort of "if purely_core_scenaro" guard? Not sure. [09:09] lifeless: for this specific case I'd probably accept an convincing argument that the practical risk of the core regressing in exactly that way is low :) [09:09] its very low. [09:10] vila: if it was in core, in a per_interbranch parameterised test, its still wrong. [09:10] vila: abstraction leak; we're being pragmatic about time and goals here is all :P [09:11] spiv: concretely [09:11] spiv: the test claims that it tests for get_parent_map missing [09:11] spiv: so its overly sensitive in using an exact list [09:11] the test is about: "he client has no reason to query the remote graph any further" does loom cares here ? [09:11] hehe, we agree :) [09:11] spiv: this test change does not open the door for get_parent_map [09:12] vila: loom in general - yes. In specific , no. [09:12] in general yes because it does push-per-thread [09:12] yup, may be the test is too high-level === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [09:26] spiv: I'm going to propose it as a merge; vila may +1 it :> [09:27] lifeless: as long as it includes a comment explaining the constraints here, sure ;-) [09:30] vila: well, its the patch I put up. [09:31] vila: you wanted a passing test suite; its up to you :) [09:32] which patch ? The one you pasted ? [09:32] https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/28375 [09:32] yes [09:35] weird, it didn't appear in the active review page until you mentioned it here :) [09:35] lifeless: approved, please land [09:36] vila: can you toggle the merge bit too in future, please [09:36] grrrr [09:36] sorry [09:36] done [09:39] Am I the only one who keep forgetting that merge bit ? [09:39] no [09:39] I want a cron job [09:39] that assesses the votes and sets it [09:40] ha cool [09:40] oh, and thanks for that fix, I will get rid of my workaround as soon as it lands [09:58] poolie: another thing I find annoying about gmail - the use of first names only [09:58] I know many Martins, and many Johns. [09:58] vila: btw [09:59] vila: threads in paramiko: teach paramiko to accept a thread factory replacement parameter. [10:02] lifeless: yes, that's probably the way to go but I felt too weak to go there and there may be a different way to run the paramiko code into the threads we already have (the way the test server implementation without ssh support works is an hint) [10:03] but overall since the paramiko daemonic threads appear to die naturally I punted :-> [10:03] vila: for sftp it makes its own ones, I think [10:04] it makes its own ones as soon as it needs a wrapper for ssh [10:04] at least they are the only ones I left [10:06] and it uses timeouts there which... re-open the same can of worms I was getting away from, so, as long as it works... I prefer to left it as is as I know it will be a nightmare to debug and probably hardly fixable without fixing paramiko which in turn will make it harder to keep it as an external dependency [10:06] huge effort, small reward :-/ [10:36] vila: timeouts are fairly good for defensive programming [10:36] vila: I wouldn't want to get rid of them [10:50] mgz: you'll be glad to know we broke subunit trunk with our patch [10:50] mgz: 58 errors :) [10:52] mgz: some of which are testtools bugs [10:54] how do I stop getting bzr bug mail [10:54] I think you have two choices [10:54] you can either leave the relevant control team [10:54] or you may be able to individually explicitly subscribe to all the bugs in the same place the team is subscribed [10:55] with a subscription of 'I'm not subscribed' [10:55] its the same conflation of 'power/access/interest' pattern we have in LP [10:55] jml: oh, and I'm sorry if I tripped your 'zomg' threshold with bug spam today. [10:56] lifeless, not at all. it's been bugging me for a while. [10:56] lifeless, I like bzr a lot, but I never ever read the bug or MP mail any more [10:56] Hello. Does anyone know how to migrate multiple related Mercurial branches to Bazaar? I know I have to use --marks/--import-marks/--export-marks, but it doesn't seem obvious to me how to do it and I cannot find anything in docs or the Web. All I find is documents explaining how to migrate from bazaar to git using marks. [10:56] gustavonarea: can't you just install bzr-hg ? [10:58] lifeless: it hangs the computer and then gets killed by the OS [10:58] oh, thats a little undesirable [10:59] And that happens on a high spec server; I wouldn't try it on my laptop [11:00] any idea how to do it with fast-import/export? [11:00] not personally sorry; maybe the bzr list, or the bugtracker, will know more. [11:02] thanks lifeless! I'll stay around just in case :) [11:03] mgz: I've pushed a one-character fix; so small I'm not even going to ask jml for a review. [11:05] lifeless, don't you care about quality?!?!!!!1!!??!? [11:05] jml: no, not at all. [11:07] mgz: jml: anyhow, trunk of both play nice together once more. [11:09] \o/ [11:09] lifeless: timeouts lead to hard to track bugs with threads and sockets in our case, they *are* good for defensive programming but they shouldn't be used to work around synchronisations issues (which was the case here) [11:10] vila: agreed [11:15] lifeless: I think I don't understand what you're after in the smart-server-leaks threads, I just posted a comment but discussing it here may be more effective (if you're still available) [11:15] s/threads/merge proposal/ [11:16] vila: you appear to have done the following: [11:16] - rearranged some code [11:17] - added a new, strange, public method which users would not expect to have to call [11:17] I am neutral on the first and against the second [11:17] vila: I don't understand why the second is needed [11:17] if I understood why, I would stop being against it :) [11:18] I would like to see internal behaviours kept internal [11:18] because I want to reuse most of the code there but *not* creating the server socket as part of building the object [11:18] I may have it wrong; it may still be internal and the diff is confusing me [11:18] vila: I don't mind if the creation is separate to building the object, thats orthogonal to my concerns [11:19] well, the actual code does too much in __init__ for my needs so the socket creation has to be done outside of it [11:19] sure [11:19] I can create a base class to address that but that sounded too bug a hammer [11:19] big [11:19] I repeat, I'm fine with the separate method. [11:20] I'm not fine with who has to call it [11:20] now, I don't think users *have* to call it as it's now called by the smart server factory, [11:20] if it was called start() I would be fine [11:20] ha, ok, so public and a better name ? [11:20] vila: the smart server factory is a user of the class the method is on [11:20] the connection between the two should be clear, or the factory shouldn't exist. [11:21] by which I mean, if we have two components, we should have *two* components, not one-and-a-half [11:22] hmm, there is already start_background_thread/stop_background_thread but no start/stop >-/ [11:23] why isn't it part of one of those methods, for instance? [11:23] cause I'm lazy ? :) [11:24] heh [11:24] I'm lazy too [11:24] I think I'd have tried to find a way where i didn't change callers. [11:24] kidding, because I was unclear about how this class was used and wanted to just pick the good bits [11:25] my overall feeling (backed by some discussion with spiv) is that the actual design is *good enough* and I think we may want to improve it but I didn't want to do that as part of my patch [11:25] not a good reason to make it worse though [11:26] right [11:26] I fully agree with that [11:27] hmm, the server factory has a set_up/tear_down but don't use start_background_thread/stop_background_thread... that's part of the friction I think [11:30] hmm, and start_background_thread/stop_background_thread is, in fact, used by TestSmartTCPServer for a single test and overlap with TestingTCPServerInAThread too >-/ [12:10] How can I add an alias to my branches, like "lp" for launchpad.net? I've check the docs and searched for this on the Web but I didn't find anything [12:10] bzr-bookmarks plugin [12:10] I think [12:11] I'd like to something like "bzr branch foo:trunk" where "foo:trunk" gets translated to "bzr+ssh://example.org/path/to/trunk" [12:11] ah ok, thanks lifeless [12:12] gustavonarea: See http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html, I think for the style of prefix you want, you might need to write a tiny plugin of your own [12:13] cool, thanks maxb [12:15] maxb: any pointers on how to write a plugin like that? [12:15] the bookmarks plugin :) [12:16] ok, thanks vile [12:16] * vila [12:16] Or the built in launchpad plugin [12:16] yup, as maxb said, but the lp plugin do more than that so may be harder to grasp [12:17] The bzr feature that you need to interact with is called directories [12:30] thanks maxb! === khmarbaise_ is now known as khmarbaise === verterok_ is now known as verterok [16:25] when working with feature branches and a trunk - if I am merging feature branches into trunk - which is a better workflow? merging trunk into feature, then feature into trunk or just try and merge feature into trunk (ran into a case where it wasn't pulling all the changes from a feature until I merged trunk into due to weirdness with reverse and forward merges) [16:25] (my problem is resolved - I was just wondering for future reference what the preferred workflow is) [16:28] I normally go by a gut feeling of "are there going to be non-trivial conflicts to resolve?" [16:29] If it'll land easy, JFDI. If not, do the merge in the branch and deal with the fallout, then land it. [16:29] And then kick yourself for not pre-emptively merging trunk into feature on a regular ongoing basis in the first place :p [16:29] fullermd: cool - thanks (or yell at the people working on the feature for not pulling in :) [16:50] fullermd: fwiw, that's the way I do it too. === beuno is now known as beuno-lunch === cody-somerville_ is now known as cody-somerville === radoe__ is now known as radoe === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === deryck[lunch] is now known as deryck [19:26] good morning [19:27] hello [19:39]