[00:06] Done, https://bugs.launchpad.net/bzr/+bug/587692 [00:06] Launchpad bug 587692 in Bazaar "Sometimes "bzr version-info" doesn't complete (affected: 1, heat: 0)" [Undecided,New] [00:49] morning all === igc1 is now known as igc [00:51] hi all, igc [01:03] Good morning. [01:20] hi there spiv [01:22] what fabulous adventures will you have today? [01:26] Finishing the patch(es) for allowing bzr-builder to merge just debian/ dirs from parallel imports, I hope! [01:27] nice [02:51] back [03:13] hi there lifeless [03:19] hiya [03:21] hi [03:21] re high bugs [03:22] if you want to strike while the iron's hot and fix it, feel free [03:22] but it's not as critical as some others [03:23] poolie: hi [03:23] poolie: was just talking to lifeless on #nzpug re. finding a good hotel in brisbane [03:23] poolie: he thought you might have some suggestions :) [03:23] poolie: I really feel that if we allow things to slip, they stay slipped; the broken windows theory of code maintenance [03:24] poolie: in particular I was expecting/hoping parthm would pick it up with the priority I'd set it, as he's slowly getting deeper and deeper in. [03:24] duffyd: also wikitravel if you haven't looked there already ? [03:24] lifeless: oh ta [03:26] re broken windows, i sympathize but the important thing is to fix them, making all bugs high won't help [03:26] thats true [03:27] I feel that regressions should be equal to the highest priority open bug, in essence [03:27] I know you don't feel that way, and I don't understand why, yet. [03:30] lifeless, if "regression" means "used to work, now doesn't" [03:31] then, i agree it's an interesting thing to track [03:31] i don't think it jumps to the top of the queue [03:31] if somebody picks up a copy of bzr today and hits say 5 bugs [03:31] the fact that one of them was once working and the other was not is not super important [03:32] in a sense if you have too many of them, then it seems that your quality process is not very controlled [03:32] thats true too [03:32] either you're lacking tests or people are careless [03:33] Doing them first, always, should either be a small time fraction (and ok) or a burden and thus make it clear you have a problem earlier in the process [03:33] I think its these two things that keep me coming back to this and not accepting the 'at any point in time, what is the most useful improvement to work on' argument [03:33] I think thats a great argument when choosing new stuff to make good [03:34] but not for choosing how to deal with things that we've permitted to slip [through whatever reason] [03:34] i think saying 'we will throttle the amount of new work by not starting any while there are regressions open' would be ok [03:36] I expect that to add more latency to addressing regressions than I'd like us to achieve. [04:24] anyone got python2.4 handy ? [04:26] I seem to still have it installed. [04:29] can you do from email import Message ? [04:30] Yep. [04:30] cool, thanks [04:41] hi guys. [04:42] I want to use cherrypicking, but I hope it can merge with history information. How can I do? [04:42] sorry, we don't do that at the moment [04:43] Why not? [04:43] sorry, what's you question precisely? [04:44] I think it is a valuable function. [04:44] i agree [04:44] Is there any plans to implement it? [04:44] at the moment bzr doesn't track history for cherrypicks [04:44] we'd like to implement it [04:44] there is a bug you can subscribe to [04:46] Poolie, thank you. [04:50] poolie: so you suggested tagging regressions; did I miss ail about that ? [04:50] i didn't send mail about it yet [04:50] kk [04:50] you can [04:50] ok [04:51] i think the issue of where they should be prioritized is interesting but also one i don't want to spend much time on atm [04:51] weapons free to fix them on demand [04:51] :P [04:51] by which i mean, as they come up [04:52] I'm interested in that, but not in chasing it if noone else is; so I won't ask you to spend much time on the priority discussion, but I will kick one off on the list, unless thats a concern for you [04:56] poolie: you expressed concerns about dirstate2's complexity [04:56] poolie: can you be a little more detailed ? [04:56] i did- [04:56] not right now but i do want to go back and reply in that thread [04:56] ok [04:56] i'm not totally trolling in asking [04:57] why fix this now rather than fixing regressions? [04:57] most of the bugs in dirstate have been there since it was first done [04:57] its my fault its like this [04:57] ok, thats a shallow answer [04:57] uhm [04:57] no, it's a reasonable answer [04:58] on regressions, I have a complex of feelings there [04:58] tied into the cost of accepting contributions I guess [05:00] it's complex for me too [05:00] for me at least marking them is a start [05:01] dirstate2 has a few interesting things [05:02] - if its not ready when we do 3, we don't get it for X more years [05:02] (per Mark and changing formats) [05:02] - it affects a great number of users in varying ways, and is, I think, causing bzr explorer and tortoise-bzr users particular pain on windows [05:03] - I really want emacs folk to be happy [05:04] i'd really like to see it fixed too [05:04] i was using gannotate the other day and it bit me [05:05] if we can finish it soon for 2.2 that would be good [05:05] i guess i'm mostly concerned about being able to deal with the fallout [05:05] - getting proper review for it, not rubberstamps [05:05] oh, and one more thing - its in-stock inventory at the moment [05:05] - and whether it takes too much attention away from udd and other kinds of bugs [05:05] something I abhor [05:10] mm [05:10] i don't want the fix for it to stuff more things into the pipeline than will fit, or to cause it to be overloaded as we deal with fallout [05:10] otherwise, i agree [05:10] agreed [05:10] Note that dirstate2 is a very specific thing [05:10] its not a new dirstate serialiser, for instance [05:11] John would like to see more work done on what-is-stored-where, and so would I, but I think that that sort of thing is very high risk. [05:11] OTOH doing that might make the overall design simpler. So we should talk next Monday briefly about that. [05:15] So, mgiuca is trying to sign the contributor agreement, but the link on http://www.canonical.com/contributors is broken. [05:15] ugh [05:16] oops [05:16] well, it's a very attractive 404 [05:16] though not really the attitude you'd expect mark to take :) [05:16] I'll file a bug [05:17] k [05:17] https://bugs.edge.launchpad.net/ubuntu-website-content/+filebug [05:17] yes [05:19] The latest copy I have is of 2.4, but 2.5 appears to be the real latest. Is there another copy of that floating around somewhere? [05:19] http://www.canonical.com/files/Canonical%20Contributor%20Agreement,%20ver%202.5.pdf gives a 403 [05:19] i have 2.5 here [05:19] bug 587755 [05:19] Launchpad bug 587755 in ubuntu-website-content "Contributor Agreement PDF link on http://www.canonical.com/contributors is broken (affected: 1, heat: 0)" [Undecided,New] https://launchpad.net/bugs/587755 [05:20] wgrant, http://sourcefrog.net/tmp/1y/Canonical%20Contributor%20Agreement,%20ver%202.5.pdf [05:21] poolie: Pointed him to it. Thanks. [05:38] so I run bzr branch lp:dcplusplus, download the patch posted at http://launchpadlibrarian.net/49406269/plugins.patch , and when I run "bzr patch plugins.patch" I get "bzr: ERROR: Error invoking patch: Invalid argument" [05:38] this is with bzr 2.1.1; why might this be happening? [05:39] frion, hm, there's no other details about which argument was invalid? [05:39] maybe something in ~/.bzr.log? [05:39] the only Google result for anything similar is http://www.mail-archive.com/leo-editor@googlegroups.com/msg06411.html and that sort of gives up on the actual cause (it suggests using an external patch tool) [05:40] oh, didn't check, but no, not displayed, regardless of being in verbose mode or no [05:40] is this on linux? [05:40] Windows [05:41] hello. i noticed that the imports in bzrlib.status and bzrlib.ignores are not lazy. is this intentional or just that no one has gotten around to doing it? i benchmarked (time) 'bzr st' with/without lazy and performance seems the same. [05:41] Looking for .bzr.log actually, now. [05:42] frion: bzr --version should tell you [05:43] spiv: ah, yup [05:43] frion: or just repeat the command with -Derror to force it to show the full traceback, i.e. "bzr -Derror patch plugins.patch" [05:43] got the traceback already in the log [05:44] http://pastebin.com/4NMfXjLF [05:45] Still no obvious information on which argument is invalid, as far as I can tell [05:47] frion is this on linux? [05:47] sorry, [05:47] just saw your message [05:47] parthm, not sure off hand [05:48] if there's no comment explaining why they have to be non-lazy then there's probably no good reason [05:48] try adding stuff to test_import_tarrif [05:49] frion: it seems that trying to start a 'patch' subprocess is failing, perhaps simply because you don't have an executable called 'patch' on your PATH? [05:49] poolie: thanks. will look at it. if there are no problems i will make it lazy as i am doing some imports. [05:50] parthm, poolie: or perhaps because there's no observed benefit to making them lazy? [05:50] right [05:50] ah, that's not internal to the standalone release? the first "patch" in the path seems to be in the strawberry Perl directory, though I don't know if that's a sufficient GNU patch [05:50] parthm, also, perhaps some can just be removed altogether [05:50] which is better [05:51] mwhudson's branch of pyflakes can spot unused imports (even when lazy_imports are used) [05:51] poolie: will check that too. [05:51] ah that's also the only "patch" in the path [05:52] (FWIW, pyflakes doesn't warn about any unused imports for status.py or ignores.py for me) [05:54] I'm a little surprised that bzrtool's patch command calls out to an external patch tool, I would have thought bzrlib has most of that functionality builtin already. [05:54] and without that in the path, it fails with some 'can't invoke patch' message, so obviously it's trying and failing and for whatever reason Perl's patch.exe isn't sufficient [05:54] it does seem to be buildable from bzr's core functionality [05:57] lifeless, reading your diff now [05:57] for dirstate2 [05:59] poolie: thanks [05:59] I'm about to cook dinner [05:59] then I'll be back for a bit [06:04] For a test case I need to put junk into $BZR_HOME/ignore. This seems to fail http://pastebin.com/V2VC2cBk [06:05] Am I doing something wrong? [06:05] i don't think so, but perhaps this is not a testcaseintempdir and needs to be? [06:06] poolie: This is TestCaseWithTransport. I checked the hierarchy, it derives from TestCaseInTempDir [06:07] sorry i don't know then [06:07] ah, maybe the code that creates ~/.bazaar has not run? [06:08] parthm: where are you doing this? [06:08] spiv: bzrlib.tests.blackbox.test_status.TestStatus [06:09] parthm: I mean, at what point in the test? In a test method, or overriding setUp, or? [06:09] spiv: oh. Its a test method. [06:09] I want to add junk into .bazaar/ignore and then run_bzr [06:10] Ok, so that seems reasonable. So I guess there's no .bazaar set up for soem reason, did something change there recently? [06:11] Hmm, I'm probably getting confused with the whoami change. [06:11] spiv: looking at tests/__init__.py there does seem to be code but it doesn't seem to be working. http://pastebin.com/RxVxpJz1 [06:12] spiv: whoami change touch EMAIL env variable and nothing else so I don't think it should matter. [06:13] parthm: I think perhaps you have a wrong assumption about when .bazaar/ignores is created [06:13] parthm: look at get_user_ignores() [06:13] parthm: it has the code that does the "try open that file, if it doesn't exist create it" [06:14] spiv: I am opening it in write more but the creation is failing ... http://pastebin.com/V2VC2cBk ... so looks like some dir is missing in the hierarchy [06:14] parthm: "in the write more"? [06:15] spiv: sorry. I meant, write mode for the test case. I don't care about existing content. Just want to add 1 junk entry. [06:15] parthm: use the APIs in bzrlib.ignores, don't write the file directly [06:16] parthm: compare how test_ignore works [06:16] spiv: good idea. will try that. [06:16] Note that it calls get_user_ignores, or _set_user_ignores [06:16] spiv: ok. [06:16] And _set_user_ignores explicitly does "ensure_config_dir_exists" [06:18] Or perhaps add_unique_user_ignores would be more appropriate in your case. [06:18] Anyway, you're running into trouble because you're bypassing the APIs in bzrlib.ignores which take care of this stuff for you :) [06:20] spiv: yes. that was it. add_unique_user_ignores takes care of it. thanks :) [07:09] lifeless, ok, dirstate2 comments [07:09] .. sent [07:09] thanks [07:09] it's not inherently scary :) [07:09] there are both some substantial comments and some on the description [07:09] hi everyone... I'm looking for someone that is well versed in the bzr-svn plugin for some help with bug hunting :) [07:09] oh i meant to say thanks so: 'thanks' [07:10] lest all the criticism seem too much [07:12] zpp, jelmer's the expert; he'll probably be on in a bit [07:12] you can just ask though [07:14] poolie: I appreciate the thorough examination [07:15] i appreciate the code and documentation, and the openness to feedback [07:15] poolie: some bits I do disagree with (I don't want hashes in the dir with working tree config files etc, experience tells us folk facing too-many-files apply big hammers [07:16] figuring out what makes things correct given fs nastiness is really the key bit, I think [07:16] i think so too [07:16] i had a go at listing adequately pessimistic assumptions [07:16] I've starred your post for next pass at the code [07:16] i probably should have added that you can barely count on ordering in the normal case [07:17] by which I mean, i won't reply till then [07:17] even without crashes network clients may be incoherent [07:17] np [07:17] but I have read it [07:17] i may have a go at removing write-during-read [07:17] yes [07:17] it may suck [07:17] OTOH bad-network-protocols are bad [07:17] mm [07:17] the problem [07:18] there's another alternative which is to just say "sorry, no" [07:18] with write-during-read is that we aim to have our operations take < 3 seconds [07:18] and keep relying on OS locks for writing [07:18] that would still not work on NFS, for instance. [07:18] sorry i don't follow you [07:18] I will note that the pack repo format, which I built using an earlier version of the same algorithm has been pretty darn reliable [07:19] sorry, changed horses [07:40] poolie: sorry... just got back :)... thanks for that [07:42] Im attempting to create a remote branch with a bound local repo & checkout and keep getting this error when I push data to the remote branch: ErrorFromSmartServer: Error received from smart server: ('error', 'Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps') [07:43] hi all [07:44] ok [07:44] EOD [07:44] poolie: ^ [07:45] hi there vila, cheerio lifeless [07:49] zpp: ooh, interesting [07:50] zpp: I guess that's probably https://bugs.edge.launchpad.net/bzr/+bug/485601 [07:50] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 12)" [Medium,Incomplete] [07:51] zpp: that bug seems to be stalled on a way for bzr devs to reproduce it, though [07:51] zpp: I don't suppose your repositories are public? :) [07:52] It's interesting that bzr-svn always seems to be involved. [08:00] Hi... [08:00] Is it possible to give access to bzr without creating a user account at the system? === radoe_ is now known as radoe [08:07] mohitranka, over ssh? [08:08] Poolie, yes [08:11] see http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html#authentication [08:18] spiv: yep I think so too... it's causing us a lot of issues so i'm hunting it now :) [08:18] spiv: I actually believe it might be a race condition somehow... [08:33] spiv: if you see jelmer before i do... can you let him know i'm hanging around? [08:33] i have a fun way of reproducing the issue now it seems [08:37] zpp: great! [08:37] night all [08:37] spiv: unfortunately it's all closed source stuff so i can't gie direct access to the repo [08:37] spiv: but it looks like under some conditions multiple svn checkins get identical bzr rev numbers... [08:38] zpp: Hmm! [08:38] spiv: and these checkins then appear in svn...but the files never appear (or the log entry) in a bzr clone of the svn repo [08:38] zpp: anyway, please post about it on the bug report. That will make sure interested people see it, and will help pool knowledge about what's going on [08:38] spiv: yep... definitely will do :) [09:04] hi all [09:04] bonjour vila [09:05] hi poolie [09:05] bialix: privet Sacha :) [09:05] privet :-) [09:05] jelmer: are you around atm? [09:06] vila, at uds you asking me and Gary about adding new feature to qbzr [09:06] vila: about checking branches and their relations with their parents/submit branches [09:06] bialix: yeeeees.... [09:06] and ? [09:06] vila: can you file a bug report please so we don't forget it? [09:07] I won't forget it (in fact I badly needed it again when my HD died), [09:08] but the last discussions left me with the idea that I could start with command-line plugin [09:09] if only to explore a bit what is needed there and provide low-level stuff for qbzr [09:09] or any other GUI :-P [09:10] zpp: hi [09:10] bialix: I think I saw you continuing on your idea about branches in the same repo and being able to add/remove them interactively to qlog, which is also very good and complementary [09:11] jelmer: hi.... I'm currently chasing on bug 485601 atm... would you have a moment to lend a quick hand? I have a theory... but am not sure how to reproduce atm [09:11] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 12)" [Medium,Incomplete] https://launchpad.net/bugs/485601 [09:12] vila: ok, just head up. I recall that discussion this morning and decided to ping you anyway [09:13] bialix: thanks, but don't worry, I won't forget this one [09:13] bialix: it just keeps haunting me every other day [09:14] hmm, why people said that my summary about uds is very good? I've just written my personal impressions. I can't say for other: what they did, what they talking about [09:15] vila: at least summary mail to qbzr ML will be good to have, maybe somebody else has similar ideas and willing to implement ;-) === nlisgo_ is now known as nlisgo [09:18] bialix: sure, I'll try to do that as soon as I recover from the fallouts of my HD death [09:19] oh, sorry [09:20] jelmer: I believe there is a race condition in bzr-svn that can cause revisions to not be picked up by bzr from the svn repo [09:37] bialix: what ??? You're the one who killed my HD ? [09:37] :-) [09:37] sorry for bother you while you in such problem [09:42] It's not dead, it's just in Vegas for the weekend. [10:12] zpp: there is an open bug report about an issue like that [10:12] hi, I am trying to install bzr on a mac, but seem to be unable to download the dmg file [10:13] jelmer: I'm just finishing a script to reproduce it reliably, and a potential work around. I'll file a new bug and you can mark as dup if it's the same :) [10:13] I keep getting not-found error [10:13] from launchpad [10:15] fullermd: you know the funny thing about that ? I'm pretty convinced now, that the OS tried to inform me about the problem via syslog looong ago (months), but always failed to do so because... the HD had parked its heads and was refusing all requests :) [10:15] zpp: cool,t hanks [10:16] fullermd: observing syslogd consuming 100% CPU is what led to me think about this scenario [10:16] syslogs 100% and no disk IOs ? Wtf ?? [10:19] vila: Well, that's why you have the OTHER hard drive in the mirror, right? [10:20] * fullermd hugs his ZFS close. [10:20] haaa, interesting solution... I still haven't played with raid so far... [10:21] * fullermd twitches. [10:22] I haven't built a system in more'n a decade without it. I'm not paranoid; I know for a FACT that hardware it out to get me. I don't trust hard drives as far as I can swallow them. [10:23] That wasn't an option with that box anyway, I had to give it for repair as I couldn't access the single HD there (without removing the LCD and having to play with thermal glue or horrors like that) [10:25] HD failures are still rare enough for me that I can cure them on a case-by-case basis, I may have to reconsider though :) [10:27] ignas: try later maybe [10:29] bialix, I thought broken link maybe ;) [10:30] which one? [10:30] if there is broken liunk then it could be a bug in lp [10:34] bialix: no worries, you couldn't know :) [10:39] I'm don't [11:36] hey bialix, why did you put your diff filenames branch back to WIP? Looked good to land to me. [12:10] mgz: heya! [12:11] after some discussion I'd like to change mbcs to terminal_encoding and add --path-encoding command-line option [13:35] bialix: I think it would be better to land what has been approved first. A further (smaller) submission will be easier to discuss [13:36] (Just a general rule, I didn't follow closely enough to know if it was approved or if some tweaks were required) [13:39] It was basically approved, and yeah, further improvements could land on top. [13:57] then at least I should change from mbcs to terminal_encoding [13:57] mgz, vila: ^ [14:00] bialix: yup, sounds fine [14:04] hmph, the problem with using terminal_encoding is you need to be sure it's actually ending up on the terminal (and in which case, you'd be better using unicode) [14:04] mbcs is at least still a reasonable option if it's going into a pipe or file [14:09] lifeless: ping [14:10] he should be sleeping, unless he's not liking his bed again. [14:11] mgz: yes .. just looked up the time in google ... 1am. i really should start taking timezones into account :) [14:20] mgz: not really. mbcs is not good choice for piping [14:20] depends where the pipe goes, which we can't know. [14:20] mgz: with terminal encoding user can at least change that encoding with chcp command [14:21] if I stick with mbcs then... [14:21] if it passes through some byte-manipulating program and ends up on the terminal anyway, we'd want terminal encoding [14:21] if it ends up in a file, we'd want mbcs (or utf8 perhaps) [14:21] mgz: I think the main use case: show me diff on terminal (or paging it via more|less) [14:21] mgz: if we want utf8, then I need --path-encoding option [14:22] if it's going into a program for processing, lots of apps assume their input is in mbcs [14:22] really [14:22] yeah, the paging is the main breakage case [14:22] more really screws things. [14:22] vila, mgz: that's why I want to implement --path-encoding for landing [14:23] but bialix, the current behaviour is a output with mixed encodings, and different from what I get if I use --diff-options=something [14:23] so, the patch as it exists is an improvement [14:24] (I happen to be in a locale where the terminal encoding equals the base encoding, so I'm a little biased :) [14:24] yes, but I've asked people in ru_bzr, and consensus seems to be using terminal_encoding by default [14:24] bialix: I thought poolie wanted to do some infra work that could *also* handle --path-encoding ? [14:25] bialix: so that would be cleaner in a separate submission [14:25] infra? [14:25] yeah bialix, but they're biased because they have a different terminal encoding ;) [14:25] of course [14:26] I'd prefer we did printing to the terminal "right" and solved the paging thing seperately [14:27] (there's no reason to encode to print to the terminal in windows, it's unicode anyway) [14:27] (it's just pipes that are the problem) [14:35] mgz: you know that we don't print on terminal buffer [14:36] not terribly hard to change that though, if it'd actually help things [14:37] yep, but... [14:46] bialix: infrastructure to be able to -opath-encoding=xxx without the need to define --path-encoding, or something along those lines [14:59] vila: I'm not surte it will be so easy [15:01] bialix: which is why it's better as a separate submission :) [15:02] OKAY I'M GIVE UP [15:03] ehehhee [15:03] we've worn him down! [15:05] vila: two things I'd like to bug you about if you've got the time [15:06] bialix: :-) My feeling was that you and poolie had different pov on that, I don't want your actual submission to stay in the queue while it's sorted out, better land the already agreed upon stuff, that was my point since the beginning :) [15:06] mgz: don't ask to ask, ask :) [15:06] it takes time to type! [15:06] oh sorry :) [15:07] vila: 1 - I still don't quite get what state bugs should be ending up in when closed, some people have been setting milestones on things but I don't see any option to do that on launchpad or if I should be doing this [15:07] ack, visitors have just arrived, I'll have to be quick [15:07] Hi bialix [15:08] 1) when a patch has landed is should be 'Fix released', before that it's 'In Progress' is someone is working on it, including waiting for review [15:08] mgz: we don't use 'Fix Committed' anymore [15:08] I guess that you were looking the 0.14.7 release [15:08] Hi all [15:09] vila: 2 - if I want to create a branch, with no tree, for a test, so that I can then try and branch from it as if it were a remote repo, what's the right mechanism for that? [15:09] mgz: it's weird that you don't see milestones, it's the last column (Affects, Status, Importance, Assigned to, Milestone) [15:09] mgz: branch --no-tree (IIRC) [15:11] 'reconfigure --branch' may work too, but it may also be under the shared-repo control, I don't remember the exact rules there [15:12] right, but if I want to do that for a test [15:12] there must be a way not through run_bzr right? [15:13] (I'm thinking specifically of testing filenames that can't be created on a windows filesystem, then trying to create a working tree from that branch) [15:13] bzrlib.branchbuilder.py, sorry I didn't realize you wanted that for tests [15:14] thanks, will look for examples on that later [15:14] mgz: there are more and more examples using it as it's a good way to avoid blackbox tests [15:15] seemed like it might be the right thing but slightly low-level and weird, what with having to make the magic root entries and stuff [15:16] * mgz displays ignorance of how bzr actually *works* [15:16] back to 1 again, eg bug 581298 [15:16] Launchpad bug 581298 in Bazaar "bt.test__walkdirs_win32.TestWin32Finder.test_dir fails without ever being run (affected: 1, heat: 0)" [Undecided,Fix released] https://launchpad.net/bugs/581298 [15:17] should I be setting a milestone there? [15:17] because launchpad gives me no box for doing it (it lists importance, but doesn't let me change it) [15:18] mgz: 1) we set milestone when the submission lands 2) looks like you're not in the right group :-/ [15:18] okay, so should set fixed released and the milestone at the same time? [15:19] you *should* be able to set the importance [15:19] yup [15:19] okay, thanks! [15:20] mgz: meh, you're part of the contributot agreement group and nothing else it appears, try joining some bazaar group :) [15:21] mgz: and be ready to receive some related mail or double-check your subscriptions ;) [15:23] mgz: see http://launchpad.net/~bzr to join [15:23] hi GaryvdM ! [15:23] GaryvdM: yes, I've looked at 0.14.7 [15:25] vila: btw, http://launchpad.net/~bzr said the team is restricted, and there is no easy way to say "I'd like to be a member"? [15:25] right, I was just about to say that. [15:26] okay, lunch for me. [15:27] bon app [15:27] bialix: I'm quite sure that the 2.1 requirement was only introduced in 0.19b1. See http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head:/NEWS.txt#L58 [15:28] bialix, mgz : Hmm, but reading this page: 'Membership is granted to people who've already been active on the list' so presumably poolie or lifeless can add people there [15:28] http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head:/NEWS.txt#L44 (better context) [15:28]