[00:11]  * spiv frowns at https://bugs.launchpad.net/bzr/+bug/709349
[02:55] <poolie> spiv, welcome back
[02:57] <spiv> Thanks!
[06:53] <spiv> It's not every day that I see a 'bzr commit' autopack 28 files (7580) revisions and suddenly take 50 seconds more than I'm used to :)
[06:56] <poolie> hi spiv!
[06:56] <spiv> Hi poolie
[06:56] <poolie> i guess you just passed a big round number
[06:57] <spiv> It's a launchpad repository, so lots of big numbers ;)
[06:57] <spiv> I'm just dealing with the review of https://code.launchpad.net/~spiv/launchpad/haproxy-for-twisted-services/+merge/46996
[06:59] <poolie> mm, that's great
[07:00] <spiv> The kanban board told me to! :)
[07:00] <poolie> hooray
[07:01] <poolie> that's like an ideal demonstration of something nice in twisted: that it's easy to just add an http status page
[07:01] <poolie> i made some quite nice progress on lp:wrested on my flight back and last week
[07:02] <spiv> I saw that post, it certainly sounds nice
[07:06] <poolie> it makes it very easy to fan-out multiple requests, which really helps with latency
[07:06] <poolie> ideally, the api it exposes would not require so many round trips
[07:06] <poolie> eg to get the bug for a task or vice versa
[07:06] <poolie> but, it's useful
[07:07] <poolie> to be able to work around it, and it will probably always be useufl
[07:07] <spiv> Yeah, definitely.
[08:19] <jelmer> moin
[08:38] <poolie> hi jelmer
[08:38] <poolie> i see you're trying out +reviewed tags
[08:39] <poolie> do you think it's worthwhile or is it just an experiment for the kanban?
[08:39] <poolie> which i just updated btw
[08:41] <poolie> oops, but from the wrong team
[08:59] <jelmer> poolie: thanks :)
[09:00] <jelmer> poolie: yeah, I tried them for a bit to see if it'd make by kanban more managable but it'd be nicer to just get rid of that column.
[09:01] <jelmer> w00t, down to "only" 24 assigned bugs :-)
[09:27]  * jelmer goes back to fixing more bzr-hg bugs
[09:27] <vila> hi all
[09:27]  * vila hates crashes to start weeks
[09:28] <jelmer> salut!
[09:28]  * vila blesses backups
[09:28] <vila> jelmer: _o/
[09:28] <jelmer> vila: that doesn't sound nice.. what crashed?
[09:28] <vila> my main desktop, for mail and chat
[09:29] <vila> I think I've got it all sorted up by now
[09:29] <lifeless> vila: again ?
[09:29] <vila> lifeless: not the same :)
[10:23] <jelmer> vila: do you have any experience with python code coverage analysis in bzr?
[10:24] <vila> jelmer: there is an selftest option to activate it, it was fixed for threads long ago, this summarizes my memories
[10:24] <vila> jelmer: may be you have a more precise question ?
[10:25] <jelmer> vila: I'm just curious how hard it would be to check the code coverage of e.g. the bzr-builddeb and bzr-hg test suites.
[10:26] <vila> jelmer: run them with --coverage <dir>, inspect the corresponding files
[10:26] <jelmer> vila: I'll give that a try - thanks
[10:27] <spiv> jelmer: what vila said :)
[10:27] <vila> --coverage is not specific to selftest
[10:27] <spiv> --coverage is a global option, so it can be handy as a quick spot check for finding out which code paths are hit by any random command.
[10:41] <jelmer> maxb: hi
[10:41] <maxb> hi
[10:44] <jelmer> maxb: I'm trying to update bzr-hg to work with mercurial 1.7, but it seems there've been quite a bit of API breakages. Do you know if there are any recommendations documented as to how to update to a newer hg API?
[10:46] <maxb> hm, all I remember is that there is some commentary on api changes on the hg wiki
[10:48] <jelmer> there is /ApiChanges, but it is incomplete
[10:48] <jelmer> e.g. mercurial.changegroup.iterchunks disappeared but is not listed
[11:04] <maxb> hmm, that's rather annoying - sorry, I don't have an answer
[11:06] <jelmer> maxb: np
[12:29] <maxb> Anyone know how to adjust the font size used in "bzr qdiff" ?
[12:35] <johnf> Possibly dumb question, when adding a file to bzr, or at any commit. Is any ctime, or mtime meta data stored with the commit? ie can I tell when a file was originally created or only when it was committed?
[12:39] <cbz> only when it was committed
[12:40] <johnf> That's what I though, lawyers ask some funny questions :)
[12:49] <cbz> it's not a bad idea though - but i guess it comes down to the fact that a vcs is primarily a version control mechanism rather than a backup mechanism
[12:50] <maxb> For the classical use case of actually version-controlling *code*, no one cares about per-file timestamp
[13:03] <pfarrell> hi. can anyone point me at where in the docs it talks about these '.~1~' files? unfortunately google doesn't recognise the string
[13:03] <pfarrell> bzr seems to put them all over the place
[13:04] <beuno> pfarrell, IIRC, they are generally created when you revert files
[13:04] <beuno> as backups
[13:05] <pfarrell> ah, ok
[13:05] <pfarrell> that wasn't obvious to me
[13:05] <pfarrell> thanks
[13:15] <vila> pfarrell: bzr help revert
[13:18] <farfromrefuge> hi everyone
[13:18] <farfromrefuge> i am seeking help about bazaar explorer
[13:23] <jelmer> hi farfromrefuge
[13:31] <farfromrefuge> hi
[13:32] <farfromrefuge> i am trying to customize bzr explorer by adding new toolbars and i was wondering if someone could help me
[13:32] <farfromrefuge> there is an action i cant manage to add
[13:32] <farfromrefuge> i dont event know if its possible
[13:33] <farfromrefuge> i am trying to add "bzr mv --auto" as a button action
[13:36] <farfromrefuge> and i cant get it to work
[13:52] <jelmer> farfromrefuge: I dn't have a lot of experience with the bzr explorer source code
[13:52] <jelmer> perhaps one of the qbzr folks (bialix, GaryvdM) can help?
[13:53] <farfromrefuge> thanks i will ask them
[14:07] <bialix> hey
[14:07] <bialix> while testing bzr 2.3b5 I've discovered nice addtition to status
[14:08] <bialix> 1 shelves exist. See "bzr shelve --list" for details.
[14:08] <bialix> I wonder why "1 shelves exist". Is not it should be "1 shelve exists"?
[14:09] <vila> 1 shelve(s) exist(2) :D
[14:09] <vila> 1 shelve(s) exist(s) :D
[14:09] <vila> grr
[14:11] <bialix> hi vila
[14:11] <bialix> typo ruins jokes, right?
[14:12] <vila> indeed :)
[14:12] <bialix> I'd like to provide the patch to fix this, it's pretty easy
[14:12] <bialix> I hope it can be accepted for 2.3.1
[14:13] <mgz> I hope you include an entire pluralisation framework in that patch.
[14:13] <mgz> just in case we ever need to get it right in czech or something.
[14:14] <bialix> gettext?
[14:14] <bialix> oh, that's be toio easy
[14:14] <bialix> oh, that's be too easy
[14:15] <bialix> wait, we don't use gettext yet
[14:15] <bialix> silly me
[14:15] <mgz> nor is gettext actually any good for... well, anything really.
[14:16] <mgz> but fun plural rules specifically.
[14:16] <jelmer> mgz: it sort of does the job doesn't it?
[14:16] <jelmer> emphasis on sort of
[14:16] <bialix> hi guys
[14:16] <bialix> happy to see you
[14:16] <mgz> yes, I was being a little cruel. it's fine as a way of hacking some localisation on to an existing C program.
[14:16] <jelmer> hey bialix
[14:17] <bialix> mgz: I know
[14:18] <mgz> and language bends, people are used to the sort of mistakes simplistic translation systems make.
[14:19] <vila> mgz: or they learn english if only to translate back into it and get some idea of what has been lost in the translation :-/
[14:20] <mgz> :)
[14:20] <mgz> https://developer.mozilla.org/en/Localization_and_Plurals <- for anyone who wants to read up on the fun.
[16:14] <bialix> which testools I need for bzr 2.3?
[16:14] <bialix> lp:testtools is okay?
[16:14] <bialix> mgz should know ^
[16:15] <mgz> yup.
[16:15] <mgz> you need 0.9.5 or later, which lp:testtools is.
[16:17] <bialix> rats, python setup.py bdist_wininst: ImportError: No module named bzrlib.workingtree
[16:18] <bialix> who wrote that setup.py %-/
[16:19] <mgz> someone who expects all peoples of the world to have bzr installed :)
[16:19] <mgz> I had a hack around it...
[16:20]  * bialix should hack that too
[16:20] <mgz> ah yeah, edit the script to set the version manually.
[16:20] <bialix> bug filed https://bugs.launchpad.net/testtools/+bug/710736
[16:21] <mgz>  -     version=get_version(),
[16:21] <mgz>  +     version="0.9.5",
[16:21] <bialix> oh
[16:21] <bialix> 0.9.5 from tarball is not affected by that problem
[16:22] <mgz> perhaps not, bug was worth filing anyway.
[16:50] <bialix> I hope old way to file merge proposals still work (push to lp and use web interface to propose merge)
[17:19] <samgee> I have the cia plugin installed and it's in the "bzr plugins" list, but for some reason it's not doing anything? Is there any way to sort of reload a plugin?
[17:21] <jelmer> samgee: you need to configure it per project, it has to know what project on cia.vc to submit to.
[17:22] <samgee> Yes, I did that. It was even working before. I have a feeling it has something to do with suspending my computer.
[17:22] <samgee> It also didn't work when I initially installed it. After a while it started working. I don't know what I did.
[17:23] <jelmer> there isn't any way to reload it - if it shows up in "bzr plugins" it should be installed
[17:24] <samgee> Hm. Maybe I should try uninstall + reinstall.
[17:27] <samgee> Crud. Still nothing.
[17:42] <jelmer> samgee: I don't see why that would help
[17:42] <jelmer> samgee: does running "bzr cia-project" in the branch where you're committing print anything?
[17:42] <samgee> Yes.
[17:43] <major> question, bzr baz-import created a pretty weird shared-repository layout..   Is this directory structure mutable?
[17:44] <jelmer> major: yeah, you can move branches about freely (within the same shared repository)
[17:44] <major> and I can shorten directory paths so long as the removed directory doesn't contain a .bzr directory within it right?
[17:46] <jelmer> yeah
[17:46] <major> excitement
[17:46] <major> thanks
[17:47] <samgee> jelmer, I uninstalled the distro package and branched lp:bzr-cia into ~/.bazaar/plugins and now it works.
[17:50] <samgee> Not what I'm looking for though. Getting lp:bzr-cia first and then switching back to distro's version made it work a few days ago. Not so now.
[17:55] <jelmer> samgee: That's odd - I wonder if the installation thing is a red herring, as the required hooks get registered at the same moment as the data in "bzr plugins"
[17:56] <samgee> Back to bzr-cia in $HOME. Works again. Let's see what suspend does.
[18:00] <samgee> Hm. Still works after suspend and hibernate. Then again, I don't remember having the problem with the one in $HOME.
[18:07] <jelmer> samgee: I'd be really surprised if suspend actually has an effect on whether or not bzr-cia works
[18:08] <samgee> I'm just clutching straws. I don't know what else it could be.
[18:08] <samgee> I'm trying some things on another machine.
[19:04] <poolie> hi all
[19:05] <jelmer> 'morning poolie
[19:05] <jelmer> james_w: Thanks again for all the reviews!
[19:05] <james_w> np
[19:05] <james_w> they are small and correct, easy to review :-)
[19:06] <poolie> :) hi james_w
[19:06] <james_w> hi poolie
[19:06] <james_w> you're up early?
[19:07] <poolie> i am
[19:07] <poolie> i have an interview with the DMB to see if i can get PPU rights for bzr*
[19:07] <poolie> i hope enough of them come to make it worthwhile
[19:07] <james_w> ah, good luck
[19:10] <jelmer> oh, that reminds me
[19:10] <jelmer> james_w: I need to ask for another favor :)
[19:11] <james_w> jelmer, sure
[19:15] <samgee> jelmer, found it. I reverted lp:bzr-cia to rev 33: didn't work. Then rev 34: worked. So looks like distro's version is broken after all and I just got confused. Thanks for your time.
[19:15] <jelmer> samgee: can you file a bug against the distro?
[19:17] <samgee> jelmer, I might, but I doubt it will get much attention for Lenny with Squeeze nearing release.
[19:17] <jelmer> samgee: it'd be great to get fixed for squeeze + 1 though
[19:17] <jelmer> samgee: (I'm one of the maintainers)
[19:19] <samgee> Ah. Well, cia-clients in Squeeze = 20100528. rev 34 is from 2008-02-12. I'm guessing it's fixed. :)
[19:20] <lifeless> jam: is loggerhead trunk in 2a?
[19:37] <jam>  lifeless: trunk is
[19:39] <poolie> hi jam
[19:40] <jam> hi poolie, you're up early
[20:29] <jelmer> hey jam
[20:29] <jam> hi jelmer, good morning
[20:29] <jam> or, late evening?
[20:30] <jam> late, late evening, I guess
[20:30] <jelmer> jam: I was about to say, I think it's morning in .au but not for either of us :)
[20:30] <jelmer> it's not too late, 9:30
[20:35] <jam> jelmer: well, late enough that I shouldn't see you *come on* at this time :)
[20:35] <jam> anyway, good to say hi
[20:38] <poolie> hi, it is good to see you
[20:38] <poolie> jelmer could bug 519709 and bug 692901 be the same?
[20:38] <jelmer> poolie: yes, they are
[20:40] <poolie> thanks
[20:41] <jelmer> poolie: congrats :)
[20:43] <poolie> thanks!
[20:44] <poolie> you could do it too
[20:46] <james_w> congratulations poolie
[20:46] <speakman> how can I revert just one hunk in a file with many changes?
[20:46] <speakman> (they're not committed yet)
[20:46] <speakman> something like git's checkout -p
[20:46] <james_w> bzr shelve --destroy <file>
[20:46] <james_w> select the hunk that you want to disappear
[20:47] <james_w> not sure if it writes a backup file first
[20:47] <poolie> now i need to use it! :)
[20:47] <speakman> shelve..?
[20:50] <jelmer> poolie: I'm going to apply for the March meeting, I was too late this time around
[20:51] <speakman> how do I split a hunk?
[20:53] <james_w> speakman, shelve is a bit like git stash. It's used here as it has a mode to drop the changes rather than shelving them
[20:54] <james_w> anyone know where the documentation for setting up an editor to use for editing hunks during shelve is?
[20:56] <poolie> speakman, james_w: bzr help shelve says 'change_editor = PROGRAM @new_path @old_path'
[20:56] <fenrig> Hi i'm looking for a good up to date guide of setting up bazaar on linux, but google doesn't seem to find much, could someone point me in the right direction?
[20:56] <fenrig> Well setting up a bazaar server I mean :D
[20:58] <speakman> poolie: which editor is to recommend?
[20:58] <poolie> fenrig, there's an admin guide under docs.bazaar.canonical.com
[20:59] <poolie> let me know what's missing/wrong in that and we'll fix it
[20:59] <poolie> speakman, well, i'd probably use vimdiff, but meld would also be a good choice
[20:59] <speakman> ok
[21:01] <speakman> hm... will this work on 2.2.1?
[21:01] <fenrig> poolie: I'm looking at your link right now but I don't seem to find where they explain how to set up a bazaar server
[21:02] <speakman> bzr help shelve doesn't mention change_editor here
[21:02] <james_w> speakman, it should work. The documentation was added after the feature
[21:03] <fenrig> poolie: I can use "Serving Bazaar with Apache"??
[21:05] <poolie> fenrig, if you want to publish things over http that's a good choice
[21:06] <speakman> james_w: how do I set the parameter?
[21:06] <lifeless> jelmer: hi; bug 308283 - open question fo ryou
[21:08] <james_w> speakman, I believe you put it in ~/.bazaar/bazaar.conf in the [DEFAULT] section
[21:08] <speakman> $ grep change_editor ~/.bazaar/bazaar.conf
[21:08] <speakman> change_editor = meld
[21:08] <speakman> under [DEFAULT]
[21:08] <james_w> changed_editor = meld @oldpath @newpath
[21:09] <james_w> changed_editor = meld @new_path @old_path
[21:09] <james_w> change_editor = meld @new_path @old_path
[21:09] <james_w> third time lucky
[21:09] <jelmer> lifeless: I'll have a look
[21:09] <jelmer> thanks for the ping
[21:09] <jelmer> I would've missed it in the massive amounts of bug mail about loggerhead I received the last couple of days :)
[21:14] <speakman> $ grep change_editor ~/.bazaar/bazaar.conf
[21:14] <speakman> change_editor = meld @new_path @old_path
[21:14] <speakman> still nothing...
[21:14] <mkanat> lifeless: I'm glad you're doing bug triage for loggerhead. It might be best to assign it to somebody who's familiar with the codebase, though.
[21:14] <james_w> speakman, you can't hit "e" at the shelve prompt?
[21:15] <lifeless> mkanat: what do you mean? I'm reasonably familiar with the codebase - I wrote the search integration for instance
[21:16] <webm0nk3y> I am getting a strange authentication error and a traceback on a laptop that was working: http://pastebin.ubuntu.com/560733/
[21:16] <mkanat> lifeless: That would have been quite some time ago, the search integration.
[21:16] <webm0nk3y> I don't want to file a bug unless I'm sure it's a real problem
[21:16] <mkanat> lifeless: It's changed a fair bit since then.
[21:16] <webm0nk3y>   OSError(13, 'Permission denied')
[21:16] <speakman> james_w: oh, yes I can. Just didn't know :p
[21:16] <james_w> speakman, ah, sorry, should have explained
[21:17] <speakman> :D
[21:17] <mkanat> lifeless: I think both jam and mwhudson have done work on it more extensively and more recently.
[21:17] <lifeless> sure, but whats the functional problem
[21:18] <lifeless> the whole LP team is doing triage
[21:18] <spiv> james_w: looking at https://bugs.launchpad.net/udd/+bug/653307 quite a few BzrCheckErrors seem to have recurred after resetting the imports :(
[21:18] <lifeless> mkanat: 'giving it to someone' would defeat the point
[21:18] <mkanat> lifeless: Defeat what point?
[21:19] <mkanat> lifeless: I don't see anybody but you doing loggerhead triage.
[21:19] <lifeless> mkanat: the point of spreading it over the whole team
[21:19] <mkanat> lifeless: Ah, but it's not being spread, you're doing all of it.
[21:19] <mkanat> lifeless: At least for loggerhead.
[21:19] <lifeless> mkanat: thats because I got it in shape for the team first, so they don't deal with backlog
[21:19] <james_w> speakman, I can just see icu?
[21:19] <lifeless> mkanat: whats the point here, what do you think is wrong?
[21:20] <james_w> err, spiv ^
[21:20] <speakman> james_w: ?
[21:20] <james_w> speakman, sorry, wrong nick highlighted
[21:20] <speakman> :D
[21:21] <mkanat> lifeless: Well, one thing is that you're in charge of the team, so if you make some decision then other people will feel somewhat bound to follow it.
[21:21] <speakman> btw, is it the "new" file that's getting shelved?
[21:21] <speakman> (or destroyed)
[21:21] <mkanat> lifeless: FWIW, I agree with most of your triage--most of those Undecided bugs were Low.
[21:22] <james_w> speakman, if you run without "--destroy", make the changes, and then run "bzr unshelve --preview" you will see what was removed
[21:22] <james_w> aka, I don't know
[21:22] <speakman> :D
[21:22] <spiv> james_w: they're categorised as slightly different errors: dsdo + 3 others, igaelic + 1 other, icu, autofs (maybe that one is new?)
[21:22] <spiv> james_w: but are all BzrCheckErrors about missing CHK root keys
[21:22] <james_w> :-(
[21:23] <james_w> assuming we deleted all the branches then that's bad
[21:23] <spiv> Yeah.
[21:23] <james_w> spiv, have you tried recreating one of them locally?
[21:23] <spiv> On the plus side I couldn't figure out how to reproduce before
[21:23] <spiv> But now there's a narrower set of things to try...
[21:23] <jelmer> lifeless: marked fixreleased
[21:23] <spiv> james_w: not yet, but will today.
[21:23] <lifeless> jelmer: thanks
[21:24] <james_w> spiv: ./import_package.py --persistent-download-cache --no-existing --no-push <package>
[21:24] <james_w> that should be an isolated import
[21:24] <spiv> Thanks, that'll save me from figuring that out again :)
[21:25] <spiv> Although the wiki pages are actually quite helpful.
[21:27] <james_w> spiv, would it be useful to have a "--local" option, or similar?
[21:27] <james_w> or to turn it around and have a "--service" option that is used on package-import.u.c
[21:27] <james_w> so that developers don't have to remember these things?
[21:32] <vila> spiv: you know that the p-i is running bzr-2.1.1 right ?
[21:33] <jelmer> 'evening vila
[21:34] <vila> jelmer: _o/
[21:34]  * vila off
[21:34] <jelmer> g'night
[21:35]  * vila hopes so ;)
[21:40] <jam> sleep well vila
[21:40] <Ronnie> i have a problem merging 2 branches: https://code.launchpad.net/~ronnie.vd.c/loco-directory/570613 into https://code.launchpad.net/~loco-directory-dev/loco-directory/0.2 . It looks like a few files from rev 345 (urls.py and views.py) fail to merge
[21:41] <Ronnie> those files show no conflict nor modified tag
[21:44] <poolie> hi ronnie
[21:45] <Ronnie> hey poolie
[21:45] <Ronnie> poolie: i use these commands to merge http://paste.ubuntu.com/560746/
[21:46] <poolie> i'm just trying it
[21:47] <speakman> is there a way to make multi-branch merge? (octopus merge iirc)
[21:48] <poolie> speakman, just do multiple merges; use --force to let them run even though there are uncommitted changes
[21:48] <poolie> Ronnie, merge tells me about 4 conflicts and bzr conflicts tells me about 4 too
[21:49] <poolie> i didn't run the intermediate commands though, only the merges
[21:49] <Ronnie> poolie: yes, it gives indeed 4 conflicts. i can resolve these. but none of them is related to the files urls.py and views.py from r 345
[21:50] <Ronnie> the intermediate commands are not important to run, it just fills the database
[21:52] <poolie> Ronnie, it looks to me like urls.py is the same in both branches
[21:52] <poolie> isn't it?
[21:53] <Ronnie> poolie: my bad, i mean the views.py and urls.py in the folder /loco_directory/events/
[21:54] <Ronnie> http://bazaar.launchpad.net/~ronnie.vd.c/loco-directory/570613/revision/345 and http://bazaar.launchpad.net/~loco-directory-dev/loco-directory/0.2/view/head:/loco_directory/events/urls.py
[21:54] <lifeless> mkanat: https://dev.launchpad.net/BugTriage is the process I'm following
[21:55] <mkanat> lifeless: Okay.
[21:56] <lifeless> mkanat: we want 0 untriaged bugs so that we know an engineer has assessed all our bugs
[21:59] <mkanat> lifeless: Fair enough.
[22:00] <mkanat> lifeless: The Launchpad project as a whole is definitely yours to run as you see fit to run it, and as you have a broad view and knowledge on it, you would certainly be more qualified to make decisions about the policies for Launchpad as a whole than I would be.
[22:00] <lifeless> well its flacostes, I'm just a caretaker :) - but sure.
[22:00] <mkanat> lifeless: Yeah, but I figure that day to day, the major technical stuff is all you. :-)
[22:01] <lifeless> mkanat: me and my closest 30 friends :P [seriously]
[22:01] <mkanat> lifeless: :-)
[22:01] <mkanat> lifeless: Yeah, I just meant that the buck stops with you for most technical things. :-)
[22:01] <lifeless> by which I mean that I'm an enabler/tie breaker, and should only rarely be setting specific things
[22:02] <mkanat> lifeless: That sounds more like an ideal though than the way things actually run now, though, no?
[22:02] <lifeless> mkanat: I think it runs that way
[22:02] <mkanat> lifeless: Fair 'nuf. I don't know too much about Launchpad day-to-day.
[22:03] <lifeless> mkanat: try keeping up with the output of 30 folk :)
[22:03] <jam> lifeless: I think mkanat's point is that I've never seen someone else on the LP team triage 50 bugs in a day on a project I'm subscribed to
[22:03] <mkanat> lifeless: Yeah, that's why I don't read most of launchpad-dev.
[22:04] <lifeless> jam: there was a very significant backlog
[22:05] <jam> lifeless: I'm not denying it, but saying "it is part of the team", but you're the one who actually steps up to the plate time and again
[22:05] <bdrung> poolie: bug #402814 matters the most IMHO. i had to work around it for vlc: https://code.edge.launchpad.net/~videolan/vlc/master.manual
[22:05] <jam> I've seen poolie do it, and jelmer, but not "generic person" in launchpad teams
[22:05] <jam> but I'm also not subscribed to all of lp, so I might miss when someone else does it
[22:05] <lifeless> jam: :) - well, in this case sure. I think that there's possibly a measurement bias here
[22:06] <lifeless> sinzui for instance, is a questions + triage fanatic
[22:06] <jelmer> Curtis rocks
[22:10] <poolie> jam: do what?
[22:10] <poolie> triage?
[22:12] <Ronnie> poolie: are you already able to reproduce my problem above?
[22:13] <poolie> Ronnie, looking
[22:22] <jam> poolie: triage lots of bugs
[22:25] <poolie> it does seem to me that the lp devs are very quiet compared to bzr people
[22:30] <poolie> Ronnie, sorry, i need to do something else now
[22:30] <poolie> can you please file a bug explaining what you expected would happen?
[22:30] <Ronnie> poolie: thx for your help. Where can i file the bug, lp?
[22:31] <poolie> bugs.launchpad.net/bzr/+filebug
[22:32] <radix> I'm trying to push an earlier revision onto a branch that has a later revision with --overwrite, but it seems to just be ignoring me with "No new revisions to push"
[22:35] <lifeless> radix: is bug, fixed in 2.4 I think
[22:35] <radix> ah, okay, thanks
[22:40] <Ronnie> bug filed: https://bugs.launchpad.net/bzr/+bug/710969
[23:33] <mkanat> poolie: My theory would be that folks who start open source and become corporate are more likely to use the community tools than people who start corporate and go open source.
[23:34] <lifeless> mkanat: doesn't explain launchpad :)
[23:35] <mkanat> lifeless: Ah, well, LP itself started as a corporate project.
[23:36] <lifeless> it did, but the developers didn't.
[23:36] <mkanat> lifeless: None of them?
[23:36] <lifeless> There are two sets you might mean, the original crew, and the current devs
[23:37] <lifeless> I don't know the detailed history of the current crew, though I know many well enough to say they are open source folk first
[23:37] <lifeless> the original crew were all open source heads - folk like spiv, me, etc
[23:38]  * mkanat nods.
[23:38] <mkanat> All of you are pretty involved in using the community tools, too.
[23:39]  * mgz requests the code from lifeless' skull
[23:39] <poolie> hello mgz
[23:39] <mgz> hey poolie.
[23:39] <poolie> mkanat, i'd generally agree, but what's that in connection to?
[23:41] <mkanat> poolie: Oh, you were commenting on how the LP devs are very quiet compared to bzr people.
[23:41] <poolie> oh i see
[23:42] <maxb> Ronnie: I see what is happening here. bzr is doing what it has been told to do correctly.
[23:42] <poolie> yes, i think that does explain some of it
[23:42] <maxb> Ronnie: The problem is that "Michael Hall" has committed a bad merge in the past, which reverts some of your changes
[23:42] <poolie> so then it's not so much community tools, as community mores or customs
[23:42] <mkanat> poolie: That makes sense, yeah.
[23:43] <Ronnie> maxb: is there a way to resolve this, or should i make a diff and copy the contents myself by hand into the merged branch?
[23:44] <poolie> maxb, you can invalidate bug 710969 if you're happy with that answer
[23:45] <maxb> Ronnie: That would work, though there's probably a more bzr-ish way to do this
[23:45] <maxb> Do you use "bzr qlog" by the way? It's probably the best way to examine and visualise what has happened here
[23:45] <Ronnie> maxb: never heard of that command
[23:46] <Ronnie> oh, it isnt installed default
[23:46] <maxb> oopsie, I am falsely impugning "Michael Hall" here
[23:46] <maxb> Ronnie: Actually, *you* reverted your own changes
[23:47] <Ronnie> maxb: how did i do that, and in what revision. how can i see such ' mistakes' ?
[23:48] <maxb> revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt "User syncing should now work"
[23:50] <maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 570613 branch, you reverted most of the changes. Later, the 570613 branch got merged into the upstream branch
[23:51] <maxb> So, there's now a revision merged to trunk which says to bzr "I know about those changes, and they're backed out"
[23:52] <Ronnie> maxb: i think i understand...
[23:52] <maxb> Right, so I think the best way to get out of this is as follows:
[23:53] <Ronnie> those were one of my first real uses of bzr and didnt always use new folders for other branches. My workflow has impoved lately.
[23:54] <maxb> First you merge the revision *before* the revert into your current branch. So by that I mean you merge revid:peter.puk@gmail.com-20101219212247-c3sq6z9sh7tbsflj into your 570613 branch
[23:55] <maxb> Then you merge the revision that did the revert i.e. revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt into your 570613, branch, but you revert the revert before committing - i.e. "bzr revert ." - the . is important
[23:55] <maxb> it says to revert the tree, but not the what-I-have-merged metadata
[23:56] <maxb> By doing this you are telling bzr "I know about this revert, but I've decided I don't want it to happen"
[23:57] <maxb> After which you should be in a position to consider doing the original merge you were intending