[01:00] <spiv> Good morning.
[01:00] <jbowtie> Good afternoon.
[01:02] <jbowtie> Looks like my documentation patches have been reviewed. Feel like I'm making good progress.
[01:02] <jbowtie> Though I've noticed several times that a bug has been fixed but never updated.
[01:06] <spiv> jkakar: I wonder if that's often because someone just fixed something they happened to notice right then, without first looking in the bug tracker?
[01:12] <jbowtie> spiv: I presume so. I've been slightly lazy and just marked them as "fix committed" with "2.2" as the milestone if I can see the fix in the 2.2 docs or help output.
[01:13] <poolie> hi there spiv, jbowtie
[01:14] <jbowtie> It would be nice if there was some simple way to figure out which version branches a revision actually ended up in, then I could be more precise.
[01:15] <jbowtie> That's probably a nice loggerhead feature for me to try writing sometime.
[01:15] <spiv> jbowtie: we don't use "fix committed", use either "in progress" or "fix released": http://doc.bazaar.canonical.com/latest/developers/bug-handling.html#bug-status
[01:15] <jbowtie> spiv: My bad, I actually did set them to "fix released".
[01:15] <spiv> jbowtie: don't worry too much about setting the milestone if you're not sure when it was fixed, the main thing is to have the bug closed.
[01:16] <jbowtie> spiv: We really should get rid of that bug status though so it's not accidentally used.
[01:16] <spiv> You can always leave a comment saying "this appears to have been fixed sometime before 2.2" or whatever.
[01:16] <spiv> Yeah.
[01:17] <spiv> It's https://bugs.edge.launchpad.net/malone/+bug/163694
[01:17] <ubot5`> Launchpad bug 163694 in Launchpad Bugs "Fix Committed/Released distinction is inconsistent and unproductive (affected: 12, heat: 45)" [High,Triaged]
[01:18] <jbowtie> Well, I could, but it would be good to know in particular for documentation fixes as a fair number of them can be backported and improve the user experience (like fixes for broken links).
[01:23] <jbowtie> poolie: Sent through my CV a couple of days ago for the BSE, it's about 6 months out of date so let me know if you need any supporting material/links.
[01:23] <poolie> jbowtie: if the "giving back" documentation could be clearer, please ask or send a patch or file a bug
[01:23] <poolie> oh great
[01:23]  * poolie look-s
[01:23] <poolie> i don't have it from HR yet
[01:23] <poolie> probably will today-
[01:24] <jbowtie> poolie: No worries as long as it didn't end up in the recycle bin.  :)
[01:27] <jbowtie> Wow, 3 years and no one's rolled a patch for that bug. I might be diving into the launchpad code tonight just so I stop using that bug status.
[01:27] <poolie> now that would be an impressive bug to fix
[01:27] <poolie> it's only about 10% code and 90% social
[01:27] <poolie> getting sufficient agreement that we will indeed transition away from it
[01:27] <poolie> feeling confident enough users will be ok with that plan
[01:28] <poolie> communicating it
[01:41] <poolie> you're the pilot this week?
[01:41] <spiv> Apparently! :)
[01:41] <spiv> Which is good, because I was just starting to think how nice it would be to clear out the +activereviews page...
[01:45] <jbowtie> Is there anything better than Empathy for IRC? It's annoying to connect to new rooms via the Empathy dialogs.
[01:48] <poolie> spiv that would be great
[01:48] <poolie> jbowtie, on ubuntu?
[01:48] <poolie> i use xchat for irc and pidgin for other stuff
[01:49] <jbowtie> poolie: Yes, thanks, that's the one I couldn't remember the name of. I knew there used to be a different default IRC client but could not think of it.
[04:47] <poolie> spiv, thanks for the changelog merger, could you add it to the plugin guide?
[04:47] <poolie> which i think is in the bzr-alldocs project
[04:49] <spiv> poolie: good idea, but let's wait until it's had a little bit of real-world exercise first, in case it's horribly broken :)
[04:51] <poolie> :) oh i don't know, you could always list it as 'alpha'
[04:54] <spiv> I was thinking of the part of http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#adding-your-plugin-to-the-plugins-guide that says "i.e. inclusion in the Guide implies a certain degree of this works as advertised."
[04:54] <AfC> What is this «works» you speak of?
[04:54] <spiv> If Eli reports that it works ok then I'll consider it to have met that hurdle.
[04:55] <fullermd> AfC: It's this low-end office suite made by Microsoft...
[07:48] <vila> hi all !
[07:48] <vila> ping losa
[07:48] <spm> heya vila
[07:48] <vila> wow, instant answer :-)
[07:48] <vila> spm: be careful, I may ge used to it :-p
[07:49] <vila> spm: it's about RT #41434
[07:50] <vila> spm: aka, pulling bzr.dev in bzr-2.3, I asked for revno 5432 in the ticket, but reno 5424 will be fine too
[07:50] <vila> spm: better stick with as much 4 as possible...
[07:51] <spm> more 4 is good, 4 4's are better 4 us?
[07:51] <vila> spm: yeah, but don't overdo it, reno 4444 won't be good  ;)
[07:51] <spm> :-)
[07:53] <poolie> hello vila
[07:53] <vila> poolie: hey :)
[07:53] <spm> vila: Ok, re-read about 4 times, I think I know what's needed now :-)
[07:54] <vila> spm: :-/ How should have I better phrased that (and is this sentence correct english ?) ?
[07:54] <spm> vila: ha. no. the english etc is fine. more "switch mindset to understanding what you want"
[07:54] <vila> k
[07:55] <spm> if you like - translating the plain request into technical "Do X, Y and Zeee"
[07:55] <spm> it's this stuff: https://wiki.canonical.com/InformationInfrastructure/OSA/PQM#BZR%20%28the%20project%29%20and%20PQM <== more or less
[07:56] <poolie> vila, thanks for all the releases
[07:56] <vila> poolie: about the flagship bugs, from the series pages (https://edge.launchpad.net/bzr/2.0/2.0.6 etc) I'd say: 2.0.6 -> bug #582656, 2.1.3 -> bug #525571 and 2.2.1 -> bug #633745 thoughts ?
[07:56] <ubot5`> Launchpad bug 582656 in Bazaar 2.1 "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 2)" [High,Fix released] https://launchpad.net/bugs/582656
[07:56] <ubot5`> Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 7, heat: 51)" [High,Fix released] https://launchpad.net/bugs/525571
[07:56] <ubot5`> Launchpad bug 633745 in Bazaar 2.2 "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/633745
[07:56] <vila> good bot... awesome
[07:58] <vila> about bots, I discover http://www.youtube.com/watch?v=rSKRgasUEko this week-end, amazing and almost affordable (the rumour is ~3000euors, i.e. a big PC)
[07:59] <vila> poolie: yeah, it still took me to much time but I think we have already pushed a lot of hurdles out of the way by integrating them earlier in the workflow
[07:59] <vila> poolie: and I didn't find obvious mistakes in releasing.txt :-)
[08:00] <vila> poolie: I changed checknewsbug.py to use hydrazine instead of lp anonymous
[08:01] <poolie> hm
[08:01] <poolie> is that better?
[08:01] <vila> poolie: yes, notably for private bugs
[08:02] <poolie> right
[08:02] <vila> I was able to fix the remaining typos. The script helps to identify them but not fix them. We could try some permutations but I didn't have time to play with that
[08:02] <poolie> we should post on the blog too
[08:03] <vila> err, about what ?
[08:03] <poolie> that we released
[08:03] <vila> the releases ?
[08:03] <poolie> though i guess the homepage aggregator shows it
[08:03] <vila> ha, before the installers are ready ?
[08:03] <poolie> and i'm not sure it's worth blogging everything
[08:03] <poolie> heh
[08:05] <vila> so, the remaining "problems" for checknesbug.py is that some bugs are still in progress... That is, we've fixed part of the bug and landed the fixes, yet, the bug can't be considered fix released...
[08:07] <vila> #583667 #598701 #601804 #566940 #82086 #219334 #375013 etc
[08:07] <vila> pfff
[08:07] <vila> bug #583667 bug #598701 bug #601804 bug #566940 bug #82086 bug #219334 bug #375013 etc
[08:08] <ubot5`> Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 2)" [High,Confirmed] https://launchpad.net/bugs/583667
[08:08] <ubot5`> Launchpad bug 598701 in Bazaar "bzr should not show internal object name in "<rev> does not exist" error (affected: 1, heat: 5)" [Low,Confirmed] https://launchpad.net/bugs/598701
[08:08] <ubot5`> Launchpad bug 601804 in Bazaar "test failure on hardy: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/601804
[08:08] <ubot5`> Launchpad bug 566940 in Bazaar "Reducing peak memory for commit (affected: 2, heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/566940
[08:08] <ubot5`> Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/82086
[08:09] <vila> that's not so bad, but if we were able to make it pass silently we could add a regular check so further reduce the burden on the RM
[08:09] <vila> s/check so/check to/
[08:10] <spm> vila: fyi, that's been done: https://code.edge.launchpad.net/bzr
[08:11] <vila> spm: rock and roll, release time for 2.3b1 !
[08:11] <vila> spm: thanks !
[08:13] <vila> meh I meant bug #522637 as flagship bug for 2.0.6
[08:13] <ubot5`> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 68)" [Low,Triaged] https://launchpad.net/bugs/522637
[08:14] <vila> poolie: hmm, what was the last bug you used for SRU ?
[08:19] <poolie> vila, for 2.2.1?
[08:20] <vila> poolie: no, I'm looking for one that has already been nominated
[08:20] <vila> poolie: and I found bug #636930 for 2.2.1 which I will use indeed
[08:20] <ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 876)" [High,Triaged] https://launchpad.net/bugs/636930
[08:20] <vila> poolie: just added sru as an official tag
[08:22] <poolie> k
[08:23] <poolie> i don't know if it's the latest but bug 528041 is one recent one
[08:23] <ubot5`> Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 134)" [Undecided,Confirmed] https://launchpad.net/bugs/528041
[08:23] <vila> poolie: right, thanks, exactly the one I had in mind
[08:32] <vila> maxb: just checking, all your work on tools/packaging/* has landed in bzr.dev right ?
[08:35] <vila> hmpf, lp:~ubuntu-branches 244840 owned branches...
[08:36] <spiv> Ugh, hooks.py is a bit ugly.
[08:36] <maxb> vila: Um, I think "all my work" was pretty much just a change of the branch naming scheme, but yes, it landed.
[08:37] <spiv> We're overdue for extracting a "give me the python object named by given a module name and optional dotted attr" function, I think.
[08:37] <lifeless> spiv: doesn't twisted have one of those?
[08:37] <lifeless> spiv: perhaps they could have their arms twisted to make a separate release of that, and we could depend on it
[08:39] <vila> maxb: excellent, I just noticed that it would be good to check for $PACKAGE as we do for $UBUNTU_RELEASES, I will do that
[08:40] <vila> maxb: hmm, well, it won't fly for update-packaging-branches :-/ There is still a '~bzr' there that won't scale for other packages (when the script *creates* the local branch)
[08:47] <vila> maxb: you use a single shared repo for all your packaging branches whatever the package is right ? All of them in a single directory right ? (aka bzr-lucid and bzr-svn-lucid are in the same dir on your local disk)
[09:04] <vila> GaryvdM: Hey !
[09:04] <GaryvdM> Hi vila
[09:04] <GaryvdM> Hi all
[09:05] <vila> GaryvdM: would you be working on the 2.2.1 windows installers ?
[09:05] <GaryvdM> vila: Yes. I'll start maybe today, or maybe tonight.
[09:05] <GaryvdM> Depending on work.
[09:06] <vila> GaryvdM: cool, would you mind updating http://wiki.bazaar.canonical.com/Releases/2.2.1 ?
[09:07] <GaryvdM> Ok
[09:07] <vila> maxb: do you know who we should/could ping to update the debian side for 2.2.1 ?
[09:08] <fullermd> vila: <http://lists.freebsd.org/pipermail/cvs-all/2010-September/321850.html> BTW, so we can mark that off if we're keeping track.
[09:09] <vila> fullermd: yup
[09:11] <GaryvdM> vila: pkg-bazaar-maint@lists.alioth.debian.org
[09:11]  * GaryvdM trying to find out who the members are
[09:11] <GaryvdM> I know offhand jelmer is one.
[09:12] <vila> GaryvdM: hmm, does this mean we should start my a *mail* there ?
[09:12] <vila> s/my/by/
[09:14] <GaryvdM> vila: I think so
[09:15] <vila> fullermd: updated
[09:15] <vila> GaryvdM: k
[09:15] <GaryvdM> vila: 2.2.1 should have shown up on this page in the watch column: http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org
[09:16] <GaryvdM> I'm not sure why it has not, maybe update delay...
[09:17]  * vila blinks
[09:17] <vila> there is a lot of numbers to grasp here...
[09:17] <vila> are even
[09:18] <vila> or does 'is' apply to 'a lot' ...
[09:18] <maxb> vila: But all the ~bzr PPA packaging branches should be in ~bzr anyway, no, so no problem?
[09:18] <vila> applies... here we go typo fest !
[09:18] <vila> maxb: !
[09:19] <maxb> vila: Personally, I created my packaging branches before I encountered tools/packaging/, and so haven't really found a use for those scripts yet
[09:19] <vila> maxb: sounds right indeed, worth a comment
[09:20] <vila> maxb: no problem with that, but since I'm starting from scratch (removing my old crufty attempts), I may as well make it easy for the next RM
[09:20] <maxb> vila: http://packages.qa.debian.org/b/bzr.html says jelmer usually does Debian
[09:20] <vila> jelmer. jelmer, wake up, wake up :-D
[09:21] <vila> maxb: thanks for the pointer
[09:22] <vila> haaa, larstiq and jonhf are there too
[09:22] <vila> so, if I read that correctly they want 2.1.3 and 2.2.1 first,
[09:23] <vila> then 2.3b1 will enter the game... or will they wait for 2.3.0 ?
[09:23] <spiv> lifeless: twisted does have something along those lines, but it's pretty easy to do, and we already have the code for it really, just not in an especially reusable spot
[09:23] <vila> maxb, GaryvdM: Anyway, it means I should forward announcements for 2.1.3 and 2.2.1 to pkg-bazaar-maint@lists.alioth.debian.org, right ?
[09:24] <spiv> lifeless: which leads to e.g. hooks.py doing _LazyObjectGetter(...).get_obj(), which is obviously not lazy at all
[09:24] <spiv> Also, the relevant code in _LazyObjectGetter doesn't appear to have direct unit tests, and it ought to.
[09:26] <vila> spiv: +1 :-D
[09:27] <maxb> vila: hmm. You could ask that list if they want release announcements. They may not, having other ways, like DEHS, to be advised of new upstream releases
[09:27] <vila> maxb: Ok, I'll do that
[09:27] <maxb> They may not even want 2.1.3 - the debian freeze is in effect
[09:29] <maxb> the freeze exception rules are basically "critical bugs only"
[09:32] <vila> maxb: ok, no critical ones for 2.1.3 (I think the 2.0 critical ones were part of 2.1.2)
[09:33] <vila> maxb: mail sent
[12:53] <vila> Do someone remember the trick to change 'Affects' from bzr (Ubuntu) the source package to our bzr ?
[13:00] <deryck> vila, hi.  unfortunately, you can't.  It's bug 80902.
[13:00] <ubot5`> Launchpad bug 80902 in Launchpad Bugs "Can't target bug report from project to distribution, or vice versa (affected: 7, heat: 67)" [Medium,Triaged] https://launchpad.net/bugs/80902
[13:06] <fullermd> vila: EWRONGMAILSUBJECT?   8-}
[13:06] <vila> NOOOO
[13:07] <vila> deryck: grumble, I'm sure spiv or someone had a workaround some months ago
[13:07] <bialix> vila: Indeed, wrong
[13:11] <fullermd> I blame that 'emacs' thing, personally.  I think it screws up your typing   :p
[13:14] <vila> fullermd: hehe, gnus, blame gnus ;-)
[13:16] <vila> losas are magicians... they fixed the review team for lp:bzr/2.3 even before I could report the problem...
[15:00] <jam> GaryvdM: you around?
[15:00] <GaryvdM> Hi jam.
[15:01] <jam> did someone start the ec2 instance for you?
[15:01] <jam> I logged on and it was already running
[15:01] <jam> maybe we just forgot to shut it down again?
[15:01] <GaryvdM> I'm here, but I've not yet started due to work.
[15:01] <GaryvdM> jam: I did not ask anyone other than you.
[15:01] <jam> GaryvdM: I was worried you'd say that
[15:02] <GaryvdM> I saw that it was up.
[15:02] <jam> I'm updating the pyqt now
[15:02] <GaryvdM> jam: Thanks
[15:03] <jam> you only need the new PyQT for 2.6, right?
[15:03] <jam> any idea when we can use the latest again?
[15:03] <GaryvdM> jam: When they fix a bug. I'll find the url for the bug for you.
[15:04] <jam> Seems weird that the older one would have 4.6 and then we went to 4.7, but now downgrading all the way to 4.5
[15:05] <GaryvdM> qbzr bug: https://bugs.edge.launchpad.net/qbzr/+bug/632501
[15:05] <ubot5`> Launchpad bug 632501 in QBzr "[win32] Subwindows only paint after a keyboard/mouse event. (affected: 1, heat: 10)" [Critical,Confirmed]
[15:05] <jam> vila: enjoying the multi-release management?
[15:05] <jam>  /thank for not making me do it :)
[15:05] <GaryvdM> jam: qt bug: http://bugreports.qt.nokia.com/browse/QTBUG-12721
[15:05] <vila> jam: hehe, yeah, not so many typos so far :)
[15:06] <vila> jam: you greatly deserved a break ;)
[15:06] <GaryvdM> jam: Good question. - What pyqt versions do you have?
[15:06]  * GaryvdM checks what versions I've got.
[15:07] <jam> GaryvdM: I seem to have the source for 4.5.4, but no installer. I probably deleted it a while back to save space
[15:08] <vila> jam: did you see https://code.edge.launchpad.net/~vila/bzr/integration/+merge/36012 ?
[15:08] <vila> jam: aren't you amazed about all those bugs I just fixed by updating NEWS....
[15:09] <jam> vila: :)
[15:09] <jam> that is what, all of 2.2 into 2.3 ?
[15:09] <vila> jam: aaaah, just understood, that's all the bug that I fixed but merged locally in my integration branch...
[15:09] <vila> jam: that's the first time I use it for proposal on lp, so it probably freaks out a bit
[15:10] <jam> vila: right, its all the bugs that have been associated with your integration branch over time
[15:10] <jam> poolie had a comment a while back that it is misleading
[15:10] <jam> since he re-uses 'doc' and 'trivial' a lot
[15:10] <vila> ok, thanks
[15:11] <jam> GaryvdM: PyQt is installed, let me know if you need anything else
[15:11] <vila> jam: I was vaguely worried but I know my merge was clean so I suspected lp rather than bzr or me :)
[15:11] <jam> GaryvdM: are you going to use the old build script for the old releases? (2.0, etc)
[15:12] <jam> vila: I thought it could have been all the --fixes tags in 2.2 merging into 2.3, but as you say, that should include more code changes, and you only have NEWS changes
[15:12] <jam> a lot of bug typos, though :)
[15:13] <vila> jam: yeah, but collected from 2.[012], there should be only *new* typos from now on ;)
[15:13] <jam> I thought I caught the 2.2 ones. but I intentionally didn't run the 'find bugs' script on anything else
[15:13] <vila> jam: I also shake a lot of series and milestones on lp, so keep an eye open for errors (Thanks in advance ;)
[15:14] <jam> btw, I'm not particularly happy with the workflow of pushing up things to the review queue that isn't meant to be reviewed. How do you feel?
[15:14] <jam> (like prepare-2.3b1)
[15:14] <jam> (I like knowing something is going on, but 3-emails telling me "ignore this, it is just housekeeping" bothers me)
[15:14] <jam> though if LP doesn't start letting me email back, I may stop reviewing via email
[15:15] <vila> well, I thought that for the lp:/bzr/2.[0123] it was worth using mps so I don't have to tell people: hey, heads-up, seen that ?
[15:15] <GaryvdM> Hi vila
[15:15] <vila> GaryvdM: hey !
[15:16] <jam> vila: I would like to get 1 email, the problem is that it is 3-5
[15:16] <GaryvdM> jam: Thanks
[15:16] <jam> and it is in the "hey you really need to look at this" folder
[15:16] <vila> jam: you file a bug on lp for that ?
[15:16] <jam> vila: for not being able to send email, yes
[15:16] <vila> jam: asking for the same aggregation that the bugs do ?
[15:16] <jam> with some response from rockstar telling me it was a foundations bug, and nothing from them
[15:16] <GaryvdM> jam: Yes - as far as I'm aware, the Ian's scripts don't work for older than 2.2, so yes.
[15:16] <vila> jam: no to get a single mail instead of 3
[15:17] <vila> jam: :-/
[15:17] <GaryvdM> jam: I've never run the old scripts, so I might ask for some help.
[15:17] <GaryvdM> jam: But 2.2.1 will be priority.
[15:17] <vila> GaryvdM: +1 for 2.2.1 :)
[15:18] <vila> GaryvdM: +0.8 for 2.3b1 so bialix can test it :-p
[15:19] <jam> to be fair, it was probably the end of the week
[15:19] <jam> but I don't know the name of a person on foundations so I can bug them
[15:19] <jam> I guess I could go look :)
[15:20] <GaryvdM> jam: I think that there was no pyqt 4.6 binary for python 2.6, and that's why we have to go back to 4.5 :-(
[15:21] <jam> GaryvdM: right, probably not one for 2.6
[15:21] <jam> I have it for 2.5
[15:21] <jam> (well, we have it installed on desolation)
[15:21] <jam> but yeah, I remember there being version issues against various python releases
[15:22] <jam> I really wish the riverbank guys would keep old installers around
[15:30] <jam> vila: I haven't looked through any other changes, but I'll note that sometimes a bug # gets put in NEWS because of a partial fix, which shouldn't actually mark the bug Fix Released entirely. Did you check any of that?
[15:30] <jam> or did you just mark them all released?
[15:31] <vila> jam: indeed, that's the problem I mentioned to poolie this morning (mine),
[15:31] <jam> vila: k. I did a lot of that triage in the 2.2.0 release
[15:31] <jam> some of which is "we should try to have more focused bugs"
[15:31] <vila> jam: no I didn't mark them fix released so they still show up in check-newsbugs.py output but this outlines a problem
[15:31] <vila> exactly
[15:32] <jam> vila: why did you add the global "fix_released = False" check?
[15:32] <vila> I think the rule should be: if you can't mark the bug fix released, crete a new one, more focused and mention it in NEWS and in the bug it partially addresses
[15:32] <jam> are you saying "if any task says that fix is released, that is good enough" ?
[15:32] <jam> and the comment is about cross-version issues ?
[15:33] <jam> (2.0 says, In Progress, but 2.1 says Fix Released ?)
[15:33] <jam> if you really want to do that, I think the check needs to come after the loop
[15:33] <jam> since otherwise 2.0 will say "hey not in sync" but 2.2 won't if 2.0 says fixed
[15:34] <vila> I think it was... a different case ;)
[15:34] <vila> let me try to find it back
[15:35] <vila> oh, but regarding the problem above, there is still the problem that a bug may be re-opened...
[15:36] <jam> vila: sure
[15:36] <jam> also, why did you assign me to bug #343218?
[15:36] <ubot5`> Launchpad bug 343218 in Gentoo Overlay for Bazaar "export could take unmodified files from wt rather than repository (affected: 0, heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/343218
[15:36] <vila> oh right, so the case is that if you don't summarize fix_released, the script whines as long as it finds *one* task still not fixed released and I was encountering too many false positives
[15:36] <jam> I did do the work to make it better about grabbing content all-at-once
[15:37] <jam> vila: I understand your point about summarizing, my point is that there is still an ordering issue
[15:37] <jam> if 2.0 is Fix Released, but 2.2 isn't, then you'll get nothing, but if 2.2 is Fix Released, and 2.0 isn't, you'll get nothing
[15:37] <jam> sorry, last form, you'll get chatter
[15:37] <jam> because it will see the 2.0 status before it sees the 2.2 status
[15:38] <vila> in addition there are bugs where we just can't set the status (when the task is against bzr (Ubuntu) for example)
[15:39] <vila> so it's not perfect, but the idea is that the RM will have already a good overview of what bugs have been fixed and which ones are in progress,
[15:40] <vila> the script helps to track *progress* while fixing NEWS
[15:40] <jam> vila: I can tell you when I was an RM, I didn't have a great handle on the 50 bugs that were all fixed :)
[15:40] <vila> I was tempted to add a blacklist for the bug still in progress while fixed...
[15:40] <hallyn> i'm apparently not doing 'merge' right.  if i want to do a merge such that histroy is maintained, does 'merge -rRN-1..Rn ~/origtree' not suffice?
[15:40] <vila> well, I mean having seen the bug page at least once :)
[15:41] <jam> hallyn: you're doing a cherrypick, which we won't remember history (because you are explicitly asking us to *omit* history by specifying a start rev)
[15:41] <jam> bzr merge -r Rn will work
[15:42] <GaryvdM> hallyn: So the history of the branch that you merge into is maintained, so i
[15:42] <GaryvdM> Ah - sorry - please ignore that.
[15:42] <hallyn> jam: and that merge will still only take the last commit?
[15:42] <vila> jam: right, so the comment points to bug #416732, without the summary, it pops up
[15:42] <hallyn> GaryvdM: thanks though :)
[15:42] <ubot5`> Launchpad bug 416732 in Bazaar 2.0 "check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch (affected: 3, heat: 0)" [Critical,Fix released] https://launchpad.net/bugs/416732
[15:43] <hallyn> jam: ok, thanks, i'll try that again.  i forget why i started specifying ranges
[15:44] <vila> jam: may be the solution is to recognize a config variable whose value is a list of black-listed bugs :)
[15:45] <jam> vila: I think hard-coding it into the script is appropriate for a script sitting in bzr's source tree
[15:45] <jam> IMO
[15:46] <jam> vila: also, I'm not sure why we can't change the Invalid to Fix Released on that particular bug
[15:47] <Glenjamin> hallyn: "bzr merge -r Rn" will give you all revisions up to n which you don't have, which might be subtly different
[15:47] <vila> jam: we can, but my comment will become obsolete
[15:47]  * vila ducks
[15:48] <jam> vila: note that Invalid should probably be considered a "I don't care about this bug anymore" similar to Fix Released. ...
[15:48] <hallyn> Glenjamin: yeah, that's not safe for me
[15:48] <jam> though why would we be fixing an invalid bug
[15:50] <vila> jam: Added this discussion on the mp, feel free to review and vote now ;-P
[15:50]  * vila back to release tasks
[15:53] <Glenjamin> hallyn: i'm not sure you can directly do what you're after then
[15:53] <jam> vila: I did vote already
[15:54] <jam> hallyn: if you really want to reject all other changes, you can do "bzr merge -r N-1; bzr revert .; bzr commit -m "reject old changes"; bzr merge -r N; bzr commit -m "bring in the new change"
[15:54] <jam> note that the '.' is significant, since it reverts the file content, without reverting the pending merge
[15:55] <Glenjamin> can I pull changes from one tree's shelf to another, or is apply/merge --unci going to be simpler?
[15:55] <Glenjamin> jam: i was under the impression that revert doesn't forget merges unless you explicitly tell it to?
[15:56] <Glenjamin> i'm fairly sure i've done revert --no-backup and still had the merges pending.
[15:56] <hallyn> jam: Glenjamin: ok, thanks.  I guess I'll just keep adding my own commit msgs for nwo
[15:56] <vila> jam: weird, damn lp should DWIM-refresh :)
[15:57] <vila> jam: thanks !
[15:57] <jam> Glenjamin: 'bzr revert' with no arguments reverts everything, including pending merges, etc
[15:58] <jam> Glenjamin: you can copy the shelf around and it should work (as long as you are still in the same shared repo)
[15:58] <jam> however, --uncommitted is probably more straightforward
[16:06] <Glenjamin> jam: revert with no args, or revert with no path?
[16:06] <jam> Glenjamin: no path (no positional arguments, as opposed to -- style "options")
[16:09] <Glenjamin> is there a concept similar to looms/shelf where I can move changesets around branches. Basically bugfixes that I dont want a full branch for.
[16:12] <jam> Glenjamin: why not a full branch?
[16:12] <jam> (with no tree in a shared repo, branches should be very cheap)
[16:15] <Glenjamin> i do have a tree
[16:15] <Glenjamin> oh right, treeless branch
[16:15] <Glenjamin> as patch storage
[16:15] <Glenjamin> that'd work
[16:28] <Glenjamin> hrm, I don't think that'll work actually - how do i get the changeset into the treeless branch?
[16:28] <Glenjamin> i suppose i can uncommit actually
[18:15] <GaryvdM> Preliminary build of 2.2.1: http://dl.dropbox.com/u/4494367/bzr-2.2.1~a-setup.exe
[18:15] <GaryvdM> But https://bugs.edge.launchpad.net/tortoisebzr/+bug/641557 still not fixed :-(
[18:15] <ubot5`> Launchpad bug 641557 in TortoiseBZR "error while trying to run command via context menu (affected: 2, heat: 12)" [Critical,Fix committed]
[18:21] <git__> can one export a repository based on time?
[18:25] <GaryvdM> git__: I think the term we would use it to export a tree: bzr export -r date:2006-08-14,17:10:14
[18:25] <GaryvdM> or bzr export -r date:yesterday
[18:25] <GaryvdM> see bzr help revisionspec
[18:27] <GaryvdM> note that export is for exporting an archive (e.g. .tar) of a tree. If you want to work with the files, you should rather bzr branch FROM TO -r date:...
[18:27] <GaryvdM> git__ ^
[18:28] <git__> thanks GaryvdM !
[18:28] <GaryvdM> it's a Pleasure.
[18:51] <git__> seems like bzr is not able to handle filenames : and ? in Windows
[18:51] <git__> i did a "bzr clone bzr://192.168.0.109/project"
[18:55] <jelmer> vila: hi
[19:04] <luke-jr> git__: rather, Windows isn't able to handle them
[19:06] <git__> :)
[19:06] <git__> what to do in this situation?  Have a pre-script to convert : and ? to _ ?
[19:06] <luke-jr> ...
[19:07] <luke-jr> just don't create files with those names?
[20:47] <awilkins> Ok.... working off an SVN branch. The person doing branches is an idiot and has made a branch where the first revision consists of all the files being deleted and replaced simultaneously. This does not merge well. Any suggestions for fixing (or at least merging cleanly)?
[20:52] <jelmer> awilkins: not really, even svn itself would have issues with that I think
[20:52] <awilkins> jelmer, Hrmmph. I have to get this merged somehow
[20:53] <awilkins> Or at least recommend how to do it to someone if I am to remain sane.
[20:53] <awilkins> 1816 content conflicts just trying the vanilla way :-(
[20:54] <awilkins> I suppose a kind of rewrite omitting the "evil revision" and applying the changesets as patch/revisions would work...
[20:54] <jelmer> awilkins: you should be able to revert his changes... but I guess that's not really what you're looking for?
[20:54] <awilkins> jelmer, there are about a hundred big revisions after this one
[20:55] <awilkins> If I revert it, won't I just get the same content conflicts?
[20:55] <awilkins> I'm trying git in desperation :-)
[20:55] <awilkins> That shouldn't be fooled by the files being "deleted" and then "added" hopefully
[20:55] <awilkins> Since if they are unchanged they will be the same objects
[20:55] <jelmer> git might be able to deal with it better since it works with content rather than files
[20:57] <awilkins> At least I may be able to get a merge pushed from it and then go back to working with Bazaar... or I may defect (I need to understand git better)
[20:57] <awilkins> This project itself is supposed to be a version controlled object database, alas, the guy writing it doesn't really understand version control
[20:58] <awilkins> I was thinking of trying to superimpose the git object model on top of it (it's in a K/V store rather than a RDBMS)
[20:58] <awilkins> Adding git tree/commit/blob objects to the mixture, construct an "index" of live objects by walking the tree objects
[22:17] <GaryvdM> Another TDD question: If I need to test a bit of code that changes a state tracker, should I assert on the state after the change, or should I assert on the output of whatever uses the state
[22:17] <GaryvdM> Ah - Let me get an actual example..
[22:20] <GaryvdM> In this test: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/annotate/head%3A/lib/tests/test_loggraphprovider.py#L226
[22:20] <lifeless> GaryvdM: you can assert on the state, or on the behaviour
[22:20] <lifeless> or on both
[22:20] <lifeless> depending on what layer you want to test.
[22:21] <GaryvdM> Ok
[22:21] <GaryvdM> In the above test, You can see I have a state, which I change in the middle of the test with state.collapse_expand_rev
[22:22] <GaryvdM> I need to write some more tests for state.collapse_expand_rev.
[22:22] <GaryvdM> So do I call state.collapse_expand_rev, and assert on the fields of state?
[22:22] <GaryvdM> I guess that is the layer that I want to test.
[22:23] <GaryvdM> but I the data structure of state is not important.
[22:25] <GaryvdM> Ok - I think I'll check the fields of state, and the results of it filter, but not a full compute_graph_lines
[22:25] <GaryvdM> Thanks lifeless