[00:23] lifeless: around? [00:27] mtaylor: sure am [00:28] mtaylor: what can I do for you? [00:29] lifeless: well... I'm going to get to have yet another launchpad/bzr vs. git/github discussion [00:29] * mtaylor jumps up and down with excitement [00:30] lifeless: and as part of prepping for it, it has been asked about the feasibility of us keeping things in launchpad but letting the devs continue to use git/github and syncing them [00:30] lifeless: I think this is a terrible idea, mind you [00:30] as the bug/blueprint/merge request integration is one of the main things we're gaining from launchpad and I believe we'd lose that that way ... [00:31] lifeless: but - I was wondering if you had any advice/pointers on where I should start looking/poking to be able to give real and specific feedback about that (would be easier if I used github for any reason I imagine) [00:34] uhm [00:35] is it a valid summary to say [00:35] 'some people want to keep working on github using git' [00:35] yes [00:35] 'team leads want the work tracking / planning features launchpad offer' [00:35] yes [00:35] is there more to it than that ? [00:35] nope [00:35] ok [00:35] one way [00:35] trunk on lp [00:35] feature branchces on lp [00:36] merge proposals on lp [00:36] have your well known branches - trunk, releases - mirrored to git [00:36] and hell, sourceforge and the hg site too [00:36] using bzr-* plugins and cron [00:36] (there's an hg site?) [00:36] k [00:36] then say in your project docs [00:37] 'launchpad is official, launchpad is great. But if you have muscle memory of $other vcs, see x, y, z and you can work on that site for *code management only*' [00:37] make the $other site pages point to launchpad with ambiguity [00:38] ok. that all seems sensible... [00:38] and document how the dev in question can generate a branch on launchpad (again, push with the bzr-* plugin to launchpad) [00:38] for merges etc [00:38] I suggest doing multiple sites because your center of gravity will be less a battle of two things and more a common-reference point - its a social angle on it [00:38] given the way git arranges branches - does bzr-git pushing to a branch on launchpad do what I expect? [00:38] mmm. very good point [00:39] mtaylor: bitbucket.org is the hg one [00:39] mtaylor: now, the git folk may say 'we don't care about hg/svn we wanna bikket gnar gnar gnar' [00:40] mtaylor: I would then ask - so if its not about acessability for non bzr users, what is it about ? :) [00:40] lifeless: I, in fact, assure you they will say exactly that [00:41] There's another hg one, too. === oubiwann is now known as oubiwann-away [01:24] jelmer: bzr: ERROR: exceptions.KeyError: 'No such TDB entry' [01:25] mtaylor: When? [01:26] jelmer: I was trying to bzr dpush a bzr branch to an empty git repo on github [01:26] jelmer: I'm using head of lp:dulwich and head of lp:bzr-git [01:26] jelmer: it seemed to be happening right after it finished updating the git map [01:29] mtaylor, does your repository perhaps contain ghosts? [01:30] mtaylor: it might also be a regression in the dpush code which is being refactored at the moment so we can support roundtripping. I would recommend sticking with the releases for the time being. [01:30] jelmer: ah ok [01:31] jelmer: the version in lucid broke in a different way so I just grabbed trunk [01:31] jelmer: I'll try a recent release [01:32] jelmer: well, that's certianly creating a different amount of things in the git map [01:33] jelmer: trying 0.5.1 [01:38] mtaylor, if you can still reproduce some issue with 0.5.1, please file a bug [01:38] I'm off to get some sleep, back in ~7h :-) [01:38] jelmer: will do [01:38] jelmer: thanks [01:39] mkanat: hi, are you around? [01:39] poolie: I am! [01:40] are you still working on loggerhead? [01:40] if so, i think we should be more in touch [01:40] poolie: Yeah, I'm still doing stability stuff. [01:40] poolie: Yeah, I think that's a good idea. :-) [01:40] are you working with anyone else on it? [01:40] poolie: Well, I get people to review my patches now and again. [01:41] poolie: Usually Peng or mwhudson. [01:41] oh that's good [01:41] but sometimes you just commit to trunk? [01:41] poolie: No, I don't have privs. [01:41] poolie: So all my merge proposals get reviewed. [01:41] (i'm not trying to give you a hard time, just to understand) [01:41] ah ok [01:41] poolie: Which is probably good, at this point. [01:41] istm you probably should be a committer though? [01:42] even if you still ask for reviews first [01:42] poolie: Possibly, yeah. [01:42] poolie: Sometimes it's not too clear when the proposal is "reviewed enough" to check in, though. [01:42] yeah [01:43] but you can just say "is this reviewed enough yet?" until people give a clear answer [01:43] i had a couple of other ideas [01:43] one would be to post an occasional short note to the bzr list about what you're doing [01:43] poolie: That'd be good. I should probably subscribe to that list. :-) [01:43] :) [01:44] even if you just skim it, it would be a good idea [01:44] poolie: FYI, right now what I'm doing is tracking down a memory leak, but meliae is breaking on my platform and jam and I haven't figured it out yet. [01:44] of course you don't need to recapitulate every patch but just an idea of the general area might help [01:44] yes he said so [01:44] that might also be reasonable to post about [01:45] poolie: http://wiki.bazaar.canonical.com/BzrDevelopment mentions the word "mailing list" several times but has no link to it. [01:45] jam knows the most about meliae but the build problems might ring a bell for someone else [01:45] heh, really [01:45] we can fix that [01:49] that page is pretty old [01:49] better now, mkanat? [01:49] how did you get to that page? [01:49] poolie: Hahaha, better! [01:49] we could adjust the links to it [01:49] poolie: google "bzr developers mailing list" [01:51] thumper: so this revno is wrong bug [01:51] poolie: Okay, I've subscribed to the mailing list. [01:51] thumper: is it on lp-code ? [02:09] mkanat: so the final thing was, perhaps you should be more in touch with the LOSAs? [02:09] poolie: Yeah, that would be great. [02:10] * spm waves hi to mkanat [02:10] Hey spm. :-) [02:10] yay :) [02:10] poolie: Well, I'm in touch with spm. [02:10] spm, mkanat is working on loggerhead [02:10] poolie: But he's not always around. [02:10] oh ok [02:10] mkanat: are you in the us? but you normally work evenings on this? [02:10] poolie: I am in the US. My schedule varies a fair amount. [02:10] poolie: I'm in California. [02:11] ok [02:11] there are a couple of people in the US [02:11] mbarnett and . um [02:11] poolie: But I'd say generally I'm working between 9am and 11pm. [02:11] mkanat: have you been introduced to the other losas? mthaddon, Chex and mbarnett? Chex and mbarnett are roughly in your TZ. [02:11] oh chex [02:11] spm: I haven't, no. [02:11] spm: I think what would be ideal is if you guys basically considered me the contact for loggerhead stability. [02:11] so i think it would be nice if there was a conversation here about [02:12] pain points, getting new versions rolled out [02:12] getting you debug data from our deployment [02:12] what else? [02:12] mkanat: scary: https://edge.launchpad.net/~canonical-losas/+mugshots [02:12] spm: Ah ha! :-) [02:13] poolie: we auto rollout lp-loggerhead, as distinct from 'loggerhead' every day if a new version is available? that's been in place for some time. ?? [02:13] Hmm, I thought I had a picture on launchpad.... [02:13] spm: I think at some point there's going to have to be a conversation about making a stabler branch of loggerhead that you guys can use, though. [02:13] mb is particularly scary [02:14] mkanat: I can abuse my powa and give you an ... unsuitable one :-) [02:14] spm: lol. [02:14] spm: No, I have one, I'll go grab it and upload it. [02:14] it's been years since i've seen the goatse guy [02:14] ..... [02:14] Oh, I do have a mugshot. [02:15] is there any suitable list where all these people could talk? [02:15] But I can't find the URL in the Wall Of Text. [02:15] maybe it's enough to just have mail to losas@ plus max and me... [02:16] poolie: I imagine we're all on the bzr list, no? [02:16] would we need tim involved? or is this no longer in his baliwack? [02:16] i don't know if the losas are [02:16] what poolie said [02:16] probably it is [02:16] Maybe there should just be a loggerhead list. [02:16] it's a bit between the cracks [02:16] arguably lp-dev would be better [02:16] +1 [02:16] that's public, and fairly low traffic [02:16] and the losas should be subscribed [02:17] and i would like to see it have a bit more traffic [02:18] max, fwiw, lp-loggerhead is *vastly* more stable these days. the few occaisons I've been alerted in recent weeks, it's typically fixed itself before I could get much done beyond basic "is it really/still down?" [02:18] spm, mkanat, what do you think? [02:18] spm: That's pretty good! :-) [02:18] i'd like to see it give a better message when it does fail [02:18] anybody know - if I'm doing a bzr-git dpush --- if I abort it after updating git map during generating git objects - will it have to do the git map all over again when I restart it? [02:18] poolie: Yeah, lp-dev would work. [02:18] ideally with an oops-like identifier that can go into a bug report [02:18] https://lp-oops.canonical.com/oops.py/?oopsid=like [02:19] * poolie pets the bot [02:19] poolie: yah, lp-dev is fine by me [02:19] spm the losas do all read it? [02:19] "no comment" ;-) [02:19] we are subscribed. reading implies... other things. [02:20] i won't even bother asking about "understand" then :) [02:20] heh [02:21] I'd suggest it's a case of 'keep an eye on', vs read every thread. Most discussions therein are more at the code layer and only rarely touch on operational concerns. So that would tend to define the scheduling it gets in our attention span. [02:22] that's fine [02:22] so if the subject is clear, you'll read it [02:22] that's what i though [02:22] *thought [02:23] so mkanat perhaps you would be kind enough to post a thread saying what you're up to and soliciting feedback from losas [02:23] how do things get into lp-loggerhead? [02:23] not speaking for the others; but yes for me. Some persons who reply at top levels in a thread will also garner my attention. But that's a personal info filter. [02:24] poolie: thumper is probably best placed to answer that? or mwh if he's around. [02:24] poolie: Mostly by somebody asking, I think. [02:25] poolie: I think the trouble with loggerhead is that it has a great UI, but until recently it had massive, fundamental architectural problems. [02:25] like you, if you think you've fixed something? [02:25] mm [02:25] poolie: Yeah. [02:25] also there is a project towards having an edge/beta loggerhead [02:25] i'd like to know where that's up to [02:25] poolie: Well, that's basically what you're running in production. [02:25] poolie: Which is the problem. [02:26] poolie: Or at least, one of the problems. [02:26] production being edge, in this specific case? yes. [02:26] i mean, a place by which new code can be exposed to realistic load [02:26] and then something that updates more solwly [02:26] spm: Well, lp-loggerhead pretty much contains loggerhead trunk. [02:27] poolie: Oh, yes. [02:27] mkanat: kk, I'd assumed as much; but wasn't aware of the fine print - if any [02:27] poolie: That is definitely something we should have. [02:34] poolie: that's RT:38985 fwiw; apologies there - looks like it was languishing from not being correctly tagged (by us). [02:35] oh ok i was wondering about that [02:35] spm so you can look at that as making edge faster-moving, or lpnet slower-moving, or both [02:36] at any rate getting a bit away from one-size fits all [02:36] i guess to prioritize this it would be useful to know [02:36] when in doubt, raise it with tom/francis. we do try real hard to pay attention to the priorities, so please do actively manage those :-) [02:36] ha. snap. :-) [02:36] - how often do rollouts cause problems? [02:36] does mkanat or anyone else wish to roll out any faster? [02:36] No, definitely not. [02:36] if we did roll out faster, would the feedback data get back to mkanat? [02:37] "definitely not" want to go faster? [02:37] I'd like to be able to rollout every time that there is a fix :) [02:37] poolie: Right, definitely not want to go faster, at the moment, because it's trunk. [02:37] I'm not aware of any cases of a rollout causing problems - having said that, I don't we actually have too many either. so... :-/ [02:37] lifeless: Right, but to do that, we need two branches. [02:37] Is this a bad time/room to ask for help? Is there a better room for that? It appears I'm interrupting something. [02:37] lifeless: We need an actually stable branch of loggerhead, preferably one with better test coverage on load issues. [02:38] lifeless: generating git objects 2867/11230 [02:38] lifeless: perhaps I should have picked something other than drizzle to use as a test case :) [02:38] GradysGhost: This channel is fine. [02:38] given our current setup tho - if a rollout breaks; we can/do revert - I think automatically even for simple "it no responds correctly" [02:38] GradysGhost: go for it. we can always /ignore you ;-) [02:38] heh. True. [02:39] mkanat: seems like you are well on the way to heaven [02:39] lifeless: lol [02:39] Okay, so I'm trying to set up bzr on my server so that only myself and a friend can commit changes to the working product. Forgive me, but this is the first time I've ever worked with any kind of revision control system, so my terminology may not be correct. [02:40] GradysGhost: That's fine. :-) Is it a Unix system? [02:41] Or *nix, I guess I should say. [02:41] I've set up a Bazaar repository at /opt/bazaar/repository. I've started bzr with `bzr serve --directory=/opt/bazaar/repository` and that appears to be working. It is Linux Mint Helena. [02:41] I intentionally left off the --allow-write parameter since that appears to allow global writing. [02:41] The process is running as root. [02:41] GradysGhost: Okay. You just use basic *nix permissions to control who can write to the directory, and then you allow SSH access to your server from user accounts. [02:41] That's what I'm getting to. [02:42] It looks like everything should be in order, but it's still failing. [02:42] So I added a group and put my own user account into that group, then I recursively set the group ownership on the repo to that group. [02:43] Perms are 775 on all files, including the .bzr control directory. [02:43] So I do this: `bzr push --create-prefix bzr_ssh://ryan@localhost/path/to/branch` [02:43] And I get an error: bzr: ERROR: Permission denied: "earthcrash/client/": : [Errno 13] Permission denied: '/earthcrash' [02:43] poolie: as an aid to clarity. what is the .. governance (I guess) of loggerhead vs lp-loggerhead these days? aiui, lh is a stock oss project - that just happens to have large numbers of lp devs working on it, vs lp-lh which is the blessed version of same that we actually run with. ? [02:44] GradysGhost: you have to yse --allow-write, or the server won't permit *any writes* [02:44] Okay. I'll try that. That doesn't allow global write perms for anybody? [02:44] GradysGhost: it does [02:44] As long as world perms lack write? [02:44] GradysGhost: we recommend using the server with bzr+ssh or bzr+http if you wish to have people writing. [02:45] I have SSH installed. What kind of config do I need to do to make it bzr+ssh only, disallowing write access to anyone without a valid account and auth? [02:45] SSH does work; I've been using it on this config for at least a year. [02:45] Well, at least 6 months. [02:47] GradysGhost: you are already setup then; just use bzr+ssh urls on your client machines. [02:47] GradysGhost: there is no need to have a continually running server [02:47] as the ssh server will start bzr when a bzr+ssh client connects. [02:47] Okay. I gotcha. I was under the understanding that I still needed to have bzr running in server mode. [02:47] That's very cool. I was unclear on that. [02:47] I will try it out. Thanks for the help, lifeless. [02:50] hi spiv? [02:59] spm: lp-loggerhead has a bunch of modifications to loggerhead. [02:59] spm: Mostly about the environment that it runs in--Paste changes, and so on. [02:59] spm: It also represents the whole package that runs on launchpad, including any plugins, I believe. [03:00] mkanat: oki. so we do very much have a separate blessed version. I guess - who is the blessor in the usual case. ? [03:00] spm: It used to be mwhudson. [03:00] spm: The thing is, the loggerhead that's in lp-loggerhead is pretty much stock loggerhead. [03:00] spm: There are just a bunch of additional files. [03:01] spm: I suppose Peng also handles lp-loggerhead. [03:01] spm: It's probably a bit up in the air. Maybe thumper? [03:02] Anyhow, I'm out for the night. :-) [03:02] Later, folks! [03:02] it might be nice to factor those differences out [03:02] possibly. the question has come up in similar terms regarding lp as a whole. because we're dealing with prod code, and confidentiality of protected code (etc), we need a Canonical person to give the nod that X is ok to go into prod. [03:02] into a non-merged change so just config changes [03:02] then we could more easily experiment [03:02] lifeless: I agree completely. [03:03] mkanat: if you have time available in the contract, that would be good to do, then. [03:03] lifeless: Yeah, it's something I could talk to Francis about. [03:04] lifeless, mkanat: hi, what's up [03:04] ? [03:04] mkanat: please do :) [03:05] thumper: Oh, nothing. Was just wondering if you were in charge of the launchpad-loggerhead branch now. [03:05] thumper: just chewing over loggerhead - it came up on the bzr list [03:05] the launchpad-loggerhead branch has been merged into launchpad proper [03:05] poolie, lifeless: Can you send me an email or something to remind me to do all the things we talked about just now? [03:05] I'd do it myself but I have to run. [03:05] thumper: nothing in particular on de agenda; see the backlog for nitty details [03:05] as of a few months ago [03:05] thumper: Oh! [03:05] So that's done. [03:05] cool [03:06] thumper: you really should give Guido his time machine back. [03:06] Anyhow, I do have to go. [03:06] thumper: I hear he needs it to make Python3 nice. [03:06] night max! [03:06] Later! [03:06] lifeless: HAHAHAHAHAHA. [03:06] mkanat: ciao [03:06] mkanat: ttfn [03:06] Later. :-) [03:06] lifeless: perhaps just fixing up strings and WSGI [03:06] lifeless: which I hear is a bit of poo [03:07] its a bit contentious [03:07] email too is in trouble [03:07] really? [03:07] damn [03:07] thread today about a use case where its - I think - 18 times slower. Or something, I skimmed it. [03:07] I don't really follow py-dev [03:08] lifeless: about the last revision bug, I really think it is a bzr bug [03:08] lifeless: as it happened locally on the guys machine [03:08] lifeless: his local reconcile fixed it, but push --overwrite didn't update LP [04:10] spm: good question about governance [04:10] i'll be the canonical manager and mkanat is the technical lead [04:10] ahh, excellent. good to know. ta. [04:10] thumper: ok let me look for a bug [04:11] iow if you have bugs talk to mkanat, if he doesn't answer talk to me :) [04:11] ha, kk, will do. [04:14] thumper: ok, no open bugs I can see. Please change the product to bzr and gimme th enumber again. [04:14] thumper: or just gimme the number and I'll do it all [04:15] lifeless: ok, let me look [04:15] https://bugs.launchpad.net/bugs/599492 [04:15] Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,Incomplete] [04:20] thumper: there are two bugs here but neither in lp-code. [04:20] I thought so [04:22] As for the branhc in question [04:22] just reconcile it [04:22] on lp, if you could [04:40] spiv bug 599670 is the one i alluded to on the phone [04:40] Launchpad bug 599670 in Bazaar "ValueError: absent factory in _stream_to_byte_stream during push (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/599670 [04:50] * spiv looks [04:54] dude. this bzr-git dpush has been running for 3.5 hours [04:55] mtaylor: dpush will be rebasing your local history [04:55] mtaylor: you probably didn't want dpush. [04:55] mtaylor: I like to think the D stands for 'do not want' [04:56] lifeless: well, it said that push wasn't supported [04:56] mtaylor: >< [04:56] mtaylor: I'm really serious, its going to be stripping all your local history down to zip, and rewriting it as a import from the git representation [04:56] lifeless: so I should cntrl-c this [04:57] mtaylor: depends, do you value your life with other drizzle devs? [04:57] lifeless: :) [04:57] I'd use bzr fast-export || git fast-import [04:57] for maintaining the git mirror [04:57] lifeless: ah. [04:57] dpush is pretty bad, because you can't simultaneously do it to hg and svn [04:58] (the code quality is ok, its the concept that hurts) [04:58] lifeless: ok... I guess I should learn about fast-export [05:02] lifeless: sigh [05:03] fatal: Path libmysql/libmysql.c not in branch [05:03] lifeless: why do I get the feeling this is going to be fun [05:08] mtaylor: FSVO painful ? [05:08] lifeless: yup [05:09] lifeless: I'm guessing this has to do with bzr tracking renames and git not so much doing that [05:09] fast-export can include renames [05:09] FTW [05:13] yup. so that doesn't work [05:14] file bugs [05:14] and tell your git fanboy devs to suck it up ? [05:14] lifeless: should I file bugs against git or bzr? [05:14] mtaylor: which process blew up [05:14] lifeless: I'm guessing git, since it's the one that crashed [05:15] check the stream did include the file creation and rename [05:15] but yes, I suspect so [05:18] lifeless: M 644 inline libmysql/libmysql.c shows up in the stream [05:19] looks sensible to me [05:19] is the fail on a rename of that? [05:19] yes [05:19] sounds like a boog to me [05:20] well, it would be great if there was a report-a-bug link on the git website. [05:20] lemme go ask in #git [05:21] ... [05:22] I need a hallway check [05:22] what would you expect 'before:thread:foo' to resolve to ? [05:22] [this is open to the floow] [05:23] i don't know [05:23] where would i find help about the meaning of 'before:'? [05:23] bzr help revspec [05:23] lifeless: I'd expect it to resolve to the thread before foo? [05:23] sorry [05:23] revisionspec [05:24] i thought that was it but it doesn't work [05:24] lifeless: oh - hrm [05:24] mtaylor: great, thats what I was hoping someone would say. [05:24] i would have thought the penultimate revision in foo [05:24] and thats the other answer [05:24] however saying "the thread under foo" would be useful [05:25] lifeless: before == parent of the revision - thread: is tip of a loom [05:25] but i'd expect that to have a different name [05:25] ok [05:25] that was the tension being considered in a bug [05:25] I'll go with below [05:25] lifeless: so - parent of the tip of the loom [05:25] below:tread:foo [05:25] so you can say [05:25] before:below:thread:foo [05:28] lifeless: +1 for below: [05:29] * poolie is putting 2.1.2 into the ppa [05:30] \o/ [05:30] me too [05:30] :qa [05:31] ZZ? [05:31] so what's the right way to bring in upstream changes from another branch, using builddeb? [05:31] just plain merge? [05:32] poolie: that's what I do [05:32] ah http://jameswestby.net/bzr/builddeb/user_manual/normal.html answers pretty well [05:32] merge-upstream with the tarball and the upstream branch [05:34] yes [05:35] poke me if it blows up - it may [05:35] you may need an import-upstream first, depending on the packaging state. [05:35] I've been improving this recently. [05:39] is there a special Command attribute for example help? [05:39] vs the main prose? [05:39] yes, and no, there isn't [05:39] only a todo wishing for one :) [05:40] Not currently, that might be nice; probably wants to be a list or dict or something. [06:34] spiv if you wanted you could post an rfc on how to clean up merge [06:34] or talk to vila perhaps [06:34] the strasbourgeouis teddybeaor [06:41]