[00:15] lifeless, i just wondered why you wanted to push a separate branch for it [00:15] was it blocking you? [00:15] poolie: having reviewed it there seemed no real point not JFDIing it === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: lifeless | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it [00:16] i see [00:16] poolie: I would have pushed to your branch and mp, but lp doesn't really support that as a workflow [00:16] you're pilot this week too? [00:16] poolie: yes [00:16] i think that given lp's current state pushing new ones makes a lot of noise [00:16] poolie: so it took me; oh 30 seconds to pull your branch, another minute ot make the change, bzr lp-propose to make the new proposal was all cli driven [00:16] sure [00:16] its pretty slight to that extent [00:16] but now i have a big old diff in my mailbox :) [00:17] i'm not really complaining [00:17] it's just a bit of a change from the normal practice of committers landing their own code [00:17] there is a backlog [00:17] I could nag folk, but I know people are just busy [00:18] so am doing; I think people will respond by getting there first if they want to avoid the noise ;) [00:19] i haven't had any work hours between some of these being reviewed and you landing them [00:20] poolie: heh, I didn't notice that [00:20] that seems a bit overoptimized :) [00:20] perhaps [00:20] OTOH for all noncommitters we roughly need this anyway [00:21] ah [00:21] and if the fixes aren't trivial to such branches, they will deserve a peer review too; so its worth noting the rough edges - and spiv filed a bug about part of it yesterday [00:22] please let me read the review comments on my branches and land them myself [00:22] unless you know i'm away [00:22] I think its important we make this easy to do; I appreciate there is some noise now, lets make sure there are good bugs and think about how to reduce the noise. [00:22] poolie: for most of yours I have [00:23] it's a bit like the pqm thing [00:23] if you're going to change the patterns in which people work it's nice to tell them first [00:23] poolie: uhm, I've landed one of yours [00:23] two? [00:23] and added a patched version of a second [00:23] I landed your external base deprecation patch [00:25] i appreciate the help i'm just a bit surprised [00:25] poolie: I'm really not sure how to react [00:25] I agree with > I think its important we make this easy to do; I appreciate there is some noise now, lets make sure there are good bugs and think about how to reduce the noise. [00:26] perhaps send an rfc saying that any contributor (or especially the pp) can finish off and land other people's patches? [00:26] if this is what you generally want to do? [00:26] evenin' all [00:27] i guess it's just that with lp reviews as they exist today this seems to generate more noise than me doing the updates in the existing branch [00:27] poolie: this isn' actually a change you know; we've variously landed stuff when people are busy for years [00:27] ok [00:27] i don't know then [00:27] poolie: I can send an email saying 'is the amount of email when I do this too much' [00:28] my answer is yes [00:28] but, whatever [00:28] it's only two patches [00:28] its worrying that two patches makes you feel overloaded :( [00:29] heh === bouncingzip is now known as mgz === r0bby is now known as robbyoconnor [01:52] urk, hung on "Inserting missing keys" pushing to launchpad again [01:53] I won't interrupt it, broke things horribly last time I did that [01:54] better not take hours though I need sleep. [01:55] done. only three minutes with no ui update there: [01:55] 17.046 creating new compressed block on-the-fly in 0.015s 172124 bytes => 58366 bytes [01:55] 196.281 creating new compressed block on-the-fly in 0.000s 4194098 bytes => 2161 bytes [02:05] -> food [02:06] bytes! [02:07] or just nybbles... [02:11] that's a lot of compression [02:11] hi lifeless [02:11] hi spiv === vednis is now known as mars [04:55] i am trying to clean up a testcase http://pastebin.com/t6KvPff0 . if i replace the ".bzrignore" creation with "self.build_tree_contents([('.bzrignore', 'RE:*.cpp\n')])" it fails (run_bzr returns 0 instead of 3). [04:56] doesn't build_tree_contents put a file on disk? [04:59] sorry. mybad. looks like i did something wrong there. its working now :) [05:01] parthm: the u'' there is almost certainly wrong [05:01] parthm: you don't have any unicode in there, and you're not opening an encoded file [05:03] lifeless: yes. i cleaned that up. thanks. [05:05] parthm: cool [05:05] parthm: the alarm bells went off because of the regular file: we write bytes to regular files, unicode to encoded file.s [05:05] lifeless: have you seen the "class _Pattern" in rejected https://code.launchpad.net/~parthm/bzr/300062-invalid-pattern-warnings/+merge/26809 ? that seem like a good cleanup to me. [05:05] i can port it to the error based mp. what do you think? [05:07] its odd that its a class with no methods [05:07] and no global mutatable state [05:08] I think I'd want to see separate patches [05:08] one to introduce such a thing [05:08] and one to change the error handling [05:10] lifeless: sounds fine. i can try a separate patch for that. thanks for the quick review :) [05:10] parthm: I think if you do it, that you should make it a real object w/out static methods [05:11] and either a single global instance, if you really need that, or one instance for the each Globster, or something [05:11] or even [05:11] make it a base class of the globsters [05:11] the file looks half-refactored from functions to objects, to me. [05:13] lifeless: yes. while implementing it i was thinking that much of it fit well in globster. [05:29] spiv: whats the bug # you filed yesterday about LP MP continuations [05:37] lifeless: bug 596726 [05:37] Launchpad bug 596726 in Launchpad Bazaar Integration "Poor support for merge proposals superseded by different branch (affected: 2, heat: 10)" [Undecided,New] https://launchpad.net/bugs/596726 [05:40] thanks [06:14] 'Ello, all! [06:17] I want to try versioning all my work in a centralized fashion, pushing and pulling from various machines to one server. I have a hierarchy of folders for my work...I assume this should be added to the same repository; is there any point in adding E.g. schoolwork and writing (if unrelated) as different projects? Will I lose any flexibility if I just import it all as one project? [06:27] jibbles: if you make it all one project, you can't push just part of it somehere [06:27] jibbles: bzr works on an entire project (we call it tree, or branch) at a time [06:30] poolie: night (signing off work, still around tho in various ways) [06:31] lifeless, good night, thanks for the note about mps [06:32] no probs; we should wait for jam who has expressed pain in this area before deciding what to do [06:41] so I should just manually init each project folder like /stuff/cplusplus/foo with E.g. "bzr init-repo --no-trees sftp://host/srv/bzr/cplusplus/foo" ? Is this how most people do it? [06:42] oops, I meant "bzr init", not "init-repo"; assume the repo was already created [06:43] be back in 20 === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [07:02] jibbles: init-repo creates a repository, which is a storage/speed optimization to allow multiple branches/trees to share a single copy of history they have in common. init, on the other hand, creates a new branch [07:11] Ok, if you were going to version a lot of personal work in one folder hierarchy, what workflow / project divisions would you choose? Any takers? === radoe__ is now known as radoe [07:19] jibbles: I'd just make branches for each project [07:19] and ignore the hierarchy [07:20] hi all ! [07:21] so something like "bzr init sftp://host/srv/bzr/foo" rather than "bzr init sftp://host/srv/bzr/work/programming/cplusplus/foo" ? [07:22] jibbles: the latter [07:24] do you type the whole path for commits, etc.? [07:28] jibbles: no, bzr remembers a default location for commits to checkouts, and for pushes, etc. [07:28] So, maybe the first time you might, but afterwards usually not. [07:29] jibbles: also normally you'd just init on your local disk [07:29] jibbles: and use push to push stuff to host [07:31] Thank you very much for answering my questions, lifeless :) [07:31] Goodnight === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === nlisgo_ is now known as nlisgo [12:00] how can I find %BZR_HOME on windows? [12:01] I would like to create a RULES file [12:01] does it have to be done on a per-user basis or is it possible to have a global one/ [12:05] bzr --version [12:05] and yes, per user [12:07] ok thanks [12:07] if I change an eol rule on windows [12:08] do I need to delete and recheck out the repo [12:08] to get the windows line endings put it [12:08] *in [13:05] hmmm I have set eol native [13:05] and recheckout my repo [13:05] but now in windows all files have changed icon [13:05] I am guessing becuase of the different line endings [13:06] when I do diff it is completely empy [14:03] thrope: sounds like a bug in tortoisebzr (or whatever it is that shows those icons), please file a bug report about it [14:04] spiv: after doing a commit it seemed to be ok [14:04] and the commit doesnt seem to have changed my other checkouts on linux machines [15:38] hello BZR people! I come with limited knowledge seeking help :) [15:39] I am trying to add a blog to the Ubuntu planet but it won't go [15:39] get this error [15:39] ERROR: Cannot lock LockDir(lp-69469520:///~planet-ubuntu/config/main/.bzr/branchlock): Transport operation not possible: readonly transport [15:39] any ideas? [15:41] iainfarrell: did you "launchpad-login"? if you don't login lp default branch to use https which is readonly. [15:41] hello parthm - I have logged in, yes [15:42] iainfarrell: whats the command thats failing? push? [15:43] commit -m [15:43] bzr commit -m "Added Design Team Blog to the Planet" [15:43] which is what I'm trying to do :) [15:45] iainfarrell: do you have commit access to the branch on the server? [15:46] hi folks [15:47] parthm: I _think_ so in that this is the adding to the planet and I'm an Ubuntu Member [15:48] I get some weird flickering issue in explorer using 2.1.1 on XP (and tortoise I guess). Didn't find any info so far, besides a known overlay conflict with DropBox (which I don't feel is related, and I don'tuse anyway). Any tip anyone, please ? [15:49] iainfarrell: i see some talk about this error message on bug #129701 ... seem to indicate that the user may not have write permissions to the branch. [15:49] Launchpad bug 129701 in Bazaar "UnlockableTransport error trying to commit in checkout of readonly branch (affected: 0, heat: 0)" [Medium,Fix released] https://launchpad.net/bugs/129701 [15:50] iainfarrell: what is the "checkout of branch:" shown by "bzr info" [15:50] ok parthm thanks, I guess I will have to find the right person to ask for access [15:50] thats the branch you will need write access to. [15:50] checkout root: . [15:50] checkout of branch: bzr+ssh://bazaar.launchpad.net/~planet-ubuntu/config/main [15:52] iainfarrell: if you are a member of "planet-ubuntu" you should be able to write. [15:52] ahh ok, I think it's because I've not been added to the correct launchpad team [15:52] heh parthm - great minds :) [15:52] iainfarrell: :) [15:53] iainfarrell: i think the message is a bit cryptic. maybe it should be clearer. ... you could file a bug. someone would eventually look into it :) [15:54] So I need to be a member of Ubuntu Members which I didn't check at the start [15:54] I'll get myself added [15:54] you guys ROCK, thanks :) [15:55] iainfarrell, being added to ubuntu members is a big process, as it is community-driven, I'd suggest you talk to someone from IS about it, or jcastro [15:56] thanks beuno I'm talking to Jcastro now :) [15:56] make sure we do this properly :) [16:05] Bah.. I dislike the new shelve plugin. shelve/unshelve/shelf was nice because all the options that weren't -obviously- shelve/unshelve, lived in shelf. shelf list, shelf view, shelf delete,... [16:05] Now they're seemingly-arbitrarily attached to one option or the other. bzr shelve --list, bzr unshelve --preview, bzr shelve --delete-only [16:20] Could anyone enlighten me please ? Using bazaar 2.1.1/xp w/tortoisebzr (0.5.4 by default) -- since this version, explorer "blinks" when getting around to any bzr folder. Fresh reinstall of bazaar/win and reboot reproduce the issue. Any thought ? [16:24] I'll take a really wild guess as I don't know, and suggest it may have something to do with icon caching in explorer. [16:26] Mantrid: thanks - this is all I found, and I can't see it related: http://preview.tinyurl.com/2b8qclg [16:56] Mantrid: the issue was occuring on a test repos, linked to an ftp server which is currently unavail. Could this be related ? Killing explorer mostly killed my windoz session, apps didn't come back when restarting explorer ^^ After restarting the issue still occured. I deleted the repos and created a new, local one: issue is gone. [16:58] in other word: is there any process trying to figure "real time" whether the branch seen in explorer is up to date against its source ? [16:59] hmm. Looks like you may have found the cause. I've not look at the tortoise code so I don't really know much about it. If it does re-occur then perhaps you can determine if it is related to the ftp server. [16:59] Ah you should ask the totoise devs. I believe there are hooks in explorer that tell you something is happening and probably we hook into that. [17:02] I've been using/setting up tortoise/cvs&svn an awful lot and never saw any similar issue. toirtoise was not 100% perfect but still the easiest for non-technical users ^^ [17:08] I've got a question cf. topology: two developers need to use bzr on their respective laptops, no server involved, just an ftp folder as a "relay" between both devs, one of them is the "gate keeper". Another ftp server should be used as an extra backup place. I guess it's a very common scenario on small projects ^^ [17:10] caravel: right, that should work without issues [17:12] None of the ftp servers are considered reliable. Should the main repos be created as independant on the gate keeper's laptop, then "pushed" onto the relay ftp ? To automate the ftp "waterfalls", should be use bzr client from the backup ftp to the relay ftp folder ? [17:13] (backup ftp is a debian server we administrate, so we can setup bzr client here) [17:14] Or... should the gate keeper define the main repos to be located on the relay ftp, then work on his local copy until remote commits ? [17:15] Finally, is there any difference between both results ? [17:18] Do you mean, should you use bzr to transfer the branches to the ftp server, or should you copy them up there? [17:20] Mantrid: well, no: I hadn't consider NOT using bzr for replication, since I was assuming bzr would be more efficient than eg rsync for this (one of our criterias to chhose bzr actually, is that it's said to support folder renaming and files moving) [17:20] but should I ? ;-) [17:21] no I'd use bazaar to do everything. i.e. to push it up to the ftp server. That way it will lock the branch for you and prevent any accidental overwrites and so on. [17:23] ok, so dev A should make a "standalone" branch on his laptop, then "push" it on the relay ftp... which should be simply branced by dev B and the backup debian. Right ? [17:25] yes I think so. But I don't quite understand, what is "backup debian" ? The ftp server is just to share the code isn't it between dev A and B right? [17:26] I've no doubt seen this I assume: http://wiki.bazaar.canonical.com/Workflows [17:28] sounds like this "Decentralized with human gatekeeper" except the gatekeeper is also developer B (or A) and you have some other debian server involved. === beuno is now known as beuno-lunch [17:32] Mantrid: Yes, I have seen this again and again ;-) dev A & B both travel quite extensively. "relay ftp" is a poor windo$ machine located at dev A home with unreliable connection (dev A is an independant consultant). dev B does internal QA and small contribs. "backup debian" is a modest server "on site" with unreliable connection, but we want a copy there, even if sometimes a little outdated. Purpose of the repo is a whole web site inclu [17:33] Mantrid: sorry I guess this is almost flooding, did you receive this entirely ? [17:34] missed the end :P But I think you say the debian box is where you would call the main repository where the code will have it's home. [17:34] and the ftp at A is so that dev B can get A's work. [17:35] You needent have a gatekeeper. It depends if you want the code reviewed or not before it goes to the debian server. I guess you DO want it reviewed yes? [17:36] Mantrid: well... dev A need NOT to rely on debian. YES, dev A must review anything, he's the only one skilled with the code he's using [17:37] here is the end of my prev msg ^^ "backup debian" is a modest server "on site" with unreliable connection, but we want a copy there, even if sometimes a little outdated. Purpose of the repo is a whole web site including many media files. Sync don't have to be very often (2 weeks), and will be scheduled ^^ [17:38] Mantrid: what we need really are mirrors of what dev A is doing + the ability for dev B to contribute (for exclusive approval by dev A) [17:39] in which case dev B can put the code somewhere, anywhere in fact and tell dev A to review and merge. you can even use bzr send to send a bundle. [17:40] dev A can then push up to a mirror and or release site. [17:43] Mantrid: (bundles could be huge) ok, so the main branch should be located on dev A laptop -- then pushed up his home ftp. Is this correct, will bzr handle his subsequent pushes to let him update ? [17:45] yes that will work. Unless someone else pushes and update to the same place on the ftp server first. In which case bzr will tell your the branches have diverged and dev A will have to merge. But. that should not happen as each developer will have his own place on the ftp server to put code, and so pushes will just "go up" - the differences (new revisions) will get pushed. [17:47] In all cases, only the differences will get pushed up no matter which developer is pushing where. [17:48] Mantrid: ok, so it seems perfect: actually, since the only purpose of the ftp is sharing a copy of the main branch (which sits on dev A laptop) then if dev B wants to contribute it is perfect: he could push also to the same space, forcing dev A to merge before re-pushing. Right ? [17:48] so 1. You can't really break anything by accident, bzr will tell you. 2. It will be quick to push (after the first push of all the data) [17:49] Mantrid: brilliant. thanks, I think I had not understood what was a bzr "push". cheers [17:50] yes that's right. [17:51] you can push the the same place. But if it's changed, he would have to merge back down first. But you said you want dev A to review the code first, so both the devs would use seperate places. [17:52] I suggest you give it a little try out. You don't have to use an ftp server. You can pretend that /home/ftpserver or c:\ftpserver is your ftp server. [17:54] What I do is the same for small projects. I push my work upto an sftp sever, so does my collegue. If I own the project, then I merge his work from the ftp server into mine and check it works, and then I push it back via sftp to what I call the mainline location which is seperate from both our branches. [17:56] Mantrid: ok, but then do you use a shared repos for both branches, so the repo location is on the sftp server (and not on your workstation), right ? Then your mainline is a seperate bzr repo, even if it is 99% a duplicate of the dev area ? [18:01] erm. you can do either. With two people it doesn't matter so much. But you can have a separate branch on the server called mainline if you want, that is if you like the "proper" stable code. That's separate from each of the developers branches. But you don't have to. If might be best though and then you can have a rule that says the mainline code must always at least be in working order. Whereas the developers branches don't have to be. [18:02] So developer B will then refresh his branch "pull" or megre from either dev A's branch, or the mainline that that developer A manages. [18:04] in any case. No matter what developer B does, whereever he gets the code from. bzr will pull it, or will tell him he needs to merge. There will be no problems of getting out of sync. [18:07] Mantrid: I understand - in our case, dev A branch need to remain purely local to dev A laptop (yet it is a big effort for dev A to start using a VCS, can't push it too far). So he'll push "stable", dev B will update from "stable" and push to "B branch", from which dev A will merge ^^ OK, unless you need to correct me again I think it's all clear [18:08] Yes that's it. And you can change your mind later if there is another way it's not a problem. [18:10] dev B can pull or (update) from DEV a's branch directly if he wants to help dev A fix something toghther and then push his branch up. it will still merge correly, bzr will track all the changes no matter which branch they come from. [18:10] but maybe I am confusing you now. Try it out, and you will see. [18:12] also the bzr missing command can be helpful. it will give you a list of changes essentialy from what you have. You could say bzr sftp://server.com/projectx/trunk and it will tell you waht's changed, and what changed you have made that isn't up there already. [18:14] Mantrid: sure ;-) again, dev A branch won't ever be accessible or published, only stable. Look: yet if I succeed to introduce the word "stable" itself as a concept in this little team, I think it will be a great victory!! I already know that after this essential move (start using a VCS, finally), dev A won't have/take/accept to spend any time to reconsider anything, not even a sec ;-) [18:15] Mantrid: thanks a lot for your clarifications. Bzr definitly sounds a lot more flexible than cvs/svn (or, well, then what I experienced with these). [18:16] Yes. When you try it out a bit you will understand it better and it will make more sense to you. [18:17] * caravel gives #bzr a break and is quite thankful to Mantrid [18:17] :-) === beuno-lunch is now known as beuno [18:26] mornin [18:52] evening. Got to run. [20:11] this is going to be fun [20:11] "Note that when os.listdir() returns a list of strings, filenames that cannot be decoded properly are omitted rather than raising UnicodeError." [20:14] urgh. [20:14] Whoever thought *that* was a good idea [20:14] python3 has a bit of architecture-astronaut feel to it [20:14] in the whole unicode string thing [20:15] lifeless: so now they are omitted rather than returned as 8-bit strs? I thought there is a proposal to give them as private-plane code points, or something like that [20:15] 3.2 or something like that will do a surrogate escaping thing for non decodable filenames which is better [20:15] jam: no, thats the 3.0.1 docs [20:15] I'm going to assume that architecture-astronaut means something like being designed from a viewpoint far too far away from the problem? [20:15] maxb: yes, one ignoring inconvenient realities ;) [20:15] lifeless: malformed files don't exist [20:16] and if we all cross our fingers and believe that really hard, maybe it'll come true! :-) [20:16] wait. you mean Santa doesn't exist? [20:17] * rubbs cries himself to sleep now. [20:17] rubbs: no no, santa *does* exist, malformed filenames don't [20:17] jam: oh, thank you for re-enforcing my irrational beliefs. [20:17] similarly the current discussion about why URLs are all Unicode strings in python 3 [20:18] malformed files are what you get for Christmas if you are on santa's naughty list [20:18] though from what lifeless has convinced me, you're not supposed to touch anything that you don't control [20:20] right [20:20] there is a large amount of close your eyes and ignore the world involved in browser address/location bars [20:20] and if you read that thread, to see the references to single urls that go [20:21] host/encodingA/encodingB [20:21] and then ask yourself how a user is possibly meant to create-guess a url for that server ;) [20:34] is it bad form to call the cmd_* classes from another python script? [20:50] rbriggsatuiowa: not at all, though I'd recommend using our factory facilities rather than constructing the objects directly. [20:50] e.g. bzrlib.commands.get_cmd_object('foo') [20:52] lifeless: thanks - also, when I try and merge one branch into another - the files show up - but the merge history does not (it does when I run bzr merge manually) # I'm passing cmd_merge().run(location=merging_location) [20:52] lifeless: (currently refactoring to use command factory) [20:52] rbriggsatuiowa: check bzr status [20:52] rbriggsatuiowa: I bet you haven't committed after the merge ;) [20:53] lifeless: reverting and trying with factory [20:53] rbriggsatuiowa: some commands override run_argv_aliases, but not all that many [20:53] rbriggsatuiowa: the factory change won't fix the issue, its merely to let you get plugin enhanced command objects and so on [21:05] lifeless: could you help me with this? the merge history doesn't show up and the lockfile stays locked (if I run this manually it behaves normally) [21:05] lifeless: https://gist.github.com/d0ecf3eb46b7fbec71e0 [21:06] 'lockfile' ? [21:06] oh right [21:06] you really want to be calling run_argv_aliases [21:07] as currently setup bzr command objects 'run' method is only really public if you are implementing a whole UI environment [21:07] you seem to just want to reuse the command as is, so you should reuse much or all of the UI environment too [21:08] what bzrlib version are you iusing? [21:08] rbriggsatuiowa: ^ [21:09] 2.1.1 (I run apt off of the ppa) [21:09] righto [21:09] so I think I know what is happening [21:09] just chekcing [21:10] right [21:10] cmd_merge uses cleanups [21:10] in 2.1.x the run() method is not safe to call because only higher levels in the call stack ensure cleanups are run [21:10] so call run_argv_aliases [21:10] which is a little less python [21:10] and it will work [21:10] or grab 2.2b3 [21:13] lifeless: trying it out [21:22] lifeless: you've approved lp:~jspashett/bzr/missing_win32api_for_test but shouldn't it use Gordan's ExcutableRequired or whatever it was called instead? [21:22] mgz: it may want to use that as well [21:22] mgz: but his specific issue is his python doesn't have the win32api module [21:23] lifeless: bzrlib.commands.get_cmd_object('merge').run_argv_aliases([merging_location]) # worked - thanks a bunch [21:23] ah, so it actually does require pywin32? [21:23] in which case, ignore me, it's fine. [21:23] so he says, and my general thought on $notmyplatform things is - if they say it works and it looks plausible, land and fix later if needed. [21:25] yup, it's correct. [21:26] thank you [21:27] the actual function it's testing is horrible, but hey. [21:28] mgz: after all, where would we be without horrible code ;) [21:28] hahaha [21:28] TresEquis: a land of shinging light [21:30] rbriggsatuiowa: excellent [21:36] re: his other branch, it's landable. [21:37] I take Alexander's +1 as meaning Approve as well [21:38] it's just a big confusing merge proposal discussion with lots of different threads of conversation going on [21:38] ok [21:38] has he pulled your stuff in ? [21:38] if not [21:38] can you please: [21:38] he has [21:38] ok cool [21:38] it's a little confusing as launchpad somehow has it listed above my comment [21:39] please file a bug [21:39] perhaps because my commit timestamps predate the comment and it's not a merge? [21:39] which is arguably correct [21:39] well [21:39] a timeline has a context [21:39] 'when it becomes visible in the context' is better than 'when it was created but still not visible' [21:39] right, which would be "when did launchpad get this branch" I guess, rather than when the commit happened [21:40] embugginate! [21:40] mgz: right [21:40] in fact, [21:40] when did this branch, which is proposed, get this commit on its mainline [21:40] mgz: please try toggling https://code.edge.launchpad.net/~jspashett/bzr/587868_args_handling_cant_debug/+merge/28129 to approved [21:41] I have no means of doing so. [21:41] mgz: didn't we give you pqm access ? [21:41] oh, it can be done via pqm? I've not tried that. [21:41] no [21:41] separate related question [21:41] did we give you pqm access? [21:42] I thought we did [21:42] yup, I have an open tab somewhere with john's pqm plugin that I mean to get round to working out [21:42] ignore that for a sec [21:42] please visit this page https://edge.launchpad.net/~bzr-core [21:42] (ignore the name, its misleading) [21:43] it will say somewhere near the middle [21:43] 'are a member' or 'are not a member' [21:43] ah, yeah, I'm not member of any teams on launchpad [21:43] are you willing to be ? [21:43] joining either ~bzr (bzr and all plugins) or ~bzr-core (just bzr itself) will grant review control [21:44] do I get a sticker? [21:44] which you have at the social level [21:44] heh :) - you got the tshirt instead [21:44] yeah, I can join one of these, last time we looked at it there wasn't an obvious way [21:44] but I now see a join button, so was perhaps just being blind before [21:44] mgz: no [21:45] tell me which one you'd like to join [21:45] core+plugins, or just core [21:45] I've just hit join for bzr-core [21:46] the ~bzr team got lots of folk that weren't really interested in teh community, more just wanting help/cds/fanboy at one point [21:46] so its set to restricted, which I think has a bad UI in LP [21:46] because you can't *apply*, you have to be *added* [21:46] and there isn't even a 'but please sir' mechanism, which the slightly more open 'moderated' setting has. [21:47] presumably you now have an approve button somewhere? [21:47] mgz: so, just-core is what you want ? [21:47] mgz: in moderated mode, yes. [21:47] yup, core will do as I've only looked at a few bits of qbzr and so on [21:49] ok [21:49] I could add you to ~bzr, but martin is the owner of ~bzr-core and neither I nor a group I'm in are administrators in that team [21:49] so [21:49] when poolie gets up, you'll get review approval facilities [21:49] cool. [21:50] have you looked at hydrazine ? [21:50] it needs the launchpad API stuff, but thats pure python and should be ok on windows. [21:50] notyet, alexander expressed some fear of it. [21:50] Famous Last Words. [21:51] mgz: well the next step in getting you fully enabled here... is getting you running hydrazine [21:51] pqm-submit is a terrible weapon from a bygone age [21:51] oh, the launchpad api things I tried to use when we were doing that stop-using-edge-thing [21:51] yeah [21:51] mgz: as I read the diff [21:52] and it nearly worked, one of the (many, ugh, setuptools) bits had a recent 2.4 compat thing I submitted a merge proposal thing for [21:52] s is now unused ? [21:52] mgz: also, typo, line 106 [21:52] it's just an iterator, that we listify. [21:52] spit the command line [21:53] yeah, the comments are a little suboptimal, and there are some existing and new >80 char lines [21:54] roasting the commandline on a spit is about right though. [21:54] ok [21:54] so where I was going with all this [21:55] hydrazine has [21:55] $python feed-pqm bzr [21:55] it will, once sufficiently stabbed, land stuff and its the interface I'll be fixing up to use LP APIs for merge control in the future [21:57] I think it would be great if you had it working [21:57] and this patch seemed like a perfect worked-example [21:57] particularly as there are a few more quirks to get out [21:57] if its not too late, and you're interested in doing that, I'd love to work through it with you [21:57] okay, so, you're kindly offering to walk me through landing this? [21:57] letsdoit [21:58] yes [21:58] so firstly, lets assume this is perfect as is [21:58] to do the simple path through [21:58] (you can after we get it going land a trivial tidy up :)) [21:59] I've 'approved' the patch [21:59] in principle you just do [21:59] python feed-pqm bzr [21:59] it should be the first patch up, so you'd hit e\n [21:59] and away it goes [22:01] just reinstalling and patching the launchpadlib stuff [22:03] okay, feed-pqm launches browser window pointing at edge [22:03] right [22:03] this is the login step [22:03] oauth style [22:03] feed-pqm will need to change any data [22:04] anything, or non-private? [22:04] the permissions are very broad, but you get to see the code ;P [22:04] anything [22:04] if you were to have a private branch [22:04] you would want to be able to land it. [22:04] A major security fix might get that treatment, for instance. [22:04] gotcha. [22:05]