[00:06] poolie: would you like to have lunch? [00:06] poolie: today I mean [00:06] mm [00:06] i would [00:06] i have to finish circa 5 [00:06] rather than 1 :-O [00:06] this sounds compatible so far [00:07] the bad 1 o'clock that is [00:07] I'll be finishing ~ 2 I imagine [00:07] wish I knew why i'm waking so early [00:07] but it sure is peaceful to be hacking - no trucks or traffic [00:08] anyhow, if you'd like to have lunch, so would I. So we should [00:19] sure [00:19] pick a place [00:19] meeting here would let me work more [00:19] meeting somewhere at the end of a motorcycle would add joy to my life :) [00:21] poolie: you're not seriously asking me to choose between you working or having joy? [00:22] poolie: thats rather faustian :) [00:22] uhm, I could go pie. Or vietnamese. or $other [00:22] one of us needs to choose :) [00:22] lets say pie [00:23] i am enjoying my work [00:23] ok, here? [00:23] poolie: yes, bzr-mac [00:23] wfm [00:23] morning all [00:23] great [00:23] done [00:23] 12ish? [00:23] igc, i was thinking about platform-specific bugs [00:23] or is that too early for your stomach [00:23] i suspect non-core people aren't subscribed to bug mail, or don't read it [00:23] in fact core people probably don't read all of it [00:23] should we maybe explicitly forward or subscribe platform teams to relevant bugs? [00:25] lifeless: wfm, i woke about 6.30 [00:28] poolie: maybe. I'm not sure if there would be any backlash against that or not. We could ask if anyone objects? [00:29] ok [00:29] poolie: there's certainly value in asking the teams to test platform specific fixes [00:29] i've had some success in the past pointing them out on the main list marked with eg win32 [00:30] i guess the question is whether they're platform test teams or platform dev teams [00:30] poolie, jml: can users/teams subscribe to bugs with certain tags? [00:31] igc, I don't believe so. It's quite possibly a filed bug too [00:34] vila: still here? [00:34] igc, i was wondering the same thing [00:34] it's probably better to just subscribe the team [00:35] i think it's probably not appropriate to subscribe the whole team to all relevant bugs [00:35] (maybe they want it) [00:35] but we could make ~bzr-win32-bug-team [00:36] poolie: do you want developers or qa-on-fixes [00:36] developers [00:36] poolie: if its qa on fixes I'd suggest ~bzr-qa-PLATFORM [00:36] primarily [00:36] i think some of these bugs are shallew [00:37] btw did you have any luck with wine in the case we mentioned yesterday? [00:37] poolie: no, it was on my todo to experiment today, but late last night bialix said it works [00:37] how sad :) [00:39] its terrible fixing bugs and stuff [00:39] bialix is going to try and get a 1.18.1 prepared with the windows fixes [00:40] Whats really a shame is that all of them were very shallow. [00:41] does buildbot actually run ascii tests specifically at the moment? [00:49] i don't know [00:49] i don't think so [00:49] but it sounds like vincent will add it soon [00:55] lifeless: oh, actually unfortunately i can't do lunch today, i have to do something for s [00:55] ok [00:55] no wakas [00:55] monday could be good, let's talk then? [00:57] friday or tuesday would be better for me [00:58] k [00:58] poolie: can you clarify vila's email last night ... [00:58] mm, which one? [00:58] about the rc? just done [00:58] poolie: the one that said rc1 vs beta1 [00:58] and lrelease date early next week [01:00] ah, i didn't see that about the release date [01:00] poolie: so to confirm, rc2 next week [01:00] poolie: and 2.0 the week after [01:00] if 2.0 is next Monday, that impacts what I'll do today! [01:04] poolie: would tomorrow work foryou? [01:04] igc: yes [01:04] was i insufficiently clear about what i wanted to happen or was vincent just a bit random here? [01:04] probably both [01:05] poolie: I think unclear; I know I've been unclear [01:06] *I've been unsure* [01:06] I was asking you yesterday whether this should be done before we're finished with the critical bugs or not, and you said not-before, but this seems to have happened before they are fixed : I don't really know where we stand. [01:07] poolie: I thought it was clear-ish but it's a change in process and we'll still finding our feet wrt monthly vs otherwise [01:07] poolie: 1.18 is yet to be announced for example IIUIC [01:07] true [01:07] what's "this"? [01:08] 2.0b1? at that time all of the 2.0 critical bugs were closed, i believe [01:08] doing a 2.0 b1 [01:08] poolie: jam is working on the fragmentation issue, I'm working on the pushing of 1.9 stacking against 2a issue [01:09] 415508 and 402645 were still open [01:09] bug 415508 [01:09] Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508 [01:09] ! [01:09] it shouldn't be [01:09] poolie: also when you said critical I heard 'targeted to 2.0' not 'critical' [01:09] which is a hearing defect [01:11] we have non-2.0 bugs marked critical [01:11] um [01:11] poolie: I'd like to either untarget, or bump to critical, all the non-critical, non-fixed, bugs targeted to 2.0 [01:11] I think it will make sure you and I are on the same page [01:11] i'd like to either degrade or target all the critical bugs [01:11] so the non-critical bugs targeted to 2.0 are meant to be things we'd like to fix, or would consider merging [01:12] this might be an unhelpful distinction compared to just looking at the high/critical lists generally [01:12] so, um [01:12] i think both those changes are good [01:12] but let's do them one-by-one not wholesale [01:12] and then if we find a case that seems to invalidate the approach we'll reconsider it [01:12] I strongly desire that targeted means 'will delay release' [01:13] mm, me too [01:13] not having them critical seems to make them mean something different to you [01:13] i found that yesterday required more thinking than was optimal [01:13] or more thinking of a kind of overhead category [01:13] ok bug 416732 [01:14] Launchpad bug 416732 in bzr "check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch" [High,Confirmed] https://launchpad.net/bugs/416732 [01:14] targeted to 2.0. SHould block it IMO [01:14] lifeless: that's what "blocker" means in GNOME. Actually, "blocker" (if confirmed as such) means «holy shit, stop everything, and there will be a release about 30 minutes after we figure out the problem» [01:14] bug 402645 you mentioned before [01:14] Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645 [01:14] poolie: lets do this over the phone; it will be quicker [01:14] mm [01:14] let me finish something here first [01:14] then i'll call [01:15] ok [01:15] lifeless: so yeah, I guess that's what "critical" means there too [01:15] it's all very informal [01:16] so the key question is [01:16] should there be a category of 'wannabe blocker' or 'kinda blocker' [01:16] AfC: there are two dimensions here; one is 'before this release', the other is 'what should a dev look at next' [01:16] it seems to cause mental pain for the RM and may have no benefit [01:16] poolie: I don't think there should be; it should be a blocker, and if someone disagrees they stop it being a blocker. [01:17] make the decision and make it easy to change if wrong. [01:17] lifeless: the answer to the second question is always "my manboobs" [01:17] mneptok: no, never. I'm sorry, but goram-no. [01:17] lifeless: well, the later is task prioritization, and I've never found bug trackers are good for that. Anyway, topic for beer. [01:17] lifeless: so much for the adventurous and brave spirit of New Zealanders. [01:17] mneptok: ba! [01:17] lol [01:25] lifeless: your phone seems engaged, call me when you're fere [01:25] free* [01:25] as in beer [01:39] poolie: doing [01:40] poolie: your phone rang out [01:43] * lifeless tries again [02:06] poolie, ping? [02:06] beer? [02:06] I like beer. [02:07] mneptok, stay classy :) [02:07] * emmajane reads backwards in time. [03:05] poolie, reply sent. :) I'll be back in a bit for a little bit. [03:17] lifeless: you only get knit-delta-closure etc if you pass "include_delta_closure=True" which doesn't happen for normal fetches, only when someone wants fulltexts. [03:17] so you end up getting every little bit of content as a separate 'substream' in a normal fetch [03:17] 2a would be different [03:17] though I think it would be 1 group per substream [03:18] which still isn't great [03:18] and means that the target repository won't really have a chance to do batching [03:18] since it won't get all the groups in a single 'insert_record_stream' [03:18] you would have to batch between the streams... [03:18] jam: it's still the same write group, though. [03:19] spiv: sure... still sort of violates what I thought substreams were abouet [03:19] jam: wish you were here. Then I could buy you a coffee. [03:20] Well, it's explicitly allowed for there to be multiple substreams of the same kind. [03:23] It would be more elegant to turn the stream from the request into a continuous object stream, but Python doesn't make that easy to do. Well, we could add more threads... [03:23] spiv: sure. but 1 record at a time is not really a bunch of *streams*, but more, a bunch of records... :) [03:23] also, Repositories know about write groups [03:23] VF's know about record streams [03:24] so you would have to figure out how to have the VF know about the current Repo's write_group [03:24] which is a small inversion [03:24] or have Repo.commit_write_group() tell the VF.flush_your_buffer() [03:24] Well, for 1.9 pack repos I don't think there was any practical difference between insert_record_stream([2 records]) and 2 insert_record_stream([1 record]) ? [03:24] (and dump_your_buffer for abort) [03:24] Because it's the write group that allocates the pack file. [03:25] spiv: present day there isn't for 2a [03:25] I would *like* to regroup on-the-fly [03:25] given the discussion about fragmentation and recombination [03:25] I can't regroup if everything I see is a single record-at-a-time [03:25] Ah, I see. I was trying to figure out why you cared :) [03:34] bzr 1.18 is out or will be immenently right? (ie, it's ok for me to "advise" people that they really ought to be using bzr >= 1.18 on a website & in release notes for something I'm cutting today or so?) [03:35] AfC: 1.18 is out, the announcement hasn't hit pending the building of all packages for all platforms [03:35] the code is cut, though [03:36] k [03:36] close enough [03:45] 2009/8/27 Mary Gardiner : [03:45] > Why say "can we upgrade this to critical" when you mean "can we fix this?" [03:45] > -- Martin Pool, twitter.com [03:45] great sig :) [03:46] heh [03:46] Heh. [03:47] Wait. We're supposed to FIX them? [03:50] poolie: I've just mailed the list with I think the pith of our chat [03:51] spiv: jam: it would be quite easy to daisy chain all the substreams of the same kind together in the insert_stream method [03:55] > "Do not assign bugs to other people unless you are confident they will work on them." sounds like some people can avoid getting bugs assigned to them altogether :) [03:55] but no one on this team :) [03:57] poolie: if you assign a bug to me, its == 'hey robert, please fix this for me' [03:57] and I'm very unlikely to unassign it immediately. [03:57] * igc lunch [03:57] mm [03:57] i'll reply in mail [03:58] I've seen fairly regularly in other areas, assign-to-someone being used by users to get their bug looked at [03:58] I think that was before the permissions on the assigned field were straightened out [04:00] what is 'staying stay' supposed to mean? [04:02] blah, typo [04:02] just switching folders. [04:06] poolie: staying stale [04:07] poolie: as data: https://bugs.edge.launchpad.net/~mbp/+assignedbugs :) [04:08] would bzr reconfigure --append-revisions-only be a useful feature? [04:08] mwhudson: yes! [04:09] Only I'm not sure I'm sanguine with it in reconfig. [04:09] lifeless: is there an easy way to set it at the moment? [04:09] mwhudson: vim [04:10] fullermd: got a better place? [04:10] Unfortunately, no. We should have a place for a lot of things like that. [04:11] And reconfigure is a great command for it. [04:11] But it's currently fairly purely "reshuffle the arrangement of bzrdir components", and I don't like mixing that with "set branch config options". [04:11] mwhudson: init has a flag for it, so check the cmd_init code. [04:11] fullermd: and repository options [04:11] mwhudson: api wise its easy [04:12] lifeless: i know [04:12] branch.get_config().set_user_option() [04:12] they're some of my favorite bugs [04:12] Yah, I know. I put that one there, remember :p [04:12] it may be too large of a queue but they're also things that i want to do in my slack time, if any [04:12] poolie: o/~ these are a few of my favourite things [04:12] Still a bit uncomfortable with it being there, though. [04:12] it may be there's some better place to store that [04:12] poolie: Would you be happy having an mbp tag on the tracker? [04:12] mm [04:12] maybe [04:13] tags are still harder to use [04:13] there is this 'bug list' feature that's meant to do exactly what i want here [04:13] no idea when that will be done though [04:13] I get concerned when I do something with someone else assigned to it. [04:13] to the point that I don't do those things. [04:13] or do them less often [04:15] ok [04:15] that's definitely a problem [04:15] some of this stuff is like working in python [04:15] nice, but you have to work with what you've got [04:15] s/.*, // [04:15] ie encoding all the bugs as tuples :-/ [04:16] :P [04:16] I like that we can file bugs on launchpad in launchpad. [04:49] thumper: will pyconz be briliant or just ok? [04:55] lifeless: I have no idea [04:55] lifeless: I expect it to be at least ok [04:55] very close to uds [04:56] I'm trying to decide if I should come to pyconnz and give a lightning talk on fixing unittest [04:56] amongst other things [05:03] lifeless: i think you have a good point about assignment actually [05:03] i've just had enough metadevelopment for today [05:04] poolie: thats fine, I have too [05:05] I was expecting a 3 minute call :P [05:05] :-) [05:16] spiv, igc, either of you want to catch up? [05:16] now would be good for me [05:17] poolie: sure, I'll call [05:17] poolie: I've EOD'd [05:24] Hi, I just started using bzr (and I've absolutely loved it, especially the bzr-svn module), but had a couple of new user questions. Is this a good place to ask them? [05:27] I created a test branch from an SVN repository and then posted it to my server. From there, I made a "working" branch that I could experiment with. However, whenever I post anything to the working branch, it also posts to the main branch on the server via SFTP. Is that normal? And if so, is there any way to disable it? [05:45] RobOakes: How did you make the working branch? [05:46] The first branch I created by using bzr push from within the SVN working copy. It took four days, but eventually it created a bzr branch of the code. [05:47] The "working" branch was created from that initial export using bzr branch /path/to/original [05:47] What does 'info' tell you in the working branch? [05:47] lifeless: ooh, when's pyconnz? [05:48] mtaylor: you mean kiwipycon?~ [05:48] It says "checkout of branch sftp://path/to/branch" [05:48] Related branches push branch: sftp://path/to/branch [05:48] mtaylor: http://nz.pycon.org [05:49] * mtaylor is always looking for excuses to go places... [05:49] mtaylor: where are you based? [05:49] RobOakes: Right. So you didn't make a branch, you made a checkout (either by running 'checkout' instead of branch, or later using 'bind' or one of its relatives). [05:49] thumper: seattle [05:49] * mtaylor now notices that CFP is open for US pycon [05:49] mtaylor: we'd love to have you :) [05:49] Okay. Is there any way to unbind it? [05:49] RobOakes: You want to turn it into a separate branch if that's what you want, with e.g. 'unbind'. [05:50] mtaylor: it is just a weekend though [05:50] mtaylor: we're only just starting out [05:50] Very, very nice. I just tried a test commit and it looks like everything is working. Now, when I want to update the remote branches, I use bzr push, right? [05:50] thumper: I'd love to come! you know, I'm sort of low on flying miles this year... [05:50] mtaylor: need to keep that gold membership? [05:51] RobOakes: Right. [05:51] thumper: yes! [05:51] thumper: if I lose it, they'll stop upgrading me places, and that would make me sad :( [05:51] mtaylor: you could talk to me in person about code reviews [05:52] thumper: oooh. now there's a business reason to come [05:52] Got time for a second question? Because of reasons too complicated to go into, I do most of my development work on a linux virtual machine. However, the actual files are stored on the physical hard drive and accessed through an interface. [05:52] For reasons I don't understand bzr seems to think that the file permissions change, quite frequently. This leads to very big (and pointless commits). Is there a way to tell bzr to ignore changes in the file permissions? [05:53] The only permission bzr watches is the +x. That really shouldn't be changing around unless you're flipping it... [05:54] mtaylor: mid nov [05:54] (I mean, depending on just what the 'interface' is, it may not mean much, but it shouldn't be _changing_) [05:55] I'm not, but the way vmware handles it's remote directories is weird. Sometimes, they mount as 777 and sometimes they mount with other permissions. [05:55] I still haven't quite figured out the overall method to the madness. [05:55] That's... pretty insane. [05:56] Anyway, making bzr ignore it would really be hackaroundish. Wouldn't be my choice of how to handle it. [05:56] But given that, no, AFAIK there's no existing config option to say "ignore +x totally plz". [05:56] Agreed. My plan has been to watch the permissions and only commit when they are 777, this prevents the nasty problem. [05:56] Maybe you could thunk something in with a plugin, but that's way outta my league. [05:57] I may think about doing that. My first desire would be for VMware to tell me why the permissions in the vmfs module are all crazy. [05:58] Vague memory tells me there is (or was) a plugin to try and allow some +x handling on win32; that might be a place to start. [05:58] I'll take a look at that. I'll look through the devel mailing list and see if I can find anything about it. [05:59] Maybe write a plugin or shell alias that checks that a) a file that should not be +x is indeed not, and b) a file that should be, is. Then abort/warn before commit as appropriate? [05:59] Oh, good, somebody competent is here. I'll leave you with spiv 8-} [06:00] That would help solve the problem, and wouldn't be too complicated. [06:00] Anyway ... thanks for the help. That clears up most of the miscellaneous questions I had. [06:00] That would catch any sort of weird "all mounted files get +x"/"all mounted files lose +x" condition. [06:00] And hopefully you can fix the root problem :) [06:00] * spiv grabs a late lunch. [06:01] Agreed. What's funny is that I don't seem to have the same issue with my svn working copies. (But I also haven't spent much time testing it. I figure it's a weird VMware thing.) [06:54] hi all [06:55] lifeless, poolie : the test are run with and without locale for quite a few days/weeks [06:55] poolie: argh, sorry about the rc/beta misunderstanding :-( [06:55] * vila checks mail [06:56] vila: thanks [06:56] it's ok [06:56] vila, what was the source of the confusion? [06:57] hmm, I think I fired qlog to search for examples of updates for version_info and could only found rc examples of course [06:58] you certainly mentioned 'beta' but it didn't print hard enough in my brain to override at that point :-/ [06:59] add to that some stress due to bugs encountered while setting up my 2.0 branch and apport masking me the real cause, etc, => small mistake, big consequences :-/ [07:01] ok [07:01] i thought that might have been it [07:01] the examples in the docs are a bit of a two-edged sword [07:01] without them it would be vague but it's easy to mentally or literally copy & paste them [07:02] while discussing with jam, I still wasn't sure about my mistake as 'cycle.txt' doesn't mention 2.0beta1 but mention 2.0rc1 [07:02] so it's still unclear whether 2.0 is different because it starts the new cycle [07:12] jam, you rejected your merge sort bug? [07:13] poolie: re-reading releasing.txt, memory comes back also: the document is clear about final releases, less so about candidates and says nothing about betas, I'll outline everything I found by mail [07:13] s/bug/mp [07:13] poolie: I saw it too, but I think he wanted to work on a second part instead and I'm pretty sure he send a submission to pqm [07:19] poolie: [07:19] File "/home/robertc/source/baz/pending/working/bzrlib/tests/test_selftest.py", line 2645, in test_run_bzr_user_error_caught [07:19] 'bzr: ERROR: Not a branch: ".*nonexistantpath/".\n') [07:19] AssertionError: pattern "bzr: ERROR: Not a branch: ".*nonexistantpath/". [07:19] " not found in [07:19] """\ [07:19] bzr: ERROR: Attempt to escape test isolation: 'file:///nonexistantpath/' [] [07:19] """ [07:21] :( [07:21] bbl - some errands to run [07:21] jml: this is good [07:21] jml: its a step towards not making 4 directories on every test [07:22] lifeless, I was reacting to a costly mistake that bzr let me make [07:23] make lots and lots of tedious changes, shelve them, merge in latest trunk, forget to commit, unshelve them, realize they're all mixed together, revert, sigh [07:23] jml: oh :( [07:25] jml: did you lose the changes? [07:25] jml: perhaps you can uncommit, or maybe we kept a backup for you? [07:27] backups would end with '~', right? [07:27] ... and the modified files aren't open in my editor. [07:27] mmm, they would have it in the name [07:27] is there a backup of the shelf in .bzr/checkout/** [07:28] jml: we should have kept backups for sure, grep for **/*~* [07:28] em, find . | grep .. or $something like that [07:29] no backup in .bzr/checkout [07:30] the backups look like they are of the wrong changes [07:30] I want what was in the shelf [07:31] please file a bug about this; we may tease it into several bugs [07:31] however, the backups are numbered [07:31] are you looking at the right ones [07:31] there's only ~1~ [07:31] no others. [07:32] ok, two bugs [07:32] revert is meant to back things up [07:32] unless you've set no backups [07:43] poolie: ouch, only 2.0rc1 appears on https://edge.launchpad.net/bzr in the download part, that's not true for https://launchpad.net/bzr though [07:44] i like the pedantry of the tooltip on RDF [07:44] vila, you're saying it should show the last stable release too [07:44] sounds like an lp bug [07:44] yes [07:44] oh, sigh [07:44] will you file it or should i? [07:45] well, had I made a beta I think the problem would have been the same... please do, I'm already filing another:-/ [07:45] oh, which one? [07:46] i'm going to finish soon btw [07:46] for a change [07:46] TooManyConcurrentRequests when pulling from lp in a lp bound branch [07:47] lifeless: bug #309309 was the one I was referring too yesterday in my review [07:47] Launchpad bug 309309 in bzr "selftest can't be run in a bound branch" [Undecided,New] https://launchpad.net/bugs/309309 [07:48] Launchpad is pathetic. Again. "The URI scheme "bzr" is not allowed. Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp" when trying to give it a bzr:// branch. [07:50] someone just filed a bug on that [07:50] it may be a recent regression [07:50] I mean, shit, even Ohloh manages to get that right. [07:51] poolie: (no, I don't think so. I recall trying to register the proper branch URI for my mainline about a year ago and it didn't work. Back then it _also_ crashed my browser when I tried to file a bug about it, which was exceptional. But now it just errors) [07:51] well, sorry [07:51] AfC: I think you're being a little harsh; that code tries to be very paranoid (and thats arguably a mistake), but pathetic is a little strong. [07:52] poolie: {shrug} I'm not about to hold their behaviour against you. [07:52] poolie: but this is yet another feather in the cap of why I think it so important to encourage people to realize they don't need to use Lauchpad to work with Bazaar. [07:54] Yeah, I think that's always been the case. I think there was/is some reluctance to open up unnecessary ports. [07:54] lifeless: perhaps, perhaps not. Given that I've registered an external branch as a project's mainline I don't really see it as necessary that Launchpad advertises "to get this do `bzr branch lp:myproject`. It's like? Huh? That's a mirror, and a 5 hour out of date mirror at that. How about Launchpad advertise `bzr branch bzr://...` like I asked it to. [07:54] lifeless: things like that, again and again [07:54] So my recollection is that refusing bzr:// is not because LP doesn't understand that prefix, but because it knows it can't work. [07:55] lifeless: me registering a release series at a certain well known foreign location and then Launchpad claiming it's where the releases are hosted? That's not cool either. [07:55] AfC: for some folk its great, because they don't want lots of people pulling directly. Maybe there should be a toggle. [07:55] spiv: that's interesting. Bizarre to my eyes, but certainly informative. Of course, if bzr:// doesn't work maybe someone should take it out of bzr and I'd stop using it. [07:56] AfC: it works, its just firewalled @ canonical. [07:56] bzr:// works just fine, in general. [07:56] AfC: is there a bug on this? [07:57] lifeless: classic [07:57] Operationally, the way Launchpad is currently deployed, Launchpad cannot access that port on arbitrary hosts. [07:57] [and you said I was being harsh?] [07:58] It's probably worth revisiting that decision. At the time there were very few TCP-only bzr branches out there, so it wasn't a big deal. [07:58] And, co-incidentally, someone did file a bug about it recently as mentioned above, so probably someone will be revisiting that decision soon. [07:58] lifeless: I can try and file one if you like. Launchpad's javascript doesn't seem to be crashing Epiphany anymore. [07:59] Oh hey, another Epiphany user. [07:59] :) [07:59]