[00:02] hello [00:02] spiv, jam, igc, lifeless, call in a minute [00:07] jelmer: ? [00:08] markh, hi [00:08] hi jelmer - I see you made a change for that crash on osx - is there anything I should do for windows binaries? [00:09] I saw another bug report recently and marked it as a dupe [00:09] but its a dupe of the osx one (which the other windows crash bug is too), and that is marked as fixed [00:09] abentley: bundlebuggy seems to be giving 502 atm [00:10] markh, there were other fixes for Windows by Snaury as well [00:10] jelmer: so if I just rebuild all should be good? [00:10] markh: Yeah, I think so [00:10] that was the perfect answer :) [00:11] do I need to move to 1.5 or anything? [00:11] I would recommend building against 1.5 but for other reasons (several bugfixes that may be relevant, more protocol calls available to svn) [00:12] ok - iirc that will require some tweaks to setup.py as the list of libs has changed. I'll see how I get on... [00:13] (that was the only reason I dropped back to 1.4 in the first place - the existing list of libs was already correct!) [00:14] markh, Snaury tweaked some of that as well afaik [00:23] Soliton: restarted [00:23] spiv: restarted [00:23] abentley: thanks! [00:43] wuu patches. [00:47] abentley: you nearly got spivs origin correct [00:47] lifeless: Hee. [00:59] poolie: does your updated patch address the problem I noticed here: http://paste.ubuntu.com/47029/ ? [01:32] so, ah, again, i renamed some files from bin/ of my repo to scripts/, because bin/ is really a virtualenv and it ends up with all these generated scripts which show up in 'bzr status', i want to just add bin/ to ignores, but i can't get my parent branch to show the change. [01:44] justizin: you need to commit changes to your ignore file. [01:51] jml: i haven't changed the ignore yet, i only moved the files which i want source-controlled, and my 'master' branch doesn't show the rename.. [01:51] even after a bzr update [01:52] also, now i am trying to merge with an svn branch and i get: bzr: ERROR: Revision {('',)} not present in "". [01:52] woo fun :) [01:52] this is a relatively old bzr 1.5 and older bzr-svn, of course.. looking forward to intrepid. [01:53] but it's been working fine for months, just think this is odd.. [01:53] for instance, i bzr mv bin/disable-stuff scripts/disable-stuff [01:53] in the repo on my laptop where i'm working, the change is there, i committed, i pushed, and on the server, i ran bzr update.. [01:53] and i checked everything i could think of. [01:53] both report the same rev # [01:54] but the contents diverge [01:54] Oo [01:58] justizin: so maybe you need to merge one into the other. [01:58] tried merge, says nothing to do.. [01:58] only changes in one branch, atm.. [01:59] so, what are you trying to do? === kiko is now known as kiko-zzz === abentley1 is now known as abentley [02:34] poolie: ping [02:37] jml: i'm trying to see my changes in the parent branch. [02:38] bzr says everything is fine, that the tree is up to date, but i'm saying, dude, it's not. [02:39] justizin: ok. so you have two branches, you've made changes in one and not in the parent branch? [02:39] how did you tell bzr about those changes? (maybe you could paste a log to http://paste.ubuntu.com?) [02:39] that is correct. i commit. i push. i merge. i pull. i checkout. i update. no dice. [02:40] i don't have a log handy, but i did as i normally do. i understand the concepts of push, pull, merge, working trees and when i push over ssh, the working tree isn't updated.. [02:40] oh ok. [02:40] so they report the same rev #, attempts to push or merge say that there is nothing to do, bzr status / diff on my laptop shows no changes uncommitted, and bzr update on the server says also, nothing to do, tree is updated.. [02:41] i guess the next thing to check to be 100% is that a branch off the server has the new changes, though it's tree doesn't.. [02:41] yeah, that's worth checking [02:43] yah a fresh checkout shows the changes.. [02:43] bewildering [02:43] justizin: what does "bzr revision-info" report? [02:43] i'd nuke the server copy, but it's a branch of svn and i'm afraid i'll lose heritage [02:44] 135 justizin@justin-ryans-macbook-pro-15.local-20080915190426-w8st6jjdasmd24ox [02:44] for both [02:44] and that'd be the commit from my laptop. [02:44] So, they are exactly the same branch then. [02:45] yah, but the working tree on the server is broken, which is my public http browsification [02:45] justizin: so you want to update the working tree on the server? [02:47] yah and again i understand when i push over ssh that doesn't happen, so i'm on the server and bzr update says the tree is up-to-date, though it's inconsistent with other branches, even the fresh one i just created *from* the branch with the broken wt [02:47] justizin: perhaps you want to be using one of these plugins? or [02:47] spiv: possibly, but again, i'm fine with manually updating the tree for now, it just refuses to update.. [02:47] justizin: does 'bzr info' in the tree on the server report the branch URL you expect? [02:48] well it's a branch from an svn repo [02:48] And what does "bzr status" say? [02:48] one sec.. [02:48] (info does report as expected btw) [02:49] well as of now it has pending merges from svn, which is a new problem, but the issue i'm talking about with the working tree was pre-existing.. [02:49] So the working tree has uncommitted changes? [02:49] and, fwiw, i am now getting: bzr: ERROR: Revision {('',)} not present in "". [02:50] well, it does as of about 20 min ago [02:50] the working tree problem is maybe 8-12 hours ol [02:50] old [02:50] Uncommitted changes would explain why the working tree's contents don't match the last revision in the branch. [02:50] it doesn't even have uncommitted changes, it's odd.. i reverted the files from the merge earlier and it just says pending merges with no other change info.. [02:50] no, they can't, because time only moves forwards - check wikipedia. ;) [02:50] the working tree problem is pre-existing [02:51] now of course it's all flubbed up and i take responsibility for that [02:51] The revision not present error sounds like a bzr-svn bug. [02:51] possibly, i don't have the latest bzr-svn b/c i'm using ubuntu hardy heron packages.. [02:51] i think i'll just end up creating a new bzr repo and futzing the svn merges on this.. [02:51] So I don't understand your problem. If "bzr update" says the branch is up to date, and "bzr status" says no files are changed in the tree, then there are no changes. [02:52] yeah, but i am a human and my brain says the files are laid out differently in a fresh branch from here.. [02:52] Is "bzr status" in the fresh branch clean? [02:52] i moved files from bin/ to scripts/ in my repo, and they are moved on my laptop where i moved them, and they are moved in a fresh branch from the server to a temp location.. [02:53] the fresh branch was created during this conversation.. [02:53] as a means of verifying that the bzr repo had the changes, but the working tree on the server, itself, was broken.. [02:53] Sure, we're at the point where there's a wrong assumption somewhere, I think, so you'll have to pardon the dumb questions :) [02:53] no it's ok [02:54] i'm just frustrated and of course i explained some of this to other people over the course of the day [02:54] (Hopefully I don't need to question http://en.wikipedia.org/wiki/Arrow_of_time ;) [02:54] and now i hosed the repo for bzr *and* svn so it's all gone to hell and confusing ;d [02:54] i realized while i was explaining the problem from earlier today that i came back in here for the new missing revision problem, in the same bzr branch / repo. [02:55] it's ok, i'm learning. noone's life support fails if this branch dies, and none of my customers will fire me. :) [02:55] and if i wasn't using outdated code, i'd be helping to test bzr and bzr-svn :-P [02:55] i noticed that bzr can be installed via setuptools now, btw - super rad. [02:55] thinking of taking advantage of that for our plone deployment. [02:56] so i can distribute a tarball of a buildout that installs bzr and pulls dev code. [02:56] maybe.. [03:00] So I don't have any idea where your problem is. If you have two up-to-date working trees at the same revision, and no uncommitted changes (i.e. a clean 'bzr st'), then I don't see any way for them to have different contents in their versioned files. [03:00] jml, pong [03:05] poolie: so, with your patch applied to bzr.dev, I can branch stacked branches into shared repos, but not standalone. [03:05] poolie: I get the same error that I pasted yesterday. [03:05] http://paste.ubuntu.com/47029/ [03:06] ok [03:06] that's good to know [03:06] in a way [03:06] you also said you had conflicts? [03:06] poolie: yeah, in remote.py and test_remote.py [03:07] jml: how recent is your bzr.dev? (It's probably unlikely, but I'm wondering if revno 3709 might help?) [03:07] spiv: 3709 [03:07] the clash is with the changes in r3695 [03:09] poolie: so, should I file a separate, critical bug for the AttributeError problem? [03:11] that'd be good, and assign it to me [03:15] http://dev.mysql.com/tech-resources/articles/advanced-bazaar.html [03:15] w00t [03:17] hello beuno [03:18] hey poolie [03:18] how are you? [03:20] poolie: https://bugs.edge.launchpad.net/bzr/+bug/270738 [03:20] Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] [03:37] there are a shorter form of 'mkdir bzr; cd bzr; bzr init-repo .' ? [03:38] mlh: "bzr init-repo bzr ; cd bzr" [03:38] I see that sequence mentioned in more than one place and wonder whether just 'bzr init-repo bzr ; cd bzr' might be better [03:39] yer [03:39] I just read Bueno's link above, and also the bzr hacking guide and they both have that triple in preference [03:40] whereas the double I think is more intuitiev and reliable [03:41] I prefer the double too. [03:42] A bzr newbie might look askance at the amount of typing required just to start a repo [03:42] perhaps bzr init-repo somedir used not to work in some older version of bzr? [03:46] jml: poolie will be a minute [03:46] mt,ignore me [03:46] * jml ignores. === bob2_ is now known as bob2 [04:20] poolie: Want to talk about Launchpad bzr teams? [04:39] jam: ? [04:45] abentley, hi, just saw your mail about them [04:45] and also about process - i was hoping someone else might reply [04:47] poolie: Oh well. [04:47] ? [04:48] so that was a yes, i'm happy to talk about them [04:49] Okay, what do you think about the plan I outlined? [04:51] i thought there might be other teams that need to be cleared up [04:51] um [04:51] presumably after the last step you're wanting to leave ~bazaar-overall yourself and rejoin ~bzr? [04:52] Right. [04:52] bazaar-overall is already a member of Loom-developers and the RSS thing. [04:52] reassigning people is probably a pita but perhaps a rubber duck will do it [04:52] rubber duck? [04:53] a launchpad admin [04:53] no duckie will do this [04:54] personally, I'd leave ~bzr where it is and just change owners on the projects that shouldn't be owned by ~bzr [04:54] there is also a ~bzr-developers, do you know how that's supposed to fit in? [04:54] poolie: My original idea was to create a *new* team to be the just-the-bazaar-codebase team. But then you wanted to make bzr mean that. [04:54] so that would not require people to move around, which might be less traumatic [04:55] lifeless points out we don't necessarily need to move people [04:55] they can join ~bazaar-overall if they want to [04:55] bzr-developers was my original "just-bzr" team. [04:56] poolie: I think it would be surprising for members of ~bzr to suddenly stop getting updates about all the various plugins and stuff. [04:57] poolie: i.e. I don't think that moving people to bzr-overall is optional or opt-in. It would be disruptive not to move them, if we follow that plan. [04:59] abentley: I think its more disruptive to have to move and rename all the branches etc [05:00] well, let me put my 2c in. I want you to get what you want here [05:00] lifeless: Why would we have to move and rename branches? [05:01] personally, I will want to end up getting the notifications I get; and I don't want to have to update push urls en-masse (though I'm happy to do so in an adhoc basis subsequent to teams and owners being sorted) [05:01] abentley: there are a bunch of ~bzr owned branches for various plugins [05:01] abentley: if 'bzr' is renamed, their urls will change [05:02] lifeless: I didn't think any of our plans involved renaming 'bzr'. [05:02] beyond that, I'm happy with anything [05:02] abentley: the bzr team I mean [05:02] '~bzr' in lp namespace terms [05:03] lifeless: Still, I don't think any of our plans involved renaming ~bzr. [05:03] ok [05:03] But we might well end up changing ownership of a bunch of plugin branches. [05:04] So they would go from ~bzr to ~bazaar-overall or something. [05:05] hey guys [05:05] jml: moo [05:06] poolie: So do you have an idea how you want to proceed? [05:06] is this a new bug or an old one: 'bzr info -v http://mumak.net/code/stacked' raises an error and 'bzr info -v nosmart+http://mumak.net/code/stacked' does not [05:07] abentley, it does seem like making ~bzr-developers own bzr is a smaller change [05:07] and then ~bzr will be a member of that [05:07] then you can change your membership but other people won't be affected [05:07] the server is using 1.6.1 from the ppa and I'm using bzr.dev with poolie's patch applied. [05:07] possibly we should rename ~bzr-developers to ~bzr-core-dev or something [05:07] poolie: Sure, whatever you like. [05:08] jml: I don't know whether it's a regression. [05:08] can you see any problems with that? [05:09] poolie: I think the original reason you didn't want to do that was because the PPA locations would change, or something likethat. [05:10] so we can't really rename ~bzr or stop using it for the ppa without causing that disruption [05:10] in retrospect teams for ppas should be dedicated only to that purpose [05:10] but i think if we do just this it should be ok [05:10] so should i do this now? [05:10] poolie: That would be great. [05:13] jml: My bzr.dev is prolly out of date, but info -v does not raise an error on that URL. [05:13] jelmer: still here? [05:15] jml: I am on revno 3698. [05:16] abentley: 3709 personally [05:16] abentley: interesting, my bzr.dev is 3702 and does traceback [05:17] tracebacks after bzr revert -r 3698 too, though [05:18] pycurl? [05:18] i don't have pycurl installed [05:20] jml: False data. I had mistyped the URL slightly. [05:20] lifeless: how can I force urllib? [05:21] jml: http+urllib [05:21] http+urliib ? [05:23] * jml gets the same with urllib [05:23] * abentley reminds the crowd that his original statement was wrong; it does traceback for him now. [05:24] abentley: I hear you :) [05:24] My best guess is that the repository isn't getting stacked. [05:26] jml: Do other operations on that URL work? [05:33] * abentley is off to bed. [05:33] * jml tries some [05:34] branch works [05:34] info doesn't. [05:34] BzrDir.clone probably doesn't [05:37] spiv: have reviewed for you, wasn't happy enough to approve, wasn't unhappy enough to resubmit [05:39] spiv: so I just commented [05:40] mwhudson_: welcome back [05:40] * mwhudson_ grrs [05:40] networkmanager appears to have gone on holiday on my macbook [05:49] abentley, ok, bazaar-overall should no longer be necessary [05:49] biab === mwhudson__ is now known as mwhudson === Snaury is now known as Snaury[away] [06:36] lifeless: that's great, thanks! I've replied; any thoughts on a better name/location than test_effort? [07:01] Goood.. hello guys [07:08] which platforms or distribution methods get the full html versions of the docs? [07:25] spiv: well, I'd have put it in test_remote I think [07:26] spiv: as I expect there will be a number of similar tests and they are all remote-centric AIUI [07:26] markh: dunno ? :P [07:26] markh: docs.bazaar-vcs.org :P [07:27] they are a nice source of pre-generated xhtml versions of each of the help topics I'm trying to work out if I can leverage :) [07:28] generating html at runtime from the 'rst-like' help text in bzrlib doesn't sound like fun [07:29] lifeless: I expect there will be too, which is why I don't want them in test_remote. [07:30] spiv: I don't understand [07:30] I think I'm hearing 'because these things are related to remote tests and will be similar to each other I don't want them with other remote tests' [07:31] I don't mind them being "with" other remote tests, I just don't want them in the existing test_remote module. [07:32] so I'd rather have the new tests in test_remote_SOMETHING, or make a bzrlib/tests/remote/ directory with test_marshalling and test_effort in it, or a solution like that. [07:33] Because test_remote is already quite large, and I don't like test modules with a vague purpose like "test everything related to bzrlib/remote.py". [07:33] Does that make sense? [07:35] I'd prefer you made remote tests into a package than a concept-related test module, because all our other tests are module/class/method related, not concept. [07:35] Basically, I see these tests as being in a related but definitely distinct category to the tests in test_remote [07:36] wow my arms are still itchy as hell from the allergy test [07:37] A package is fine with me, and it sounds like it's ok with you? If so, I'll do that. [07:38] hang a sec [07:38] mailing [07:38] Ok. [07:42] ok, mailed [07:42] writing a paragraph helps me think sometimes [07:43] anyhow, bzrlib.tests.per_branch.test_push is where I think it belongs [07:43] Really? Interesting. [07:43] the mail should be there now, read it and lets chat more if it doesn't make sense [07:47] I was thinking that a per_branch test would be low bang-for-buck, and also significantly more complex, because the RPC count for push could legitimately be different for different formats. [07:47] fork() [07:47] (especially while we still fallback to VFS for various things) [07:48] on the one hand, I think this is too low level anyhow, it really demands to be cmd_push that is tested [07:48] (Currently that patch has a test for both cmd_push and for branch_object.push) [07:49] on the other branch, I would set an upper ratchet on a per-branch types, if they are different [07:49] uhm anyhow [07:49] My key concern is SUT<->TestCode connections [07:52] Yes, that's very important. [07:52] I don't think grouping tests by the fact they test overall effort is useful [07:53] (We don't test all the e.g. constructor method tests together) [07:53] No, me either. [07:53] so cmd_push's test should definitely be in blackbox/tests/test_push.py IMO [07:53] (Even though it was the way I was leaning initially) [07:53] the branch.push test I would be happy with either a per_branch, or a specific format test [07:54] doing per_branch would mean that new formats get coverage by default [07:54] See, that's strange to me. It seems to me that the cmd_push test is as appropriate as a per_branch test as the other one. [07:54] Well, nearly. [07:55] it is nearly [07:56] the problem is the tension between the cmd_push code, and the code it calls [07:56] Having coverage for new formats is a very good point. That probably does make a per_branch test worthwhile. [07:58] hi, i've just installed bzr. and every command i enter in the console outputs a warning "bzr-svn is not up to date with installed bzr version 1.7rc1. There should be a newer version of bzr-svn available." what do i do [07:58] imyojimbo: have you installed a daily snapshot or something ? [07:59] no [07:59] the latest build for Windows [07:59] ah [08:00] markh: ^ [08:00] lifeless: btw, I see no difference in behaviour in pushing unreconstructable tags with bzr.dev vs. faster-empty-push [08:00] spiv: I know, I was saying that the tags support <-> repository layering etc needs an overhaul [08:00] and it will change the shape of the tuning you are doing [08:02] I'm not sure what you're telling me. Are you saying that my change is incorrect, or just that it's likely that someone else will touch this code at sometime soon? [08:02] uhm [08:02] I think the current code is faulty [08:02] and that your change may make it more faulty [08:03] Ah. As far as I can tell it's bug-for-bug compatible :) [08:03] further, that we may need to probe for revisions routinely when we fix the tag behaviour, to correct previous misbehaviour. [08:04] the tag stuff doesn't need to block us. Oh, but I have a small metacomment [08:04] ?? [08:05] imyojimbo: I don't know anything about the windows builds; markh is the dev making them, he can answer your question [08:06] spiv: the metacomment is that 'no-op push' is not the common case. The common case is arguably 'changed tip with tags in branch', so changes that only help special cases but are less clear/useful for plugins etc are not auto-approve from me [08:06] ok, thanks [08:07] spiv: w.r.t. tags, I'd like to this change not assume that no-tags implies no-change-to-remote-tags [08:07] spiv: so either delegate to a helper method subclasses can replace, or something along those lines [08:10] Pushing 0 revisions is not *the* common case, but it's not an uncommon one either. A push of a branch with no tags is also fairly common I think (certainly all my bzr work falls in that category atm). [08:11] I definitely wouldn't assume that anything is an auto-approve from you unless it's crystal clear that's improvement in every respect :) [08:12] spiv: sure, I'm not saying 'do not optimise' I'm saying 'for the common case I give clarity/extensibility a lower weighting' [08:12] Ah, I see. Sure. [08:13] In short: I'm glad you reviewed this :) [08:15] ops. i did install the release candidate 1. and not the stable version 1.6.1 should i just unistall and reinstall the stable version? [08:15] *1.7 [08:16] imyojimbo: yes, installing 1.6.1 again would probably fix the error [08:17] should i uninstall the current version, or just overide it with the new install [08:24] hi. I need to revert the last commit done on a branch, what's the proper way to do that? with "revert" or "merge"? [08:24] lifeless: http://rafb.net/p/1Edrnu30.html <-- change to allow subclasses to vary when tags are pushed by _basic_push [08:25] mdke: 'bzr uncommit' usually [08:26] spiv: that worked. Wow that's simple :) [08:26] mdke: if you don't want to permanently remove that commit from the branch's history, then 'bzr revert -r 2 && bzr commit' [08:27] :) [08:27] (Oops, "bzr revert -r -2" is what I meant in that example, not that you care...) [08:27] spiv: if I'm working on a bound branch, does "bzr uncommit" fix the serverside branch too? [08:28] Yes. [08:28] supercool [08:28] thanks very much [08:28] You can check for yourself with 'bzr log -r -1 URL' :) [08:28] ok [08:28] spiv: that looks ok to me [08:28] and the last question. [08:28] lifeless: thanks [08:29] users doing "bzr update" from the server branch will automatically get the uncommit too? === vk5foss is now known as kgoetz [08:30] mdke: yep [08:30] (it'll "update" to whatever the current revision is) [08:31] great [08:31] thanks again [08:49] ok, I'm out :) [09:28] hello...if i do a bzr merge ../bundle.patch the original author is not preserved.. pull did not work, it told me to merge...merge applies cleanly (using cherry-pick). How can i preserve the original author? i'm using bzr 1.6.1 [09:28] is it possible at all? [09:40] akuehntopf: it should be preserved [09:41] akuehntopf: (as commits underneath your merge commit) [09:42] unfortunately not, does it have something to do with "merge" doing cherry-pick? [09:43] because i couldn't use pull [09:43] you commited, and 'bzr log' didn't show the commits indented below the merge? [09:45] it showed them, but using my id as the commited [09:45] committer [09:45] i'm sure i did something wrong, i'm not that familliar with bzr yet [09:45] so my steps were as follows: [09:46] bzr branch main feature [09:46] cd feature [09:46] bzr merge ../bundle.patch [09:46] bzr commit [09:46] cd ../main [09:46] bzr merge ../feature [09:46] that's how merge works [09:46] it creates a new commit, with your user id [09:46] ok [09:46] and pull? [09:46] would pull have preserved it? [09:50] akuehntopf: install bzr-gtk and then try the visualize command with `bzr viz`. You'll get a much better idea of what's going on. [09:52] oh hi AfC , long time no see ;-) [09:52] i guess i'll try it using a simple demo repository [09:52] pull would have just prepended them to the current revisions, yes [09:53] alright [10:02] spiv, are you still around perchance? [10:43] jelmer: do you have ideas why bzr-svn does not save passwords it's asking for? [10:47] are location now implemented for anything other launchpad. the only thing i could find was a brain dump from 2005. otherwise what is the current status? [10:47] sorry for the missing words in these sentences :( [10:51] jrb_, what kind of location? === siretart_ is now known as siretart [11:41] * gour is wondering how people auto-generate changelog with bzr [11:47] gour: there's a gnulog plugin to output a GNU-style changelog [11:47] james_w: ohh, thanks [11:54] has anyone else had trouble with the 1.6.1 installer? [11:54] for Mac OS X [12:14] Snaury[away]: It doesn't do any password caching because that's up to bzr and svn [12:15] Hmm. But somehow it doesn't. :-/ [12:15] jelmer^^ [12:40] Just a quick check: if I want to use a smart server over http, I'd have to something like this... right? [12:40] bzr revno bzr+http://jakob@www.astro.rug.nl/~jakobb/bzr_repos/repos1 [12:42] grutte_pier: new-ish bzr probes for the smart server by default [12:43] mwhudson: allright.... but that doesn't make any difference for the traceback I get :P Just to make sure that I'm not filing a bug whilst using the wrong syntax :P [12:43] heh [12:44] poolie: the common prefix (or at least the server) of the branches on my own server [13:08] poolie: bzr checkout mine://foo [13:34] jelmer: is the performance issue we recently discussed fixed in bzr-svn 0.4.12? at least bzr-svn 0.4.11 had the problem [13:35] uws, yes, that's fixed in 0.4.12 [13:35] jelmer: Ok, thanks. upgrading [13:36] 0.5 will be even more significantly faster [13:37] latest in a series of daft questions... .bzrignore, should it be added to source control? [13:39] jelmer: how? [13:39] VSpike: if you use 'bzr ignore' instead of touching .bzrignore itself it will add it to version control it self [13:39] VSpike: Yes. [13:39] VSpike: if you made it yourself, then yes [13:39] uws, fewer roundtrips and cache database queries [13:41] jelmer: and what is the ETA for 0.5? :) [13:41] thx [13:41] LarstiQ, "when I find the time" :-P [13:42] jelmer: ok, so what are the blockers? :P [13:42] basically, more tests - in particular tests for upgrading between different versions of the mappings [13:42] jelmer, uws: btw, 4 oktober there is a Python community day at the NLLGG national gettogether in Utrecht [13:42] LarstiQ, ah, thanks [13:43] (and 27 november a PUN meeting in Rotterdam) [13:43] which, coincidentally, I still need speakers for ;) [13:43] hmm [13:44] what sort of timeslots do the PUNs have, ~30 min? [13:45] jelmer: 30 minutes and 5 minutes lightning talks [13:45] PUN? [13:45] uws: Python Usersgroup Nederland [13:46] uws: http://wiki.python.org/moin/PUN/ [13:46] I'd never heard of these... what kind of topics are usually covered during PUNs? [13:48] grutte_pier: anything goes [13:48] grutte_pier: http://wiki.python.org/moin/BvB28Aug has some of last time [13:48] grutte_pier: also, http://vanrees.org/weblog/archive/2008/09/12/python-calculated-coin [13:48]