[01:28] <igc> morning
[01:55] <poolie> spiv, hi
[01:56] <poolie> igc, spiv, so in looking at the codebrowse stats it's interesting that the tags file is very hot
[01:56] <poolie> we may be accessing it too much over plain http
[01:57] <spiv> Huh, that is interesting.
[01:58] <spiv> Separately, I've noticed the get_tags_bytes RPC sometimes gets called more than is strictly necessary, perhaps due to the same root cause.
[01:59] <poolie> probably
[01:59] <poolie> while i was at the hospital cafe the other day i started adding the test-factory concept
[01:59] <poolie> i might call it test subjects to avoid touching any sore points about lp test factories
[03:15] <luke-jr> jelmer: my bzr-svn problem seems to be rooted in it deciding old-old paths are not branches
[03:15] <luke-jr> is it possible to tell it *tags* are tags and anything else is a branch? :/
[03:17] <mwhudson> luke-jr: you can set up a custom layout in ~/.bazaar/subversion.conf
[03:18] <luke-jr> mwhudson: bzr-svn doesn't like it
[03:18] <luke-jr> branches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*
[03:18] <luke-jr> tags = armagetronad/tags/*/armagetronad;armagetron/tags/*;armagetronad/tags/*;armagetronad/armagetronad/tags/*
[03:19] <mwhudson> ah i see you're ahead of me then :-)
[03:34] <lifeless> poolie: so what are you and igc hacking on ?
[03:34] <lifeless> poolie: re test-factories, I wish you could explain better what you mean there.
[03:41] <igc> lifeless: a few things ... poolie is helping me get lp running in a chroot
[03:42] <lifeless> igc: I found a VM was much easier
[03:42] <lifeless> FWIW
[03:42] <igc> lifeless: and we're hoping to clean out the loggerhead merge queue as well
[03:42] <poolie> lifeless: there was a thread from about september last year
[03:42] <poolie> 'rfc testfactory' or something like that
[03:42] <lifeless> poolie: yes, I remember that thread
[03:43] <poolie> basically i was going to get around to doing the consensus position from that
[03:43] <lifeless> ah, I didn't remember a consensus other than 'caring about test quality matters'
[03:43] <poolie> which was to make setup of test data "shorter, standardized and declarative"
[03:43] <poolie> i think that was aaron's description
[03:44] <igc> lifeless: and poolie's explaining hydrazine and the nice work you're doing on improving lp-pqm integration - sounds really promising IMO
[03:45] <lifeless> igc: its fixes some process bugs for us
[03:45] <lifeless> should let us add more committers more easily
[03:45] <lifeless> and makes it easier to migrate to tarmac if/when we do that
[03:46] <igc> lifeless: right. I'd like to leverage all the above to make it easier to land stuff from Explorer
[03:46] <poolie> lifeless: where does the failure message go to?
[03:46] <lifeless> poolie: subunit-filter -> lp merge proposal
[03:47] <lifeless> poolie: bugs filed about getting binary safe attachments on mp's
[03:47] <igc> lifeless: IIUIC, if a user can toggle the status of a MP from inside Explorer via launchpadlib, then your magic will take care of landing the associated branch from there?
[03:47] <poolie> k
[03:47] <poolie> igc, yes, it should
[03:48] <poolie> and it should be trivial to set it
[03:48] <poolie> finding the right mp may be slightly harder
[03:49] <igc> poolie: for a given repository, I'll simply list the MPs for the matching lp project in a panel
[03:49] <igc> with some action buttons next to each one say
[03:51] <lifeless> igc: yes
[03:51] <lifeless> finding the right mp is pretty easy.
[03:51] <lifeless> you can crib from pqm/queue/lp.py - take you ~ 5 minutes
[03:51] <lifeless> listing all the mp's makes sense though, to let them choose the branch
[03:52] <lifeless> igc: one [important] thing is to show the diff, because NEWS in particular will often require a manual fixup before PQM submission, to move entries to the right stanza
[03:53] <igc> lifeless: good point
[03:54] <lifeless> this is a significant sticking point on using MP's to control things
[03:54] <lifeless> we kindof end up having to:
[03:55] <lifeless> make a new branch
[03:55] <lifeless> fixup
[03:55] <lifeless> submit that as an mp
[03:55] <lifeless> self approve as 'fixup for xxx'
[03:55] <lifeless> queue
[03:56] <igc> lifeless: so having an integration branch remains a part of the workflow puzzle
[03:56] <lifeless> igc: when releases happen, or things sit for a while, yes.
[04:13]  * igc lunch
[04:14] <lifeless> spiv: btw your branch is pretty certain to be erroring, its just blowing up in the exception handler handler
[04:14] <lifeless> spiv: I think its fixed [reporting] now - this run should do better
[04:25] <mkanat> mwhudson: Hey hey. Any chance of getting the logs that I wanted?
[04:26] <mwhudson> mkanat: do you have the times to hand?
[04:28] <mkanat> mwhudson: They're in the attachment, I could go find them.
[04:28] <mwhudson> i guess i can too
[04:34] <mwhudson> yay i think the times in the attachment are in NZST
[04:35] <lifeless> rot12 is fun ? :)
[04:38] <mwhudson> ah, actually not
[04:40] <luke-jr> hmm, one-liner patch to svn-bzr likely to get in as a bugfix? :p
[04:42] <luke-jr> lp:~luke-jr/bzr-svn/bzr-svn-longest-branch-path
[04:42] <lifeless> luke-jr: submit that via launchpad ;)
[04:45] <luke-jr> any way to go back and add parent revids to revisions?
[04:45] <luke-jr> I can add revprops on the svn end if needed, I think
[04:50] <lifeless> http://bouillon.math.usu.ru/articles/ctre.pdf
[04:50] <lifeless> ^- rev ctrl geek alert
[04:50] <lifeless> luke-jr: in general, no.
[04:50] <luke-jr> :/
[04:50] <lifeless> you could rebase/rewrite
[04:51] <mwhudson> mkanat: i commented on the bug report
[04:51] <mkanat> mwhudson: Thanks.
[04:52] <mwhudson> mkanat: i hope it's useful
[04:57] <luke-jr> lifeless: I don't want to rebase or write anything
[04:57] <luke-jr> just add missing metadata
[04:57] <lifeless> luke-jr: so bzr revisions are immutable
[05:18] <luke-jr> lifeless: why?
[05:18] <luke-jr> I'm going to have to change all the file-ids sometime too
[05:19] <lifeless> why?
[06:06] <poolie> spiv, thanks for the tribunal mp
[06:06] <poolie> how did it work aside from that?
[06:13] <luke-jr> lifeless: to maintain compatibility with existing branches if possible
[06:14] <lifeless> luke-jr: but existing branches will have the current file ids
[06:15] <lifeless> luke-jr: so I don't follow
[06:18] <luke-jr> lifeless: the existing branches are all based on a bzr-svn screwup
[06:18] <luke-jr> I am trying to recreate our Bazaar HEADs properly
[06:19] <lifeless> ah
[06:19] <luke-jr> so we can actually merge between stable and trunk
[06:19] <luke-jr> and useful things like that
[06:20] <luke-jr> right now, the Bazaar HEADs start revision 1 at the import to Subversion
[06:20] <luke-jr> rather than at the original import into CVS
[06:21] <luke-jr> also, side note: I will need to ensure I can repeat this again later, since Bazaar STILL can't mirror Subversion losslessly at the moment :/
[06:21] <luke-jr> so a third import will be needed when Bazaar *can* losslessly contain the history
[06:22] <spiv> poolie: it's pretty slow when fed a full test run from bzr
[06:22] <spiv> poolie: I haven't got to the point of profiling
[06:24] <spiv> poolie: I've got some other changes in https://code.edge.launchpad.net/~spiv/tribunal/experimental that I'm less certain about, but made it a little nicer for me
[06:24] <poolie> yeah it does seem a bit slow
[06:24] <poolie> or like it gets stuck
[06:24] <spiv> poolie: io_add_watch seems to basically be a wrapper around poll(2) on an fd, and so feeding it a file doesn't really work well because they always report as ready for reading
[06:25] <poolie> for me it works to give it a plain file but not a pipe atm
[06:25] <spiv> poolie: So I ripped that out (although it might be more appropriate for reading from a pipe?), and also used add_idle or something instead of timeout_add(1, ...)
[06:26] <poolie> folding together "neither success nor failure" probably makes sense
[06:26] <spiv> poolie: and borrowed some progress code from subunit2gtk to give more info in the statusbar
[06:26] <poolie> i see
[06:26] <poolie> that looks nice
[06:26] <spiv> Oh, and changed it to filter xfails with skips
[06:27] <poolie> right that's what i meant about folding them together
[06:27] <spiv> And added a separate filter for unknowns (which in my use were just flickering on/off as tests loaded)
[06:27] <poolie> mm
[06:27] <spiv> Although I don't think that's a great change.
[06:27] <poolie> that actually needs to be handled a different way i think
[06:27] <spiv> But it did prove I knew how the ui.glade file worked :)
[06:28] <poolie> i mean if we're really getting unknown test results that's one thing
[06:28]  * luke-jr mutters.
[06:28] <poolie> but the case of a test just being in progress is different
[06:28] <spiv> It's really "incomplete" in this case, rather than "unknown"
[06:28] <spiv> Right.
[06:28] <poolie> you know there is a gui for glade? :)
[06:28] <spiv> I do :)
[06:28] <poolie> i guess i'd be surprised but happy if the input code can be as simple as you have it
[06:28] <spiv> But it seemed quicker & easier to do this change via XML hacking, and I think I was right :)
[06:29] <spiv> I'm not sure that the input code as I have it will cope well with a pipe that hasn't got the full stream ready to read yet.
[06:31] <spiv> One effect of removing the timeout_add calls is that Ctrl-C on the console now works as expected.
[06:50] <lifeless> poolie: in case it wasn't clear, its safe to merge: approve in email/the web ui
[06:50] <lifeless> poolie: pqm looks for merge: queue, not merge: approve
[06:50] <poolie> that's what i understood now, but i think this is not clear to everybody
[06:51] <poolie> or whether that's going to start happening in the future
[06:51] <lifeless> poolie: I'm going to update the merge docs once the glitches are gone
[06:51] <lifeless> poolie: for now I want to keep email as the 'official' way to submit stuff
[06:51] <poolie> ok
[06:51] <poolie> that makes sense
[06:56] <lifeless> poolie: so https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
[06:58] <lifeless> poolie: looking at it, I made it in progress because vila had decided to hand the writing of the tests back to INADA; I was following suit but setting the metadata
[07:23] <vila> hi all !
[07:23] <fullermd> Eek!
[07:23]  * fullermd hides.
[07:25] <poolie> hi vila
[07:29] <poolie> lifeless, vila, so basically i think if someone has half a patch and doesn't seem to be getting the tests (or cleanups or whatever) finished
[07:29] <poolie> we should actively help them
[07:29] <poolie> if necessary by writing the tests
[07:30] <lifeless> I think we should only do that after discussing with them unless we particularly want the patch
[07:30] <vila> poolie: sure, I will look at it today (and to brian's append_revisions_only one)
[07:31] <lifeless> poolie: particularly as you seem to mean this to apply to non-staff contributions [or something, I'm unclear what the heuristic you use is]
[07:33] <vila> lifeless: you seem to be patch piloting quite well so far, do you intend to make it official ? :)
[07:33] <lifeless> vila: I'm not patch piloting; if I was I'd be implementing stuff as needed; thats part of the pp definition atm
[07:34] <vila> was worth a try :)
[07:35] <lifeless> vila: I'd be happy to if I wasn't moving house this weekend
[07:36] <vila> lifeless: thanks for the cleanup anyway !
[07:36] <vila> lifeless: tada ! Happy moving !
[07:36] <lifeless> parthm: we could use tempfile.mkstemp to make .bzr.log perhaps
[07:36] <igc> hi vila!
[07:37] <vila> lifeless: I would have help if I wasn't that far :0)
[07:37] <poolie> lifeless: if somebody's done some work on a patch, and it has value, and we think they won't finish it off themselves, we should finish it
[07:38] <poolie> you can get an idea from someone's history of whether they can/will finish it
[07:38] <vila> poolie: fully apply to brian's one, I'm a bit less comfortable with naoki's one but I think it's still a step in the right direction
[07:38] <poolie> fully apply?
[07:39] <lifeless> poolie: I kindof agree, but I think your dials are overly sensitive, or something.
[07:39] <vila> poolie: your comment " it has value"
[07:39] <parthm> lifeless: i thought of that earlier. rename is guaranteed to work on posix but not on windows (IIRC it errors on windows) so the update from martin_gz seemed good to me.
[07:39] <vila> fully applies ?
[07:39] <poolie> i see what you mean
[07:39] <lifeless> parthm: oh, right, we can't specify the full name. Ignore my suggestion :)
[07:40] <poolie> yes, we have a difference of opinion as to what's worth doing
[07:40] <vila> lifeless: Are there updates to your feed-pqm branch ? What is the consensus around it ?
[07:42] <lifeless> poolie: I want to help folk over a hump they can't get over when any of a few conditions are true: they are likely to come back and do more; they are struggling and pointers won't be enough; we would be working on teh patch anyhow
[07:43] <parthm> lifeless: thanks for the review of bug #529930 mp. i have updated the testcase to use user_encoding.
[07:44]  * parthm is new to unicode but dislikes unicode errors
[07:45] <poolie> join the club
[07:48] <lifeless> that was incredibly bad reception - or transmission, can't tell
[07:48] <lifeless> I had 3 bars
[07:48] <poolie> srsly
[07:49] <lifeless> yes, except more like
[07:49] <lifeless> ssy
[07:54] <lifeless> poolie: I'm thinking of either: changing the behaviour of pull --remember when there is a locations.conf, to remove configuration from locations.conf if it would override the --remember, or to have branch.conf win for local branches
[07:54] <lifeless> ditto push --remember
[07:55] <vila> lifeless, poolie : Where are we with https://code.edge.launchpad.net/~lifeless/hydrazine/cron/+merge/23213 ?
[07:55] <poolie> sounds good
[07:55] <lifeless> vila: you can use it to submit things to pqm
[07:55] <vila> lifeless: I now I can, I'd like to know if I *should* :-)
[07:55] <poolie> heh, the last commit on the cron branch is "remove cron mode?"
[07:55] <vila> s/now/know/
[07:56] <lifeless> vila: sure; its merging robustly, but it has issues showing errors
[07:56] <lifeless> vila: debugging is a long winded thing (need a LP instance to talk to yada yada), so its high latency, even though its not high-staff-time
[07:56] <poolie> issues meaning it can't show them at all? :)
[07:56] <lifeless> vila: once the quirks are gone, I'm thinking to put the changes into bzrlib.plugins.launchpad
[07:57] <lifeless> vila: and have hydrazine call into that on a per-branch basis
[07:57] <vila> Is it the 44M mail spiv was referring to ?
[07:57] <lifeless> poolie: some of the time :(
[07:57] <lifeless> vila: no
[07:57] <vila> lifeless: that would be lovely for my use case :)
[07:57] <lifeless> vila: thats subunit
[07:57] <poolie> vila: it gives you something like "IndexError: None"
[07:58] <lifeless> poolie: thats on success ;)
[07:58] <lifeless> poolie: but is, I think, fixed.
[07:58] <poolie> if that's success i'd hate to see failure :)
[07:58] <poolie> :)
[07:58] <lifeless> poolie: indeed. Failure was spmdo tail pqm.log
[07:58] <vila> lifeless: I had failures last week and never got any mail, we tried to diagnose it with Chex, but never concluded, in the end I fixed the problem and sucessfully merged
[07:58] <lifeless> which is very suboptimal
[07:58] <lifeless> vila: that would be the 44M email
[07:59] <vila> lifeless: do you which server is blocking that ?
[07:59] <lifeless> vila: thats fixed, but the fix isn't robust yet; have just had spm rollout a pqm to gather the output and let us analyze for the reason of teh failure
[07:59] <parthm> does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
[07:59] <vila> lifeless: ok cool
[07:59] <lifeless> poolie: yes, --cron became obsolete with pqm.queue.lp
[08:00] <poolie> lifeless: so atm i think i should merge that branch but give you a choice of two commands
[08:00] <poolie> 'queue by email' and 'queue in launchpad'
[08:00] <poolie> since you do in fact have these two options now
[08:00] <spm> you should have a third : "queue by sheer awesomeness"
[08:01] <lifeless> poolie: ok, I can reinstate a separate command, but I'm not really game to try and eliminate all the cruft
[08:01] <lifeless> poolie: by which I mean there will be duplicate code
[08:01] <vila> lifeless: mark it as deprecated :-P
[08:01] <vila> lifeless: and spam the users about the alternative
[08:02] <poolie> i'll try
[08:02] <lifeless> vila: no, thats not reasonable when we're still supporting email submission
[08:02] <poolie> two commands in one program seems better than two branches
[08:02] <lifeless> poolie: I know what I changed, I'm happy to do it
[08:02] <lifeless> poolie: it would be nice to have hydrazine look at the conflicts list too
[08:08] <lifeless> what I need is the self user id from launchpadlib
[08:10] <parthm> poolie: does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
[08:13] <poolie> lifeless: so in short, in case we don't catch up
[08:13] <poolie> i do want you to adjust that knob upwards
[08:13] <lifeless> poolie: hydrazine 'e' command added and pushed to the cron branch.
[08:14] <poolie> ok thanks
[08:14] <lifeless> poolie: I want to discuss that with you; I'm pretty sure we will not be doing as best we can for the project by doing that
[08:15] <poolie> happy to discuss it but please also just do it for now
[08:16] <vila> lifeless: lifeless missing ':' line 182
[08:17] <lifeless> vila: bah, thanks
[08:17] <poolie> great, thanks
[08:18] <lifeless> vila: pushed
[08:20] <vila> lifeless: pulled
[08:55] <lifeless> jelmer: what should format.open(name='xxx') raise on a non-supporting colocated-things format ?
[09:17] <speakman> morning folks
[09:18] <james_w> lifeless: how did this bzr-builddeb change work???
[09:19] <james_w> I even think we've discussed this change before
[09:42] <lifeless> james_w: does it not work for you ?
[09:43] <lifeless> james_w: oh right, global scope commands. bah
[09:44] <lifeless> clearly I have '' in my path inappropriately
[09:57] <jelmer> lifeless: NoColocatedBranchSupport
[10:26] <lifeless> jelmer: and name!=None is thr right condition ?
[10:27] <lifeless> well, is not
[10:29] <MvG> lifeless: wrt bug #560030, what exactly are you proposing? Should we get all major distros to provide a bzr-bash-completion package before we drop stuff from the bzr main tree?
[10:30] <lifeless> MvG: debian and redhat certainly
[10:30] <jelmer> lifeless: yeah
[10:30] <lifeless> MvG: not necessarily wait for them to be done, but have the maintainer ack and be prepared
[10:31] <MvG> lifeless: Do you want to contact them? If I do, it might seem like I'd simply trying to maneuver for a larger audience for my plugin. If you say that's the future, they are more likely to take it serious.
[10:32] <lifeless> MvG: the bug and review feedback are pretty clear
[10:32] <lifeless> MvG: I think they will take you seriously ;)
[10:32] <MvG> OK, got a point there.
[10:35] <lifeless> I'd just say something like
[10:36] <lifeless> 'hi, this is a heads up, we're about to merge a branch deleting xxx, there are replacement, better, scripts at yyyy, we wanted to make sure that this is known now, rather than at the last minute'
[10:36] <MvG> Do you have contact addresses for maintainers of the RedHat package?
[10:36] <lifeless> he hangs out here :P
[10:36] <lifeless> don't remember the name offhand
[10:37] <james_w> abadger1999 will at least know who it is if it is no longer him
[10:39] <spiv> Ooh, I think my shiny new news_merge logic is working.  The prototype doesn't blow up in manual testing at least...
[10:39] <MvG> jelmer: How about Debian? Should I write to pkg-bazaar-maint@lists.alioth, or is it enough that you read the above?
[10:39] <lifeless> spiv: cool
[10:39] <lifeless> spiv: hey
[10:39] <lifeless> spiv: I have a further Commands cleanup issue
[10:39] <spiv> Time to write some proper automated tests for it, but right now it's dinner time :)
[10:39] <lifeless> spiv: subclasses  - super().
[10:39] <lifeless> spiv: food for thought.
[10:39] <spiv> Super-duper.
[10:40] <speakman> I've got yet another workflow question comming. Hold on. :-)
[10:40] <spiv> lifeless: I guess the current answer is "don't upcall"?
[10:40] <lifeless> spiv: Not entirely sausagefestfactory
[10:41] <MvG> By the way, I've got another merge request for which I'd like comments here: https://code.launchpad.net/~gagern/bzr/bug387117/+merge/23750 about ListOption(..., param_name=...) which is currently broken.
[10:41] <spiv> Anyway, food time.
[10:42] <spiv> lifeless: btw, the better-news-merge branch, while still rather messy, can read a template file from a configurable location (rather than using the hard-coded list).
[10:42] <lifeless> spiv: sounds nice
[10:42] <spiv> lifeless: as well as having a more capable parser
[10:43] <speakman> Me and my coworker are about to make a facelift to one of our application. The current stable version is in trunk, and we suppose all facelift work should be done in a separate branch of trunk. But how do we work together on this branch in best practice? Beside our own workstations we also have a bzr smart server set up on a dedicated server machine. Any recommendation how to proceed?
[10:44] <lifeless> speakman: just do it ?
[10:44] <MvG> speakman: I'd say create a branch off trunk on the smart server, and let contributors decide whether they want to check it out or branch from it.
[10:46] <jelmer> MvG: Sorry, I think I missed the context :-)
[10:46] <speakman> We're only two working on this, but we will be working with overlapping things i guess.
[10:47] <MvG> speakman: In terms of http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html you two either use the centralized approach (with or without local commits) or the decentralized with shared mainline. In both cases, mainline would be the facelift branch, not trunk.
[10:47] <MvG> jelmer: Bug #560030 plans dropping bash completion scripts, and lifeless wants distros made aware of this upcoming change up front.
[10:48] <speakman> So the preffered workflow in this scenarios is the centralized (SVN) type?
[10:48] <jelmer> lifeless: still around?
[10:49] <lifeless> very
[10:50] <MvG> speakman: Depends on your personal preference. In particular whether you want to resolve possible merge conflicts and share your changes at almost every commit, or whether you'd rather keep your stuff to yourself until you decide it's ready for sharing.
[10:52] <MvG> jelmer: So I'd still like to know whether the people maintaining bzr for debian are now sufficiently aware of the fact that bash completions are about to go, and that there is my bzr-bash-completion plugin as suggested and superior solution. If not, I'd write a mail about it.
[10:52] <speakman> I don't actually have any preference, and every time I just choose one workflow, I always hit issues one way or another :)
[10:53] <speakman> That's why I'm asking the pro's before starting the facelift project :)
[10:53] <lifeless> speakman: don't don't choose one workflow - use many :)
[10:53] <lifeless> speakman: seriously, different strokes for different issues
[10:53] <lifeless> speakman: clearly you want a facelift branch; make one, work on it.
[10:54] <MvG> speakman: In that case I assume that your edits overlap in a way that is bound to cause extra work unless you strictly serialize them. Might be an indication of bad code design or bad task assignments.
[10:54] <speakman> Earlier I think I've seen something where each user had their own branches on the smart server, like /srv/bzr/ourproject/mybranch and /srv/bzr/ourproject/coworkerbranch
[10:54] <lifeless> If you are getting lots of big conflicts, merge more often with each other (the ultimate example of that is per-commti)
[10:54] <speakman> lifeless: but we will be two working on the same "feature" :-/
[10:54] <lifeless> speakman: so ? I don't see why you feel that make a difference
[10:54] <MvG> lifeless: "don't choose one workflow" might apply to bzr usage in general, but for working on one specific task I'd prefer not to change workflow too often... :-P
[10:55] <speakman> MvG: You're hitting the spot; it's *very* bad code design, but the facelife project is the last resort for that codebase though :)
[10:56] <speakman> lifeless: but if we're supposed to merge often - then the checkout/centralized workflow is pretty much it?
[10:56] <MvG> speakman: If edits overlap so often, then as lifeless points out, you might want to merge for almost every commit, in which case the centralized svn-stype approach would indeed be best.
[10:56] <lifeless> speakman: the more often you merge, the smaller conflicts are; dial-up the number of merges you do to match the work you're doing.
[10:57] <speakman> I think the centralized workflow will be it then. Thanks :-)
[10:57] <speakman> And then - how "often" should one commit? Are there any rules of thumb?
[10:58] <lifeless> speakman: often
[10:58] <mathrick> speakman: merging doesn't necessarily imply a centralised workflow
[10:58] <mathrick> you can just cross-merge from each other's branch
[10:59] <lifeless> speakman: ifyou're using centralised to avoid conflicts, you want to be committing a lot, otherwise you're no different than just merging every now and then
[10:59] <mathrick> speakman: how many people will *not* be working on the facelift?
[10:59] <speakman> lifeless: ok, thanks alot!
[10:59] <speakman> mathrick: not working? :-)
[10:59] <lifeless> by a lot, I mean multiple times an hour
[10:59] <mathrick> yeah, how many developers are there who don't participate in the facelift?
[10:59] <speakman> mathrick: we're just two programmers, and both will be working on the facelift :)
[10:59] <mathrick> oh
[11:00] <mathrick> speakman: then you just do bzr branch stable facelift; bzr branch facelift facelift-speakman; bzr branch facelift facelift-coworker
[11:01] <jelmer> MvG, lifeless: I'm not exactly sure what's expected of me here
[11:01] <mathrick> and then facelift becomes your integration branch, with stable still being there in case you need it
[11:01] <jelmer> MvG, lifeless: Does removing this completion script cause shell completion to break for existing users?
[11:01] <lifeless> jelmer: a decision about what to do in debian when bzr drops its included completion scripts; ideally package up the rplacement.
[11:01] <lifeless> jelmer: it depends, how do we deploy them at the moment?
[11:02] <lifeless> like, do users have it on by default, or do they source it, or copy it, or ...
[11:02] <mathrick> lifeless: wouldn't making their personal branches bound to the main facelift branch be best for merging here? This way they'll always be sure to have a single codebase
[11:02] <MvG> bzr deploys them in contrib, debian places them in /etc/bash_completion.d/ , from there on I'm less than sure.
[11:03] <MvG> But I'd assume there is some kind of framework for selecting thise completion scripts you want to enable on a per-user basis.
[11:03] <lifeless> mathrick: doesn't really make any difference; regular merges are regular merges
[11:03] <mathrick> yeah, I mean just for code hygiene and not forgetting to push
[11:03] <lifeless> mathrick: whatever works for the individuals involved
[11:03] <lifeless> mathrick: I don't think there is a gold standard 'best' here
[11:03] <mathrick> lifeless: the decision about completions is usually global, you either enable it and then get all installed completions, or not and then you don't.
[11:03] <lifeless> jelmer: ^
[11:04] <mathrick> lifeless: fair enough
[11:04] <MvG> In that case I wonder why Debian installs BOTH bash completion scripts, bzr and bzr.simple... :-/
[11:04] <lifeless> jelmer: ideally we'd have replacement packaged and recommended: on by the bzr package
[11:04] <MvG> I don't have a Debian/Ubuntu at my fingertips just now, otherwise I'd investigate this more thoroughly.
[11:05] <mathrick> speakman: anyway, you can make your personal branches checkouts, this way every commit you do locally will be instantly mirrored on the integration branch. And ideally, you want to sit next to each other and inform clearly what you are about to commit and what you'll be working on next
[11:11] <speakman> mathrick: that's pretty much how it works practically. We're sitting next to each other, and due to the (lack of) code design we really need to work tight on this.
[11:12] <mathrick> right
[11:12] <speakman> final conclusion; bzr branch bzr://smartserver/ourproject/trunk bzr://smartserver/ourproject/facelift, and then "bzr checkout bzr://smartserver/ourproject/facelift" on each of our workstations.
[11:13] <speakman> Then go buy intercom :)
[11:13] <jelmer> MvG, lifeless: ok, thanks
[11:13] <mathrick> speakman: yup; you might also consider tagging the starting point of the facelift
[11:13] <jelmer> MvG, lifeless: I'll file a RFP when I do the next upload
[11:13] <MvG> jelmer: Please expand RFP.
[11:14] <lifeless> request for package
[11:14] <MvG> Thx.
[11:15] <MvG> Debian done, Ubuntu by inheritance hopefully done as well. RedHat maintainer still unknown. I haven't even found a redHat package database online, only one for Fedora. https://admin.fedoraproject.org/pkgdb/acls/name/bzr lists 3 users with commit privileges, one of them the owner.
[11:16] <jelmer> MvG: abadger1999 is (one of?) the Fedora maintainer
[11:16] <mathrick> MvG: I thought RH doesn't have a non-fedora package list anymore, given how RH is basically fedora + support + very long release cycle
[11:19] <lifeless> MvG: redhat is fedora as far as we're concerned
[11:21] <MvG> So we'll wait for abadger1999 to react.
[11:22] <MvG> In the meantime I'll go for lunch.
[11:29] <speakman> mathrick: hm... I don't get it - why tagging when working in a branch..?
[11:30] <mathrick> speakman: to have an easy reference to the starting point
[11:30] <mathrick> speakman: otherwise you'll have to remember the first revision you branched from
[11:31] <speakman> oh yes, you're absolutely right! thanks!
[11:32] <lifeless> mathrick: I don't get the tag either
[11:32] <lifeless> mathrick: whats it for ?
[11:32] <speakman> Hm looking at the commit history my coworker seems to have commited with wrong email address (login@machine). Is there any way to change that retrospectively?
[11:32] <mathrick> lifeless: seeing the full extent of what you've done for example
[11:32] <mathrick> speakman: no
[11:32] <speakman> ok :(
[11:32] <mathrick> other than fast-replay
[11:33] <mathrick> err, fast-import
[11:33] <mathrick> but it'll be a different repository then
[11:33] <lifeless> or rewrite (in principle)
[11:33] <speakman> ok, it's okey as is :)
[11:34] <speakman> about tagging; when working explicitly in the facelift branch you can easily see which commit was the first in the new feature branch. I guess?
[11:34] <mathrick> lifeless: in general I find having a clear idea of where I started useful. And if the trunk moves in the meantime (because of a critical bugfix say), you won't have any easy way to say "where I started"
[11:34] <lifeless> mathrick: well, bzr knows
[11:34] <mathrick> speakman: depends, how do you define "first in the feature branch"? Revisions don't belong to any branch, branches contain them
[11:34] <mathrick> lifeless: howso?
[11:34] <lifeless> mathrick: revisions in your branch not in trunk
[11:35] <mathrick> unless you backport / merge
[11:35] <speakman> About trunk changing - is "merging" considered default about "rebase" in bzr?
[11:35] <lifeless> mathrick: the topologically oldest of them, has a single parent, the starting point.
[11:35] <speakman> about/above
[11:35] <mathrick> lifeless: and how do you say that?
[11:36] <lifeless> mathrick: bzr missing --mine-only etc, I'm not sure there is a query for that rev at the moment
[11:39] <mathrick> lifeless: but that's potentially a moving target. Tags by definition aren't
[11:40] <mathrick> and they're easy to spell as revspecs too
[11:40] <lifeless> mathrick: sure, if you're happy great. I've just never ever needed it ;P
[11:41] <speakman> We all learn something each day :)
[11:56] <speakman> Each time I need to reach my smart server I have to type "bzr://servername.local/project/trunk" -- is there an easy way to make a alias, like "ss:project/trunk" (like launchpad "lp:") ?
[11:58] <lifeless> speakman: instal bzr-bookmarks
[11:59] <lifeless> vila: ping
[11:59] <lifeless> vila: do you remember, does WeaveMerger write BASE files now ?
[12:08] <lifeless> it does
[12:30] <vila> lifeless: sorry, had lunch
[12:30] <lifeless> vila: tsk, eating now. What next? Breathing?
[12:30] <vila> or sleeping :)
[12:47] <speakman> I currently did a merge from trunk into a feature branch. Now "bzr missing" tells me that the merge commit is missing in trunk. How will this show in history when the feature branch is finally merged into trunk?
[12:49] <lifeless> speakman: have a look at the bzr trunk log
[13:09] <speakman> lifeless: bzr trunk log..? the log of my trunk branch?
[13:10] <bialix> no, lp:bzr
[13:14] <millun> hi
[13:15] <millun> i am a noob. working on a project (colocated branch) and would like to create a copy of this project so i could have 2 repos and be working on both
[13:16] <speakman> lifeless: changeset 5153?
[13:18] <millun> i guess i could 'cp -R stuff' and then delete .bzr dir?
[13:19] <speakman> why not branch and work on both?
[13:19] <speakman> what more specifically are you trying to do?
[13:19] <MvG1> abadger1999: ping?
[13:20] <millun> speakman: just be able to separate 2 projects and then work on both without mixing anything
[13:21] <MvG> millun: Just because branches were made from a common ancestor doesn't mean you'll HAVE to mix anything in the future.
[13:21] <MvG> millun: And doing a branch now will preserve full history for both new projects, which should be a good thing to have
[13:22] <millun> ok
[14:36] <abadger1999> MvG: pong
[14:45] <MvG> abadger1999: you're maintaining the bzr package for Fedora, right?
[14:46] <abadger1999> abadger1999 == toshio in the Fedora pkgdb btw
[14:46] <abadger1999> MvG: I am comainaining it -- hno handles the day-to-day these days.
[14:46] <abadger1999> MvG: What's up?
[14:46] <MvG> abadger1999: In response to bug #560030 we're gonna drop the bash completion script, and suggest the bzr-bash-completion plugin as replacement.
[14:47] <MvG> So we'd like distros to provide a package for it, be ready for the time when the scripts disappear from the bzr source releases.
[14:47] <abadger1999> MvG: Okay.  No chance of getting that plugin into core?
[14:47] <MvG> Not up to me, I'm only developing the plugin and offering the off fix for inclusion.
[14:48] <MvG> I'd be happy to see it in core, but lifeless didn't exactly jump to that offer.
[14:48] <MvG> And I can think of a million places where bzr would be required but bash completion not, so it might make sense to keep things distinct.
[14:49] <abadger1999> Hmm... bzr-bash-completion doesn't need bash completion installed, though?  It just generates the script that would be used by bash completion?
[14:50] <MvG> abadger1999: Correct. but it does ship a lazy.sh that can be installed as bash completion script and generates the full completion function upon first invocation.
[14:50] <MvG> So that's file is what I'd suggest as a replacement, in cases where the plugin is installed.
[14:52] <abadger1999> Ah.  Okay, we'd drop that into place without making a hard requirement on bash-completion so it wouldn't matter if it was in bzr core.
[14:53] <MvG> abadger1999: I was a bit imprecise: the script assumes that the plugin is installed. It is intended for cases where the plugin is installed, but doesn't check if that actually is the case, but will fail noisily if it isn't.
[14:54] <abadger1999> MvG: <nod>  I'm talking -- if it was in Core, bzr still wouldn't need to suck in a bash completion package.
[14:55] <abadger1999> MvG: A few years ago poolie wasa interested in getting more plugins into core.
[14:55] <MvG> Agreed. So suggestion would be for bzr to suggest but not require bzr-bash-completion, and for bzr-bash-completion to suggest but not require bash-completion, and for bzr-bash-completion to install lazy.sh under a file name that was provided by bzr so far.
[14:56] <abadger1999> I ask this because there's only two of us packagers who are interested in bzr in Fedora... so additional packages kinda suck.
[14:56] <abadger1999> Which is why we don't have bisect, pipelines, or a lot of other bzr plugins packaged :-(
[14:57] <MvG> abadger1999: I understand, but my package shouldn't be too complicated: simple distutils from proper release tarball, and the lazy.sh file installed via custom install command copied from the bzr package spec.
[14:57] <MvG> And if there is anything I can do to make life easier for you downstream, let me know.
[14:59] <MvG> abadger1999: BTW, is hno occasionally here on irc as well, and if so, using what nick?
[14:59] <abadger1999> MvG: <nod>  Yeah... but maintaining packages is the problem... The front end load is fairly simple, when free time > 0: create new package from template, submit for review, have bzr comaintainer review, commit to package SCM, build and release.
[15:01] <abadger1999> MvG: The maintainance is the problem: When New upstream release || new Fedora release || bug reported: stop other work to work on issue (minimal for updating package, much more for fixing bugs); submit patches upstream, build new packages, push to all relevant Fedora branches.
[15:01] <abadger1999> MvG: his nick is hno, so he's easy to spot
[15:02] <abadger1999> MvG: He's almost always on #fedora-devel if you need him.
[15:03] <MvG> abadger1999: bzr-bash-completion should in no scenario be mission-critical, so nothing should be urgent. For the "bug reported" case, I'd suggest reporting upstream first, waiting some amount of time for me to come up with a fix and release it (the benefit of independent package is that I can have short and independent release cycles), then simply bump the fedora package.
[15:03] <abadger1999> MvG: Hehe -- true.  I like to be an active packager that helps out, rather than just a packager that demands fixes, though :-)
[15:04] <MvG> I guess I'll include a comment in the bug report, stating that you are now aware of the situation, but not entirely happy with it, and see if that makes core devs reconsider the core inclusion.
[15:04] <MvG> abadger1999: And I'd welcome you to be, but I'd rather have a packager demanding fixes than no packager at all due to lack of time. :-)
[15:05] <abadger1999> yeah -- Just mention that getting more plugins into core will make bzr look better when people are comparing the features that bzr vs $OTHER_SCM has within a distro.
[15:05] <abadger1999> MvG: :-)  Thanks!
[15:06] <abadger1999> I'll try to get hno to package/maintain this as I use zsh rather than bash (or maybe I'll take a look at your plugin and try adding a zsh output as well).
[15:07] <MvG> abadger1999: zsh does ship a completion script for bzr. It's prety outdated as well, but not as much as the one in the bzr source tree.
[15:07] <MvG> I've had a look at it as well, and wondered whether augmenting my script might be feasible.

[15:08] <abadger1999> The thing I miss most in the zsh script is no support for plugins -- a lot of commands from bzrtools don't have completions.
[15:08] <MvG> For lists of options it should be easy. For registry option values it should be feasible. For help strings it might at times become difficult. For arbitrary argument type completions there isn't enough information in the bzr classes to provide completions the way the hardcoded zsh script currently does.
[15:09] <MvG> In other words: all versions of bash completion currently complete option names and registry values, but leave everything else to standard file name completion. All versions of zsh completion try to be clever and complete much more, like revision numbers, versioned and unversioned files, and so on. The latter is diffiocult to do generically.
[15:10] <MvG> And expensive in terms of performance as well.
[15:10] <abadger1999> Okay.  That summary gives me a head start on what work would need doing, at least.
[15:11] <MvG> So if I were using zsh, I'd drop most of the zsh cleverness, and instead have it do what the bash script does, except for perhaps a few more help messages. But I'd need a regular zsh user to work with me on that.

[15:13] <abadger1999> MvG: Could you link to your plugin in the bug?  it'll make it easier for people to tell what they need to be packaging.
[15:15] <MvG> Will do. For you it's here: https://launchpad.net/bzr-bash-completion and http://pypi.python.org/pypi/bzr-bash-completion
[15:16] <abadger1999> Thanks!
[15:37] <MvG> abadger1999: In case you really wanna tweak the bzr-bash-completion plugin towards zsh, have a look at http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/Unix/Command/_bzr or your local installed copy of it. The format doesn't look too complicated.
[15:37] <MvG> abadger1999: I've just commented on bug #560030; maybe you and/or hno want to subscribe, so you stay in the loop.
[15:38] <abadger1999> MvG: Yeah -- hno hasn't responded to me yet -- waiting to see if he'll take the package.
[15:54] <millun> can i set "/home/millun/work/bzr" as my default push directory for more projects?
[16:00] <millun> oops. i obviously can't :)
[16:04] <MvG> millun: It should be possible, though I'm not sure it would make a lot of sense, as you'd have diverging branches preventing pushes for all projects except one.
[16:41] <vila> I need help from a losa
[16:42] <vila> lifeless: A funny one for you: pqm is looping...
[16:43] <vila> lifeless: I submitted with feed-pqm, got a failure (reported on lp, not by mail) but nothing to give me a clue about why
[16:43] <vila> lifeless: so I submitted by mail
[16:43] <vila> lifeless: no it appears that pqm is still failing but it keeps trying to process the same submission...
[16:44] <Chex> vila: hi there, what do you need help with?
[16:44] <vila> Chex: as explained above, it seems pqm is looping on the same submission and doesn't give me *any* hint about what is failing
[16:45] <vila> Chex: AIUI lifeless and spm have been working on pqm since last week, so be aware that things may have changed there
[16:46] <Chex> vila: ok, let me check the logs for you
[16:46] <vila> Chex: the urgency here is to kill this submission so that the other ones can be processed
[16:46] <Chex> vila: ah ok, thats easy, hang on
[17:02] <Chex> vila: ok, I have cleared out your submission, and cleared the pqm-bzr procs, should restart now on a new submission
[17:03] <vila> Chex: any hint of *what* was failing ?
[17:04] <vila> Chex: http://pqm.bazaar-vcs.org/ says 503
[17:05] <Chex> vila: sorry, try now
[17:06] <vila> Chex: ok, it now says 0 scripts
[17:06] <vila> Chex: any hint about why my submission failed ?
[17:07] <vila> Chex: I briefly saw a summary saying 1 error but no details
[17:08] <Chex> vila: right,  that is what I am seeing in the pqm.log file, too.. let me pastebin for you
[17:10] <Chex> vila: https://pastebin.canonical.com/30964/
[17:11] <vila> Chex: and nothing after that ? There is not even an error mentioned there :-/
[17:11] <Chex> I know.. nothing
[17:11] <Chex> vila: I think we may want to try to turn on more logging, if possible to see whats going on
[17:12] <Chex> vila: but I am not sure how to go about doing that
[17:12] <vila> Chex: Isn't there a log file for each submission ?
[17:13] <vila> Chex: at least the other submissions are being processed right now...
[17:14] <Chex> vila: yes there are indiv. log files, but they dont seem to get created until the job is finished..
[17:14] <Chex> vila: and for some reason, your patches aren't.
[17:14] <vila> Chex: AIUI, my submission has been run 3 times, you killed the last one
[17:15] <vila> Chex: ooooh, if it's only mine, then .. fine, I'll  talk with pqm :)
[17:15] <Chex> vila: talk with.. pqm? you guys have a special friendship?
[17:16] <vila> Chex: joke aside, the first submission was from the lp queue while the second (and the others) came from a direct mail
[17:16] <Chex> vila: aha, ok, I see.
[17:16] <lfaraone> Can I get a remote branch's history without branching it?
[17:16] <vila> come to think of it, I wonder if the mail one didn't trigger *3* (and not 2) runs
[17:17] <vila> lfaraone: branching *is* getting the remote history
[17:17] <lfaraone> vila: sorry, I just want the log.
[17:17] <vila> Chex: doesn't the log mention several submissions for this patch ?
[17:18] <vila> lfaraone: bzr log should accept remote urls
[17:18] <vila> lfaraone: 'bzr log lp:bzr' works
[17:19] <lfaraone> vila: okay. that will work without using SSH, right?
[17:20] <vila> lfaraone: it depends on what protocol you're using to access the branch... http ?
[17:20] <MvG1> lp uses ssh if it knows a login name, http otherwise.
[17:21] <lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
[17:23] <lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
[17:32] <lfaraone> If I have a lp: URI, how should I pass that to bzrlibb.branch.Branch in the way it expects it? ("a = bzrlib.branch.Branch('lp:ubuntu/lucid/gnome-do')" gives me an error()
[17:35] <vila> lfaraone: use Branch.open_containing()
[17:35] <vila> lfaraone: as a general rule: looking into bzrlib.builtins.py will give you many hints
[17:39] <donri> How can I add to the last commit?
[17:43] <maxb> donri: By 'bzr uncommit'ing and then committing your modified commit
[17:43] <donri> uncommit wont touch my non-committed changes since the last commit?
[17:45] <maxb> correct
[17:46] <donri> Thanks.
[18:18] <Boingo> Hello all.  I have done a bit of searching, but not a lot of finding.  I am having some very slow commits over FTP.  Even a single character change in a single file, with a fresh commit to a remote repo over FTP can take 30+ minutes.  Is there something I am doing wrong?
[18:21] <jam> Boingo: using FTP
[18:21] <jam> especially if your server doesn't support APPE (append to an existing file)
[18:22] <Boingo> My only real option is FTP in this case.
[18:22] <Boingo> I think.
[18:22] <Boingo> godaddy hosting.
[18:25] <Boingo> Why does editing even a simple small file take that long though?
[18:25] <dash> Boingo: one reason is that bzr uses compressed files to store version history, so updating via ftp can involve replacing an entire file
[18:26] <dash> Boingo: which can be a good bit bigger than the one you edited
[18:26] <Boingo> Oh.
[18:26] <Boingo> That makes sense.
[18:26] <Boingo> Is there anything I can do then?
[18:27] <dash> the easy thing to do is use some other host for your bzr repo, like launchpad or sourceforge or something :)
[18:27] <Boingo> I need something that is private.
[18:27] <Boingo> Can lp do that?
[18:27] <Boingo> Would sftp or ssh speed it up?
[18:27] <jpds> Boingo: Yes, Launchpad offers commerical subscriptions.
[18:29] <jpds> Boingo: https://launchpad.net/+tour/join-launchpad#commercial - not sure if it's what you want though.
[18:29] <Boingo> I am reasonably happy with what we have, minus the abysmal speed for commits.
[18:32] <Boingo> Will sftp or ssh speed it up?
[18:32] <dash> sftp might, ssh definitely will, if bzr is installed on the remote server
[18:33] <Boingo> It would not be.
[18:33] <Boingo> Well, at least not in the current context.
[18:33] <dash> well if you can ssh there you can install it
[22:13] <lifeless> vila: to stop it looping, you just unqueue it from launchpad
[22:14] <lifeless> vila: go to the merge proposal, click on the edit icon beside 'queued' and change to 'approved'