| maxb | Ronnie: I've pushed the result of those three merges to lp:~maxb/loco-directory/710969-example in case an example is helpful | 00:01 |
|---|---|---|
| Ronnie | yes, an example could be very usefull | 00:02 |
| Ronnie | ill have a look | 00:02 |
| maxb | When I said: | 00:05 |
| maxb | < maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 570613 branch, you reverted most of the changes. Later, the 570613 branch got merged into the upstream branch | 00:05 |
| maxb | I got some of the numbers wrong | 00:05 |
| maxb | I should have said: | 00:05 |
| maxb | So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 611304 branch, you reverted most of the changes. Later, the 611304 branch got merged into the upstream branch | 00:05 |
| spiv | vila: I didn't know that, thanks for mentioning it. I don't *think* there's any obviously relevant bug fixes since then, but it's possible... | 00:11 |
| Ronnie | maxb: i had difficulties to read the log (history viewer from a nautilus plugin) but i think i get it. but i dont know what commands to use te revert it | 00:20 |
| Ronnie | i normally only work with the branch, merge, status commands, and sometimes the resolve | 00:21 |
| maxb | Ronnie: I would very much recommend installing bzr qlog | 00:21 |
| Ronnie | maxb: do you have a link, branch for that? | 00:22 |
| maxb | Ronnie: ubuntu? | 00:22 |
| Ronnie | yep | 00:22 |
| maxb | 'apt-get install qbzr' | 00:22 |
| maxb | And yes, it will probably want to install megabytes of libqt*, but I find it to be worth it, for the ease with which it lets you understand complex merging | 00:23 |
| Ronnie | nah, i had already the qt libs | 00:23 |
| maxb | Ronnie: I've appended the commands I used to bug 710969 | 00:26 |
| ubot5 | Launchpad bug 710969 in Bazaar "Merge did not work as expected" [Undecided,Invalid] https://launchpad.net/bugs/710969 | 00:26 |
| Ronnie | maxb: is ci a shortcut for commit | 00:28 |
| maxb | yes | 00:28 |
| Ronnie | ah, thx | 00:28 |
| Ronnie | hmm, i did not find qlog more informative than bzr-gtk history viewer (did you ever try that one?) | 00:29 |
| maxb | It's an abbreviation for "Check In" - which is actually quite silly, as it's a hold-over from the dark ages of locking VCS, but people still use it because it's short :-) | 00:30 |
| maxb | I have used bzr viz. I found bzr qlog quite superior, due to its flexible expanding and contracting of branches | 00:30 |
| Ronnie | maxb: at the command: "bzr merge -r revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt ../0.2/" it shows some errors. should i resolve these now, or do all the other commands first? | 00:33 |
| maxb | hmm. It did not show errors for me | 00:35 |
| * maxb rechecks | 00:35 | |
| maxb | oh, conflicts, not errors | 00:37 |
| maxb | The next command "bzr revert ." will get rid of them | 00:37 |
| Ronnie | maxb: yea, conflicts | 00:37 |
| Ronnie | http://paste.ubuntu.com/560793/ | 00:37 |
| Ronnie | oh, ok | 00:37 |
| Ronnie | maxb: thx it works like expected | 00:42 |
| maxb | np | 00:53 |
| poolie | lifeless, did you already reset loggerhead trunk to 1.18? | 05:31 |
| lifeless | no | 05:31 |
| lifeless | was waiting on the 2a update to pthe pqm branch | 05:31 |
| lifeless | which happened just recently | 05:32 |
| lifeless | i couldn't sensibly push/compare etc before then | 05:32 |
| vila | hi all ! | 07:41 |
| * fullermd flops at vila. | 07:45 | |
| vila | ;) | 07:46 |
| poolie | hi there vila, fullermd | 07:51 |
| vila | hey poolie ! | 07:51 |
| poolie | vila, i should stop for the day i guess | 08:03 |
| poolie | how are things with you? | 08:03 |
| vila | poolie: fine, setting up a local package importer, going through the hidden dependencies, should be usable today (with its associated ppa) | 08:04 |
| poolie | ah, good | 08:04 |
| poolie | it's already in a ppa, or you're going to make one? | 08:04 |
| poolie | i looked a bit at https://bugs.launchpad.net/loggerhead/+bug/701329 | 08:04 |
| poolie | and we learned a bit, though not yet what the final answer is | 08:05 |
| vila | I just created a new one to stop misusing my own (still private to me so far but allowing to track the precise versions) | 08:05 |
| poolie | vila, actually can you give me a quick call at home? | 08:06 |
| vila | sure | 08:06 |
| vila | gha, phone battery empty, just a sec | 08:07 |
| fullermd | Battery? But, phones get all their power from the 4 little copper wires going into them... | 08:08 |
| vila | fullermd: 4 ? We do fine with 2 around here... :D | 08:35 |
| vila | damn, totally missed this one, 2 for power and 2 for line which is why it failed >-) | 08:35 |
| fullermd | Well, OK, only 2 technically needed for single-line basic working. But I don't remember the last time I saw a 2-conductor cable going into 6P2C connectors, so... | 08:40 |
| vila | connectors... we still have old phone plugs with 8 wires here (but rj11 is 6 right ?) | 08:46 |
| fullermd | 6P4C as a rule. | 08:48 |
| fullermd | Though now that I double check, my desk phone actually has an integral cable that's 6P2C. Cheap bastiches. | 08:49 |
| vila | can't you just settle on international standards for once... :-P | 08:52 |
| fullermd | Hey, we adopted International Morse over American. What more do you want? :p | 08:53 |
| vila | metric system ? | 08:53 |
| fullermd | I tried drinking 473 cc's of beer once. Didn't taste near as good as a pint. | 08:54 |
| vila | Oh I don't mind pints, but mphs are a booby-trap, I keep trying to jump out of cabs at 30... | 08:56 |
| fullermd | You just gotta roll. | 08:58 |
| sobersabre | hi, I am confused a bit. | 09:25 |
| sobersabre | I have a bzr tree, let's call it /tree1 | 09:25 |
| sobersabre | I also have another tree /somewhere/tree2 | 09:25 |
| sobersabre | I want to reach /somewhere/tree2/tree1 | 09:26 |
| sobersabre | when all history from tree2 and tree2 are preserved. | 09:26 |
| sobersabre | how do I translate this into bzr operations ? | 09:26 |
| sobersabre | is it possible ? what possible problems may occur ? | 09:26 |
| fullermd | cd /somewhere/tree1 ; bzr branch /tree1 ; bzr join tree1 ; bzr commit | 09:27 |
| fullermd | That's basically equivalent to cd /somewhere/tree2 ; bzr merge -r0..-1 /tree1 ; [move all files into tree1/ subdir] ; bzr ci | 09:27 |
| sobersabre | fullermd: you've confused tree1 and tree2. | 09:28 |
| fullermd | (not exactly, but conceptually it gets you in the right territory) | 09:28 |
| sobersabre | fullermd: I understood yer 1st remark. | 09:28 |
| sobersabre | I got lost on the 2nd. | 09:29 |
| sobersabre | if I am merging tree2 into an empty tree1 ... what am I achieving ? | 09:29 |
| sobersabre | I mean you suggest to create a copy of the tree /somewhere/tree2, in /somewhere/tree2/tree1 ? | 09:30 |
| fullermd | Mmm. If I'm backward on tree1 and tree2, I don't understand what you're saying... it certainly sounds like you're wanting to put tree1 (and all its history) in a subdir of tree2. | 09:30 |
| sobersabre | true. | 09:30 |
| fullermd | Then... oh, I typo'd "/somewhere/tree1" for tree2 right at the start there. | 09:31 |
| * fullermd blames vila. | 09:31 | |
| sobersabre | let's make is easier in naming: /1 is a tree. /d/2 is a tree. I want to have: /d/2/1/ | 09:31 |
| sobersabre | fullermd: what is vila. | 09:31 |
| fullermd | An evil spirit that inhabits #bzr and screws with my typing. | 09:32 |
| vila | well, for my defense, I'd point out that sobersabre also confused 1 and 2 in: " when all history from tree2 and tree2 are preserved." :-D | 09:32 |
| sobersabre | vila: true :) | 09:32 |
| sobersabre | so, if I translate it: | 09:32 |
| fullermd | It's in your defense that you're screwing with HIS typing as well as mine? :p | 09:32 |
| vila | well, let say I'm quite generous and love to share my tyops | 09:33 |
| sobersabre | cd /somewhere/tree2 ; bzr branch /tree1; bzr join tree1; bzr ci -m "join-a-tree" | 09:33 |
| sobersabre | vila: I've never seen your tyop. can you share ? | 09:34 |
| fullermd | Yes. 'join' is roughly equivalent to 'merge' into a subdir. | 09:34 |
| vila | sobersabre: you're new here right ? Just you wait and you'll see my tyops soon enough ;) | 09:36 |
| fullermd | So you wind up with a merge commit, with the whole history of tree1 off on the RHS. Except that from tree2's perspective, it all happens inside '$ROOT/tree1' instead of '$ROOT' | 09:36 |
| sobersabre | hm. | 09:37 |
| sobersabre | I did an experiment. | 09:37 |
| sobersabre | I WANT the history of tree1 | 09:37 |
| sobersabre | so I rephrase: I have /path/tree1, /path/tree2. I want to have /path/tree2/tree1 so that now have both files from /path/tree1 in /path/tree2/tree1, AND the history of /path/tree1 is inside the history of /path/tree2 (if I run bzr log) | 09:39 |
| fullermd | Yes, that's why you're join'ing. | 09:39 |
| sobersabre | oh, I see. | 09:40 |
| sobersabre | If I run bzr log -n0, THEN I see merged stuff. | 09:40 |
| sobersabre | cool | 09:40 |
| sobersabre | very nice. | 09:40 |
| vila | sobersabre: give a try to 'bzr qlog' from the qbzr plugin too | 09:41 |
| * fullermd always wonders if he should pronounce that "cube-zor"... | 09:42 | |
| sobersabre | fullermd: call it 'cuby' | 09:46 |
| sobersabre | q b | 09:47 |
| vila | cude-zor sounds right, but then, I'm not a native speaker so me and accents... | 09:47 |
| fullermd | It brings to mind many long hours wasted playing Q*bert. | 09:48 |
| jelmer | maxb: hi | 10:00 |
| jelmer | maxb: what does that recent MP change exactly? | 10:00 |
| maxb | jelmer: You asked for some added docstrings | 10:05 |
| maxb | Oh, wait. bzr MP or bzr-svn MP ? | 10:06 |
| jelmer | maxb: bzr-svn mp | 10:09 |
| jelmer | maxb: I don't see any new docstrings in the MP email | 10:09 |
| maxb | hmm. I pushed... I thought. Let me check | 10:10 |
| maxb | They're on LP | 10:11 |
| maxb | but for some reason it's not representing my additional pushed revision in-line in the comment flow of the MP | 10:12 |
| vila | maxb: there is probably a bug around that, I notice it randomly | 10:14 |
| jelmer | maxb: got it now, thanks | 10:27 |
| jelmer | vila: There have been some bugs related to file id rewriting in working trees after dpush recently | 10:27 |
| jelmer | vila: it uses tree transform, which is still a bit obscure to me. I was wondering if you could have a look to double-check I'm using the API correctly? | 10:28 |
| vila | jelmer: urgh, yeah, I can try, but I've been notoriously bad at that myself (though I learned a few tricks in the process) | 10:29 |
| vila | jelmer: where should I look ? | 10:29 |
| jelmer | vila: bzrlib/foreign.py, function update_workingtree_fileids() | 10:30 |
| vila | in trunk ? | 10:30 |
| jelmer | yep | 10:30 |
| jelmer | though it hasn't changed since 2.1 I believe | 10:30 |
| maxb | jelmer: Oh, btw, i have an Approved dulwich MP, is that just wsiting for next time you do work on dulwich, or do you need amything more from me there? | 10:32 |
| jelmer | maxb: I'll have a look | 10:34 |
| * jelmer wished there was a good way to see all the MPs he was involved with | 10:34 | |
| jelmer | maxb: that's already been merged | 10:34 |
| maxb | huh | 10:35 |
| maxb | silly lp, then | 10:35 |
| Tak | I'm really surprised LP doesn't have that | 10:36 |
| vila | jelmer: so, f, p, c, v, d, n, k, e is a bit obscure :) But more seriously, the doc string says update the file-ids, but I don't see how you acquire the file-ids from the other tree, | 10:36 |
| jelmer | maxb: the revision was dpushed, so it can't use the revision id to see when the MP was merged | 10:36 |
| maxb | ah | 10:36 |
| * jelmer should put some more time into proper roundtripping support in bzr-git | 10:37 | |
| vila | jelmer: oh, 'f' is the file-id, so target_tree.iter_changes() should provide them | 10:38 |
| jelmer | vila: Aaron wrote that code originally, and it's worked fine before | 10:38 |
| jelmer | vila: I'm not entirely sure how then :) | 10:38 |
| jelmer | vila: ah :) | 10:38 |
| maxb | btw in the dulwich case I filed a bug on, some revision ids hadn't been dpushed either | 10:39 |
| vila | jelmer: so, this code looks correct to me, but often with tt, combining multiple operations is where the problems start, do you have a specific one problem with this code ? Or when it's used in conjunction with some other operations ? | 10:39 |
| vila | jelmer: the tt seems to be local to the function though | 10:40 |
| jelmer | yeah, it's all in this function | 10:40 |
| jelmer | vila: bug 707761 | 10:40 |
| ubot5 | Launchpad bug 707761 in Bazaar "'versioning no contents' tree transform error during dpush" [High,Triaged] https://launchpad.net/bugs/707761 | 10:41 |
| vila | haaa | 10:41 |
| vila | jelmer: right, so based on tt.new_file(), you probably need a tt.create_file(contents, trans_id) in *some* cases | 10:44 |
| vila | emphasis on some, hilarity ensues | 10:44 |
| vila | jelmer: "some" may be when the newly versioned file doesn't exist under the right? path in wt | 10:46 |
| vila | ? | 10:46 |
| jelmer | ah, hmm | 10:47 |
| vila | jelmer: you will need more tests for update_workingtree_fileids() it seems :-/ | 10:47 |
| jelmer | vila: thanks | 10:47 |
| vila | jelmer: sounds likely ? | 10:47 |
| jelmer | vila: yeah, somewhat | 10:48 |
| vila | ok | 10:48 |
| pfarrell | is there a bzr equivalent of svn:externals? If I check out one bzr repository, it automatically checks out another? | 10:50 |
| jelmer | pfarrell: not in the core (yet). there are some plugins that provide similar functionality, such as bzr-externals | 10:50 |
| pfarrell | jelmer: oh, right, thanks. | 10:51 |
| vila | hmm, http://launchpadlibrarian.net/63287267/buildlog_ubuntu-hardy-lpia.pristine-tar_1.11ubuntu1~pkgimport1_MANUALDEPWAIT.txt.gz | 10:55 |
| vila | fails on debhelper(inst 6.0.4ubuntu1 ! >= wanted 7.0.50) | 10:55 |
| vila | I suspect I'm running into an issue known by maxb... Is https://launchpad.net/~bzr/+archive/builddeps part of the asnwer ? | 10:56 |
| vila | answer | 10:56 |
| vila | except the later includes only debhelper-7.0.13 | 10:56 |
| jelmer | vila: is there any reason you actually need debhelper 7.0.50 ? | 10:56 |
| jelmer | as opposed to an older version, I mean | 10:57 |
| vila | jelmer: no idea, this is required by pristine-tar, do you suggest I should try to lower the requirement and see ? | 10:57 |
| vila | jelmer: hardy has debhelper 6.0.4, -backports has 7.0.13 as does bzr-builddeps, so lowering to 7.0.13 and add bzr-builddeps as a ppa dependency ? | 11:04 |
| maxb | vila: most dh7 stuff does actually require 7.0.50 | 11:06 |
| maxb | look for override_* targets in rules | 11:07 |
| maxb | they are the most common reason | 11:07 |
| vila | maxb: two occurrences for pristine-tar: override_dh_auto_configure and override_dh_auto_clean | 11:08 |
| maxb | right, so you do need a later debhelper than backports provides | 11:08 |
| vila | maxb: can debhelper be upgraded >= 7.0.50 in https://launchpad.net/~bzr/+archive/builddeps ? | 11:09 |
| vila | maxb: I'm pretty sure I'll have to add it as as dependency to https://launchpad.net/~vila/+archive/pkgimport anyway | 11:09 |
| === wgrant_ is now known as wgrant | ||
| maxb | ah so we've stopped trying to sru pristine-tar for jubany? | 11:10 |
| vila | maxb: that's different, I'm trying to setup a local package importer and doing so track what is needed | 11:11 |
| vila | maxb: I thought prisitine-tar has been upgraded on jubany anyway, I didn't know about an sru for it... | 11:11 |
| maxb | you can find a suitable debhelper in mercurial-ppa/builddeps | 11:12 |
| vila | maxb: could you copy it to bzr.builddeps ? | 11:15 |
| vila | maxb: could you copy it to bzr/builddeps ? | 11:15 |
| vila | maxb: or will it break everything there ? | 11:15 |
| maxb | I think it should be pretty safe | 11:17 |
| maxb | The only reason I did not before was that I did not have a need | 11:17 |
| * maxb blinks at bzr-package-importer being a package | 11:18 | |
| maxb | Doesn't it just run from the branch in production? | 11:18 |
| vila | maxb: blame me | 11:18 |
| vila | maxb: I'm creating it right now to track what is ~used in production | 11:19 |
| vila | maxb: it is *not* used by jubany | 11:19 |
| maxb | ok | 11:20 |
| maxb | Well, I don't have any specific objections to copying debhelper 7.0.52 to bzr/builddeps - except that there's been no requirement for it for anything built in the ~bzr PPA so far. Perhaps you could just copy it to vila/pkgimport directly? | 11:21 |
| vila | maxb: yup. I was going to do exactly that | 11:22 |
| maxb | Although, wouldn't your project be easier, and more representative of production, if you based on lucid? | 11:22 |
| vila | maxb: well, jubany is hardy right now... | 11:22 |
| maxb | *blink* | 11:22 |
| maxb | I am confused. Or perhaps I misunderstood. I thought the whole point of considering SRUing pristine-tar to lucid was to get it to jubany | 11:23 |
| jelmer | I don't think there is any intent to do a SRU? | 11:23 |
| vila | meh, no idea, as I said, I'm not aware of the SRU, any pointer ? | 11:23 |
| maxb | Somewhere there was a mention by (I think) james_w that we should do a backport. I filed a backport request bug, which got declined on the basis that it should be a SRU instead | 11:26 |
| maxb | oh, it's in an import failure bug | 11:27 |
| * maxb looks | 11:27 | |
| vila | maxb: jubany currently uses 1.11ubuntu1~0.IS.8.04 | 11:27 |
| jelmer | maxb: are you sure that's for the package importer? | 11:28 |
| maxb | Oh. That's recent, then | 11:28 |
| vila | maxb: yes, less than 24h | 11:28 |
| maxb | Evidently someone got tired of waiting and did an IS backport instead | 11:28 |
| vila | maxb: jam will know the details | 11:28 |
| maxb | bug 695108 | 11:28 |
| ubot5 | Launchpad bug 695108 in lucid-backports "Backport pristine-tar 1.11ubuntu1" [Undecided,New] https://launchpad.net/bugs/695108 | 11:28 |
| maxb | bug 653301 | 11:29 |
| ubot5 | Launchpad bug 653301 in Ubuntu Distributed Development "Packages failing due to pristine-tar not being able to reconstruct their tarball" [High,Triaged] https://launchpad.net/bugs/653301 | 11:29 |
| vila | maxb: right, so s/24/13/ | 11:29 |
| vila | maxb: right, so s/24h/13h/ | 11:29 |
| jelmer | ah, so it affects general bzr-builddeb as well | 11:35 |
| vila | as a related note, should add bzr-builddeb to the bzr ppa(s?) ? | 11:36 |
| vila | s/add/we add/ | 11:36 |
| jelmer | yeah, probably | 11:36 |
| vila | *blinks* | 11:38 |
| vila | It *is* in bzr/ppa but for jaunty/karmic/lucid only... | 11:38 |
| maxb | vila: That typically means that maverick+ is already at the latest upstream release | 11:59 |
| jelmer | it's about time we do another bzr-builddeb release | 11:59 |
| vila | maxb: of course, silly me ! Thanks | 12:00 |
| maxb | Oh, and it's not there for hardy because we're have to backport python-debian, and it didn't seem worthwhile | 12:00 |
| vila | maxb: very good exercise for me :) | 12:02 |
| maxb | meh, hardy is ancient | 12:02 |
| maxb | I wonder when PPAs are discontinue support for Jaunty | 12:03 |
| maxb | ^ going to | 12:03 |
| vila | maxb: but that's what jubany uses *today*, on the other hand may be I should check what is the target for migrating jubany (probably lucid) and just works from there... | 12:04 |
| maxb | What does the importer need builddeb for? | 12:04 |
| jelmer | maxb: it uses a bunch of the tarball importing code from bzr-builddeb | 12:08 |
| maxb | ah | 12:08 |
| maxb | oh, duh, I should have remembered that | 12:08 |
| === oubiwann is now known as oubiwann_ | ||
| vila | ok, confirmed, so I'll target lucid instead and see how it goes | 12:14 |
| deepestthought42 | hi all! I'm evaluating how to best use bzr for revision control at my company. We have a medium sized Visual Studio Project that depends on a few binary files, which seldom change. Is there a way to just copy the files on branch/merge (direction depending on timestamp) commands , without having them version controlled ? Thanks! | 12:19 |
| === oubiwann_ is now known as oubiwann | ||
| jelmer | hi deepestthought42 | 12:34 |
| Tak | deepestthought42: from my research, no current dvcs has "good" handling of large, versioned binary files | 12:34 |
| vila | spiv: are you *sure* 2.1.1 is not relevant when bug #522637 has been fixed in 2.1.3 ? | 12:40 |
| ubot5 | Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637 | 12:40 |
| vila | mwahaha, bzr-builddeb package imported failed leading to out-of-date branches on lp which I use to create my own | 13:05 |
| jelmer | hehe | 13:05 |
| deepestthought42 | I feared as much , but thanks anyway. We'll probably end up putting them under vc. | 13:10 |
| vila | deepestthought42: what do you call large (# and size of the largest) ? | 13:11 |
| deepestthought42 | vila: I do not think I said how large they are ;) but the complete build folder has about 350 MB (Debug, release builds etc.) -- the real "problem" is that changed binaries crop up in the status/diff/merge and they probably slow the system down (not sure on that), | 13:19 |
| vila | oh right, sry, but why don't you *ignore* the binaries (via 'bzr ignore') i.e. don't version them and they won't appear in status/diff/merge | 13:21 |
| deepestthought42 | not all of them need to be build (and can be by all developers) every time but need to be present.; so a copy would suffice for them; we probably will have a folder for the stable binaries and version them and ignore the unstable ones | 13:23 |
| vila | ha... Well, your call, but mixing production and version control has known deficiencies, keep in mind that bzr will change the timestamps of the files it modify so rebuilding an old version should only rebuild the files related to the modified files | 13:26 |
| vila | In practive, devs will have to build the whole project once and then rebuild only the needed parts, even when working on old versions | 13:27 |
| deepestthought42 | vila: you're right, this solution is not without problems -- but when completely ignoring the binaries, we would have to copy them by hand on every branch etc. | 13:42 |
| vila | deepestthought42: you want to try 'bzr switch' then so you can reuse the same working tree for several branches | 13:44 |
| vila | deepestthought42: but you're the judge, just mentioning some different ways to address the issue | 13:45 |
| deepestthought42 | vila: i know and thank you for your help :) | 14:02 |
| === oubiwann is now known as oubiwann_ | ||
| fenrig | Could someone give me good guide on howto set up a bazaar server over http on linux? | 14:37 |
| AfC | fenrig: do you mean "just access a branch over HTTP" or the magic bzr+http integration? | 14:45 |
| fenrig | AfC: uhm bzr+http is where bzr doesn't get whole files but just the diff lines? | 14:46 |
| cbz | no | 14:46 |
| fenrig | :o uhm okay | 14:48 |
| AfC | fenrig: bzr always does that (sic) regardless. | 14:48 |
| AfC | fenrig: ie, it Does The Right Thing™ as it should. You rarely need to second guess it. | 14:48 |
| AfC | fenrig: have you got SSH access to the web server in question? | 14:49 |
| fenrig | AfC: ow okay I compare GIT a lot with BZR. | 14:49 |
| fenrig | AfC: I have yes :) | 14:49 |
| AfC | fenrig: if so, just push your branch there via bzr+ssh:// | 14:49 |
| AfC | fenrig: and then you can just point people at http://... | 14:49 |
| AfC | [there's also a sftp:// for pushing if you can't install Bazaar on the server] | 14:50 |
| fenrig | but then http acts like a read only branch? | 14:50 |
| fenrig | AfC: Do u guys have a super good guide, so I can try it out on a VM? | 14:52 |
| AfC | fenrig: yes | 14:53 |
| fenrig | AfC: :p could you please give it to me :D | 14:54 |
| AfC | I said yes to "read only" | 14:55 |
| jam | maxb, vila: you rang? | 14:56 |
| AfC | Maybe someone else could lend this person a hand? Rumour has it Bazaar has good documentation, but apparently they haven't been able to find it :( | 14:56 |
| === AfC is now known as AfC|zzz | ||
| vila | jam: morning jam, maybe, long ago, let me check :) | 14:56 |
| maxb | jam: There was a discussion about pristine-tar for jubany, but I think we got everything clarified in the end. | 14:56 |
| vila | ha, yeah, pristin... what maxb says :) | 14:56 |
| jam | maxb: lamont was kind enough to backport the natty pristine-tar and install it on jubany | 14:56 |
| jam | it didn't fix everything, but it fixed a lot of them | 14:56 |
| maxb | fenrig: Please clarify: you want to do write-access to branches over http? You want to browse branches like you see at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ? | 14:57 |
| fenrig | maxb: no with loggerhead is fine :) but then I need to have ssh+bzr to commit changes? | 14:58 |
| vila | fenrig: there is nothing to configure for bzr+ssh except for the ssh access | 14:58 |
| jam | vila: looks like it went from ~92 to 14 failing packages | 14:59 |
| maxb | fenrig: Many people prefer bzr+ssh for commit because a ssh-agent is often a more convenient way to cache your authentication safely than a password | 14:59 |
| vila | fenrig: not even a vm, you can try with bzr+ssh://localhost | 14:59 |
| vila | jam: yup, well done, I didn't look closely but had a ~60 rough estimate | 14:59 |
| fenrig | :D okay maybe someone could point me to a good guide on how I have to do this (and please don't give a ubuntu specific cause I use arch linux) | 15:00 |
| vila | fenrig: just try: 'bzr push bzr+ssh://localhost/~/a-new-shiny-one' | 15:01 |
| fenrig | vila: I mean how to setup a server :p | 15:01 |
| vila | fenrig: I meant: just try | 15:01 |
| vila | fenrig: there is no server to set up ! | 15:02 |
| maxb | If you have a running sshd, and bzr installed, that's all you need. | 15:02 |
| maxb | Does anyone fancy dispatching https://code.launchpad.net/~maxb/bzr/ppa-doc-update-2/+merge/48101 to PQM? (it's already approved) | 15:02 |
| fenrig | so let us say :) just to understand i do :o | 15:03 |
| fenrig | bzr push bzr+ssh://root:localhost/~/a-new-shiny-one | 15:03 |
| vila | maxb: done | 15:03 |
| maxb | thanks | 15:03 |
| fenrig | where does the folder goes to? | 15:03 |
| fenrig | in /root/a-new-shiny-one? | 15:03 |
| vila | root:locahost ? You mean root@localhost ? | 15:03 |
| fenrig | vila: yeah sorry XD | 15:04 |
| vila | fenrig: hmm, don't use root for that, just try with your regular user | 15:04 |
| fenrig | yeah I know using root bad idea, but it's for understanding the semantics :o where does the repo folder go to? | 15:04 |
| vila | ~ is replaced with the user home directory yes | 15:05 |
| mgz | jelmer is launching a DoS on my inbox... | 15:06 |
| vila | fenrig: the *branch* is created there, creating a new repository or re-using an existing one (you may want to read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief) | 15:06 |
| vila | mgz: hey ! | 15:06 |
| fenrig | vila: so i could find all the source code files in "/root/a-new-shiny-one"? | 15:06 |
| vila | mgz: yeah, it's a new kind of Ddos: single attacker, multiple targets :) | 15:06 |
| mgz | :) | 15:07 |
| vila | fenrig: no, you won't find the working tree, only the history (branch [+ repository]) | 15:07 |
| mgz | maybe I should blame launchpad instead, does it really need to send me email for tag changes. | 15:08 |
| fenrig | vila: how do you mean (your url says: "page does not exist,...") | 15:08 |
| vila | fenrig: most of the time working trees are useless on servers, if you need a working tree there, look for the bzr-push-and-update or bzr-upload plugins depending on your use case | 15:08 |
| vila | fenrig: try again, I copied the URL from my browser | 15:08 |
| fenrig | vila: there was a ")" behind it sorry xD | 15:09 |
| vila | argh, sry for that | 15:10 |
| fenrig | vila: don't mind it :D | 15:13 |
| fenrig | bzr is easier to setup than git isn't it? | 15:17 |
| cbz | yes | 15:20 |
| cbz | mostly | 15:20 |
| cbz | and easier to work with mostly | 15:20 |
| === beuno is now known as beuno-lunch | ||
| fenrig | cbz: the "bzr whoami" command gives you a name on your client :) so If I and my friend use diff whoami's but we use the same ssh user there should still be a difference in bzr? | 16:08 |
| vila | fenrig: whoami is used at commit times, not at push time | 16:16 |
| fenrig | :o so the diff will we marked with the whoami? | 16:17 |
| vila | fenrig: yes, whoami set the committer | 16:17 |
| fenrig | I'm following thui | 16:24 |
| fenrig | *this guide: and he creates a user like this => useradd --create-home --home-dir /var/local/bzr --shell /usr/lib/sftp-server bzr (on ubuntu) | 16:25 |
| fenrig | why is he setting the home-dir to be /var/local/bzr? | 16:25 |
| fenrig | http://wiki.flexion.org/BazaarServer.html | 16:25 |
| vila | fenrig: no idea, but given he mentioned hardy and doesn't use the smart server, I'll forget about it | 16:26 |
| fenrig | vila: :o where do I have to find a proper guide then? | 16:27 |
| vila | fenrig: you can use bzr over sftp, but you don't have to. | 16:27 |
| vila | nowhere | 16:28 |
| vila | there is no guide to setup an ssh smart server because there is no setup | 16:28 |
| vila | as maxb said earlier: install sshd and bzr and you're done | 16:28 |
| fenrig | yeah okay :o | 16:28 |
| fenrig | but I want to make one bzr ssh user for this :o | 16:29 |
| vila | from there it's only ssh config, nothing specific to bzr (at least to start with) | 16:29 |
| fenrig | called (tadam) bzr | 16:29 |
| vila | jfdi | 16:29 |
| vila | it's not a bad idea as you will be able to set its .ssh/authorized_keys to control who can push there | 16:29 |
| === Meths_ is now known as Meths | ||
| fenrig | when doing "bzr push bzr+ssh://bzr@192.168.56.101/~/a-new-shiny-thingy-one" | 16:48 |
| fenrig | gives me a : "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if ..." | 16:49 |
| fenrig | but loggin in with | 16:49 |
| fenrig | ssh bzr@192.168.56.101 works perfectly :o | 16:49 |
| vila | fenrig: try 'ssh -vv bzr@192.168.56.101' to debug ssh issues | 16:49 |
| vila | ha, hmm | 16:50 |
| fenrig | vila: ssh -vv bzr@192.168.56.101 works :o logging in and all :o | 16:53 |
| fenrig | vila: but I'm using a modified "shell" => /usr/lib/ssh/sftp-server | 16:54 |
| vila | don't do that then | 16:55 |
| vila | bzr will send the right ssh command, you're getting in its way here | 16:55 |
| fenrig | vila: what's the command to change the shell of a user XD | 16:55 |
| vila | how did you modify the shell ? | 16:56 |
| fenrig | u configured it using adduser | 16:56 |
| fenrig | *I | 16:56 |
| fenrig | (sorry) | 16:56 |
| vila | by following the guide I told you was wrong ? :D | 16:57 |
| fenrig | I only followed it on the adding bzr user :$ | 16:58 |
| vila | dunno the specific command on your os, *I*'d modify it by editing /etc/passwd | 16:58 |
| vila | or you can delete the user and re-create it or create another one | 16:58 |
| fenrig | vila: change it to /bin/bash? | 16:59 |
| vila | whatever is the default on your system | 16:59 |
| === beuno-lunch is now known as beuno | ||
| jam | vila, fenrig: the command is often just "chsh" for change shell | 17:08 |
| jam | You often can run chsh without needing root | 17:08 |
| jml | jelmer: are you retagging all of the bugs? | 17:08 |
| jelmer | jml: I'm tagging the ones that haven't been tagged yet and closing/duping where possible | 17:09 |
| jml | jelmer: ahh, ok. | 17:09 |
| jelmer | jml: Sorry about the mail. I'm sure you get plenty already ;) | 17:10 |
| vila | . o O (Yeah, that's the idea, bounce them all to jml !) | 17:10 |
| jml | jelmer: no worries. it's just an unusually high number today | 17:11 |
| jelmer | vila: at least he's somebody who can make sure that launchpad bug notifications get fixed :) | 17:12 |
| vila | jelmer: you get the idea ;) | 17:13 |
| vila | james_w: ping | 17:13 |
| james_w | hi vila | 17:13 |
| vila | james_w: hey ! wow, that was fast ;) | 17:14 |
| james_w | I've been sitting here all day waiting for your ping | 17:14 |
| vila | I've set up a local package importer (with --no-push), and I'm trying to add some packages to it | 17:14 |
| vila | :) | 17:14 |
| vila | I tried add_import_jobs.py but it timeouts | 17:15 |
| james_w | times out doing what? | 17:15 |
| vila | so my question is: is there another way to add a package (a single one to start with :) | 17:15 |
| james_w | ./requeue_package.py should do it | 17:15 |
| vila | it says package has not failed, oh, --force ? | 17:16 |
| james_w | yeah | 17:16 |
| vila | yeah ! | 17:16 |
| vila | james_w: thanks, I'm unblocked | 17:16 |
| cr3 | how can I branch a project in launchpad on system that doesn't have any access to bazaar.launchpad.net? if I can access the system by ssh, can I push a local branch to the system in a way that can be merge on the same remote system later? | 17:17 |
| james_w | cool | 17:17 |
| vila | cr3: if you have an ssh access to a system that have an ssh access to b.l.n, why not set up an ssh tunnel ? | 17:21 |
| cr3 | vila: I did that once, I was hoping for another solution :) | 17:22 |
| fenrig | vila: changing shell worked :D | 17:23 |
| vila | cr3: hehe :) | 17:23 |
| vila | fenrig: finally ! | 17:23 |
| vila | cr3: so, anyway, as long as you do the merge on 'system' you can still push there from wherever works for you | 17:23 |
| vila | cr3: you don't need a working tree in the branch you're pushing to as long as you have one where you merge this branch | 17:25 |
| vila | s/you don't need/don't use/ | 17:25 |
| cr3 | ssh -g -R 50022:bazaar.launchpad.net:22 system; bzr branch bzr+ssh://localhost:50022/... | 17:32 |
| vila | james_w: add_imports_jobs.py is the canonical way to bootstrap the importer or something else ? | 17:47 |
| james_w | vila, that's what adds all the jobs as new packages are uploaded :-) | 17:47 |
| vila | james_w: so it's run from a cron job ? | 17:47 |
| james_w | yep | 17:47 |
| vila | ok | 17:48 |
| vila | oooooh here is the crontab :) | 17:49 |
| fenrig | howdo I download a full branch? | 18:01 |
| fenrig | no with pull right? | 18:01 |
| beuno | fenrig, "bzr branch" | 18:05 |
| fenrig | thx :D | 18:07 |
| bregma | hey all, I keep having a problem with bzr merge-upstream deleting my debian directory in my packaging branch ... any ideas what I've done wrong? | 19:00 |
| maxb | bregma: It sounds like the best way to explain would be to provide instructions for someone to repeat your steps | 19:04 |
| bregma | hmm, okay, I'll try to describe what I've done... | 19:05 |
| bregma | I have a packaging branch for my package that I created by branching my package, then I added packaging (the debian/* files) and committed... | 19:08 |
| jelmer | bregma: does your previous upstream revision perhaps contain the debian/ directory? | 19:08 |
| bregma | .. I then did a bzr mu, which kindly removed and readded all my upstream files and updated the debian/changelog... | 19:09 |
| bregma | .. debcommit, fix some packaing problems, debcommit, good to go | 19:10 |
| fenrig | should I add my user for bzr+ssh to the group users or should I create a new group for it (bzr for example)? | 19:11 |
| bregma | ... now, I have a new upstream release... I use uscan to get the tarball, then do a bzr mu, referencing my upstream repo, and the mu removes the debian directory and fails because there is no debian directory | 19:11 |
| bregma | I have other projects that use bzr mu OK, but I tried bootstrapping this one on my own and now I get fail | 19:15 |
| fenrig | should I add my user for bzr+ssh to the group users or should I create a new group for it (bzr for example)? | 19:15 |
| fenrig | Hi :o | 19:21 |
| fenrig | how do i specify the port if the port of ssh is another then the default (22) | 19:21 |
| fenrig | bzr --create-prefix bzr+ssh://bzruser@192.168.1.1:8888/~/project ? | 19:22 |
| fenrig | I've got it sorry xD | 19:23 |
| maxb | bregma: It would be a lot easier to understand if you just pointed us to the branch and tarball in question | 19:24 |
| bregma | maxb, indeed, branch lp:~utouch-team/utouch-compiz/ubuntu and use uscan to grab the tarball | 19:27 |
| bregma | ... and the upstream branch is lp:utouch-compiz | 19:29 |
| maxb | bregma: ok, could you say the exact bzr mu command you are running? | 19:31 |
| maxb | Well, first things first, this packaging branch is pretty screwed up | 19:34 |
| maxb | In fact, I think you should throw this packaging branch away and start afresh | 19:36 |
| bregma | heh, OK, how should I start? | 19:37 |
| maxb | Was 0.1.1-0ubuntu1 an actual upload to a PPA or something? | 19:39 |
| bregma | yes | 19:39 |
| bregma | .. except UNRELEASED was tweaked to natty for the PPA upload | 19:40 |
| maxb | That shouldn't be possible with a debian/change.... ah | 19:40 |
| maxb | OK, so here's what I would do | 19:40 |
| maxb | I'd start a new branch branching from -r tag:v0.1.1 of the upstream branch | 19:40 |
| maxb | I'd use bzr import-dsc to import the 0.1.1-0ubuntu1 package precisely as it is in the PPA | 19:41 |
| maxb | then I'd check the tags and ensure that the imported package was tagged "0.1.1-0ubuntu1", and the upstream version was tagged "upstream-0.1.1" -- probably needing to add that second one manually | 19:42 |
| maxb | At that point, I'd manually copy across the debian/ directory from the old packaging branch, and commit those changes | 19:42 |
| maxb | And *then*, I'd go to do a merge-upstream, and expect it to work | 19:42 |
| maxb | oh, and when I copied across the debian/ directory, I'd avoid reverting the old changelog entry to UNRELEASED, just for clarity's sake | 19:44 |
| bregma | OK, I am trying all that, I will post results | 19:44 |
| bregma | ok, good news, I merged my new release OK and can continue from here, but I still have a problem bootstrapping a packaging branch for use with merge-upstream ... is there a godd resource for that that somewhere that I've missed? | 19:57 |
| maxb | The simplest way that I know of is to simply branch the upstream branch at the last release, do "bzr tag upstream-VERSIONNUMBER", and add and commit a debian/ dir. | 20:03 |
| speakman | is it possible to create a set of patch files, one for each commit, of the last five commits? | 20:22 |
| maxb | for i in `seq 1 5`; do bzr diff -c -$i > patch-$i.patch; done | 20:28 |
| speakman | omg... | 20:28 |
| speakman | then it won't be named by commit message? | 20:29 |
| jelmer | speakman: generally when transferring revisions it's down as a bundle file, which can contain multiple revisions and their metadata | 20:30 |
| speakman | jelmer: how do I cherry-pick commits into (or out of) a bundle? | 20:32 |
| speakman | and how do I inspect a bundle? | 20:32 |
| jelmer | speakman: generally you'd pull it into a branch and then work from that branch | 20:33 |
| jelmer | there has been some work to be able to treat a bundle as a branch as well, but that's nowhere near complete yet | 20:33 |
| speakman | ok | 20:33 |
| speakman | how do I uncommit a specific commit? | 20:33 |
| jelmer | speakman: "bzr uncommit" | 20:34 |
| speakman | any commit? | 20:35 |
| jelmer | you can only uncommit from the tip | 20:35 |
| jelmer | with -r you can uncommit until a specific revision | 20:35 |
| speakman | can I cherry pick from a branch? | 20:42 |
| speakman | without merge is preferred | 20:42 |
| jelmer | you can cherrypick a revision with "bzr merge -c REV" | 20:43 |
| mwhudson | jelmer: wow, i have a LOT of bugmail from you! | 20:50 |
| jelmer | mwhudson: sorry! | 20:51 |
| mwhudson | it's ok, it's easy to skim :) | 20:51 |
| speakman | maxb: crazy, your one-liner created *large* patch files. But doing exactly the same manually works. | 21:33 |
| mwhudson | some of my branches on launchpad appear to have become corrupted | 21:38 |
| mwhudson | pushing fails with | 21:38 |
| mwhudson | bzr: ERROR: Server sent an unexpected error: ('error', "Cannot lock LockDir(lp-87934032:///~mwhudson/offspring/path-independence/.bzr/branchlock): File exists: u'/srv/bazaar.launchpad.net/mirrors/00/06/3f/75/.bzr/branch/lock': [Errno 17] File exists: '/srv/bazaar.launchpad.net/mirrors/00/06/3f/75/.bzr/branch/lock'") | 21:38 |
| mwhudson | info says this: | 21:38 |
| mwhudson | Shared repository with trees (format: unnamed) | 21:38 |
| mwhudson | Location: | 21:38 |
| mwhudson | shared repository: bzr+ssh://bazaar.launchpad.net/~mwhudson/offspring/path-independence/ | 21:38 |
| mwhudson | does this ring any bells with anyone? | 21:38 |
| jelmer | mwhudson: that suggests the branch has disappeared | 21:39 |
| jelmer | what happens if you remove that lock? | 21:39 |
| mwhudson | jelmer: the .bzr/branch directory is there | 21:39 |
| jam | mwhudson: but if the 'lock' directory is missing, we'll fail oddly trying to create something underneath it | 21:39 |
| jam | (namely .bzr/branch/lock/pending-XXXX eventually renamed to .bzr/branch/lock/held) | 21:39 |
| mwhudson | jelmer: when i fixed another branch by rmtree-ing .bzr/branch/lock with hitchhiker, it worked | 21:39 |
| jam | mwhudson: rmtreeing everything *under* lock seems ok | 21:40 |
| mwhudson | jelmer: i guess _something_ has gone missing which makes bzr think there is no branch there | 21:40 |
| jam | but deleting 'lock' itself is dangerous | 21:40 |
| mwhudson | but in fact, there are bits of a branch there | 21:40 |
| jam | mwhudson: right, I think the branch is still there, just that the lock dir is gone, and we don't create it on demand | 21:40 |
| mwhudson | jam: lock is empty | 21:40 |
| jam | but it does exist? | 21:40 |
| mwhudson | jam: i think you're reading the error backwards | 21:40 |
| jam | mwhudson: it says "FileExists" but I don't trust our error codes for many things | 21:41 |
| mwhudson | the error is complaining that the lock dir is already there when it tries to create it | 21:41 |
| mwhudson | jam: oh heh | 21:41 |
| mwhudson | jam: the lock dir is there, yes | 21:41 |
| mwhudson | what has to be there for bzr to think there's a branch there? | 21:41 |
| mwhudson | .bzr/branch/format is there | 21:41 |
| spiv | The ".bzr/branchlock" part of that error is intriguing. | 21:42 |
| mwhudson | as is | 21:42 |
| mwhudson | branch.conf | 21:42 |
| mwhudson | format | 21:42 |
| mwhudson | last-revision | 21:42 |
| mwhudson | lock | 21:42 |
| mwhudson | tags | 21:42 |
| jam | mwhudson: yeah, I'm in on sftp right now | 21:42 |
| mwhudson | spiv: hm yeah | 21:42 |
| spiv | That's possibly just an error not being serialised for the wire very well, though. | 21:43 |
| poolie | hi spiv, jelmer, | 21:44 |
| mwhudson | spiv: yeah, locking over http appears to get the same sort of erro | 21:44 |
| jelmer | 'morning spiv, poolie | 21:44 |
| mwhudson | russel appears to have had the same issue as me though: http://osdir.com/ml/bazaar/2009-10/msg00072.html | 21:44 |
| mwhudson | ah | 21:45 |
| mwhudson | the branch is stacked on a branch that has changed url | 21:45 |
| mwhudson | i suggest the error reporting is not perfect here? | 21:46 |
| jelmer | mwhudson: you have high standards for error messages. | 21:50 |
| speakman | Is it "bzr rewrite" or "bzr rebase" these days? | 21:57 |
| poolie | jelmer, you flooded my mailbox :) | 21:58 |
| speakman | Now I've moved some lines in a file, but bzr think I've moved all the other lines which makes a very confusing diff. How can I change how bzr detects changes? | 22:03 |
| poolie | speakman, it prefers to synchronize on unique or unusual lines | 22:04 |
| speakman | but it doesn't reflect my actual change | 22:04 |
| speakman | is there a way to change the behavior+ | 22:05 |
| jelmer | speakman: bzr rewrite | 22:05 |
| poolie | not built in | 22:05 |
| poolie | you could use an external diff | 22:05 |
| jelmer | poolie: I get that a lot today :) | 22:05 |
| vila | jelmer: I caught up, send me more :-P | 22:09 |
| vila | spiv: in case you missed it: | 22:16 |
| vila | spiv: are you *sure* 2.1.1 is not relevant when bug #522637 has been fixed in 2.1.3 ? | 22:16 |
| ubot5 | Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637 | 22:16 |
| jelmer | vila: hehe | 22:16 |
| jelmer | vila: Thanks for those followups, btw | 22:16 |
| vila | jelmer: thanks to you for the triaging ! | 22:17 |
| mgz | I wrote an imap script in the end, to keep up... | 22:23 |
| mkanat | poolie: Hey, I finally wrote up that email about my community research as a blog post: http://www.codesimplicity.com/post/open-source-community-simplified/ | 22:26 |
| peitschie | mkanat: thats a very nice write-up! | 22:33 |
| mkanat | peitschie: Thanks!! :-) | 22:33 |
| peitschie | mkanat: out of interest.... how long did it take to put together all the data and do the analysis? | 22:34 |
| mkanat | peitschie: For the Retaining part, I'd say a few weeks. | 22:34 |
| mkanat | peitschie: A lot of the graph analysis I did in one day, but then correlating it to what was happening at the time was more difficult. | 22:34 |
| mkanat | I also generated the graphs in a *lot* of different ways to make sure that I wasn't mis-reading the data. | 22:35 |
| mkanat | peitschie: The "removing the barriers" stuff I'd say was more an obvious fact that just became apparent after 5 years on the project and everybody being confused about how they should start. | 22:37 |
| poolie | jelmer, i was wondering how you were retagging things, and how/whether you found it worthwhile | 22:39 |
| jelmer | poolie: the main reason I'm retagging is to get a bit of an idea of what's still out there in terms of bugs and to make it easier to find related bugs when working on a specific topic later. | 22:41 |
| jelmer | poolie: I'm mainly tagging based on the top-level commands in which something occurs, if that's significant or otherwise the protocol / format / platform that it's related to. | 22:43 |
| poolie | are you using the web ui? | 22:43 |
| poolie | i think the tags are accurate and useful | 22:43 |
| poolie | i have mixed feelings about whether it's worth going through and gardening them | 22:43 |
| jelmer | As well as a few overall themes (udd, ui, foreign, ...) | 22:43 |
| poolie | but as a way to page it into your head it's quite good | 22:43 |
| jelmer | poolie: I've got a lplib script that finds interesting bugs for me to look at, and feeds them to chromium | 22:44 |
| poolie | ah, interesting | 22:45 |
| poolie | can you share it, maybe on launchpad@lists? | 22:46 |
| jelmer | sure | 22:46 |
| jelmer | it's only 5 lines though, so not terribly interesting :) | 22:46 |
| poolie | it's just "all bugs" or "bugs without tags?" | 22:46 |
| AfC | mkanat: Excellent post. I have passed it along and have already started thinking about what we can apply to our project. | 22:46 |
| poolie | or you have some local state of ones you're already seen? | 22:46 |
| mkanat | AfC: Awesome, thank you! :-) | 22:47 |
| AfC | mkanat: My work is an order of magnitude smaller, but I've observed similar patterns. | 22:47 |
| poolie | jam: https://bugs.edge.launchpad.net/kanban | 22:47 |
| * mkanat nods. | 22:47 | |
| jelmer | poolie: it's bugs without interesting tags (uninteresting tags being things like "apport") | 22:47 |
| mkanat | AfC: I think it's macrocosmic and microcosmic too. | 22:47 |
| mkanat | AfC: You could probably apply it to "the open-source community as a whole," too. | 22:47 |
| AfC | mkanat: the one I found particularly bell-ringing was "what can I do", and I'm not sure we actually answer that | 22:47 |
| AfC | mkanat: barrier to entry stuff was a big deal early on when I was learning to be a maintainer, too | 22:48 |
| mkanat | AfC: Yeah, for me too. :-) | 22:48 |
| AfC | No one ever tells you abut that part | 22:48 |
| mkanat | AfC: Yeah. I think the only reason I became a long-term part of the project was that I entered with a defined long-term goal. | 22:48 |
| mkanat | That was my own goal. | 22:48 |
| poolie | jelmer, and then you just get 20 browser tabs or whatever to overlap the page load times? | 22:49 |
| jelmer | poolie: More like a 100, but yeah :) | 22:49 |
| mkanat | AfC: Also, I was naturally very meticulous and willing to accomplish that long-term goal as a series of smaller steps. | 22:49 |
| AfC | mkanat: (not horn blowing) the second half of http://blogs.operationaldynamics.com/andrew/software/java-gnome/love-your-work.html you'd see that I have quite the "high" standard for getting code in, and you can imagine the knock on effect of that. | 22:49 |
| mkanat | AfC: Hahaha, I totally do too! | 22:50 |
| mkanat | AfC: People have often complained that the review process was too hard. But nobody complaints that the code sucks, anymore. So.... | 22:50 |
| mkanat | AfC: And as I said in the blog, nobody cited the *difficulty* of the process as their actual reason for *leaving*. | 22:50 |
| AfC | mkanat: one of my problems (I think I will blog this today) is that people turn up "what can I hack on" and I tend to reply "um, maybe you should try *using* the library first. Then we can talk about what you might do to help improve it" | 22:50 |
| AfC | mkanat: yes, that was interesting too | 22:51 |
| AfC | mkanat: though in the Apache world, no one has any difficulty with code review at all. So sometimes people don't expect pushback. Anyway. | 22:51 |
| mkanat | AfC: Ahh. :-) | 22:51 |
| mkanat | AfC: Yeah, I do think that developers should be users first. | 22:51 |
| AfC | mkanat: I'm pretty happy not to follow the Apache worldview, but it does have knock-on consequences | 22:51 |
| mkanat | AfC: Yeah. | 22:52 |
| mkanat | AfC: The system we have in Bugzilla is that certain people can CTR in modules that they "own", but everybody else, it's RTC. | 22:52 |
| mkanat | (For everybody else in the channel who doesn't work on Apache, that's "Commit Then Review" vs "Review Then Commit".) | 22:53 |
| mkanat | Also, our stable branches are always RTC. | 22:54 |
| AfC | Interesting difference in the 3rd generation DVCS world: it's commit, then submit for review, then merge[d by maintainer] | 22:58 |
| AfC | (==RTC, but :)) | 22:58 |
| jam | mkanat: interestingly, people *have* cited the difficulty of the process as the reason for leaving the launchpad group | 23:03 |
| jam | :) | 23:03 |
| mkanat | AfC: Haha, yeah. | 23:03 |
| mkanat | jam: That's interesting. I would have dug a bit and asked them if their reviews had been *faster* if they'd have felt differently about it. | 23:03 |
| mkanat | I did quite a bit of responding to the survey answerers to understand everything about what they were saying. | 23:04 |
| jam | mkanat: as one of the outsiders suffering the q, reviews is one thing, actually getting the whole steps from 'write some code' until 'it is deployed in production' can be a huge q of things. | 23:04 |
| jam | depends on the size of the hack | 23:04 |
| mkanat | jam: Yeah, I certainly found that frustrating, when trying to get loggerhead deployed on LP. | 23:05 |
| mkanat | jam: I think the whole process of submission to "get it into the product" is what needs to be sped up for every project, ideally. | 23:05 |
| jam | mkanat: right. because even if I hack on Evolution or whatever, how long before I actually get to use that on my machine... | 23:06 |
| jam | (without having to run manually compiled binaries indefinitely.) | 23:06 |
| mkanat | jam: Totally. | 23:06 |
| mkanat | jam: It's easier for something written in a dynamic language. | 23:06 |
| mkanat | jam: Particularly for a web app that people can run themselves. | 23:07 |
| mkanat | jam: They can just "bzr pull" and they have their fix. | 23:07 |
| jam | mkanat: a lot of that depends on the design of the app, and how it can be run | 23:07 |
| jam | run from source | 23:07 |
| mkanat | But even in that case, getting the actual release out is a big deal. | 23:07 |
| mkanat | jam: Yeah, totally true. | 23:07 |
| jam | needs to be configured and installed, etc. | 23:07 |
| mkanat | jam: That's one reason why I've always worked to make it easier and easier to install Bugzilla, too. | 23:07 |
| mkanat | jam: But something like bzr or launchpad, you realistically need to see a release before you can actually use your feature. | 23:20 |
| jam | mkanat: I run from bzr.dev constantly | 23:22 |
| jam | but launchpad def needs a rollout | 23:22 |
| mkanat | jam: Yeah. | 23:22 |
| mkanat | jam: Although most people aren't going to use an unstable version of a VCS, because it's so important. | 23:22 |
| dev001 | hi. i'm using lp:bzr/2.3. today's update of plugins squawks abt 'Installed Bazaar version 2.3.0dev6 is too old to be used with plugin "Bzrtools" 2.4.0.', where I've been tracking lp:bzrtools. so, a switch to 'other' bzrtools branch is called for, i s'pose. which branch? | 23:23 |
| dev001 | ping abentley | 23:25 |
| abentley | dev001, pong | 23:25 |
| dev001 | abentley: hi. ^^^ re: "your" (well, at least you're the maintainer :-) ) bzrtools ? | 23:26 |
| dev001 | am i stuck 'inbetween' API upgrades, or is a branch switch called for? | 23:26 |
| abentley | dev001, if you want to track trunk branches, you should track both the trunk of bzr and bzrtools. | 23:26 |
| dev001 | abentley: nah, i got warned off bzr trunk a while ago. so if i'm tracking bzr/2.3, which bzrtools? | 23:27 |
| dev001 | trunk worked for awhile ... | 23:27 |
| dev001 | but, apparently no longer | 23:27 |
| abentley | dev001, I happen to be in the middle of creating a 2.3 branch, but I don't guarantee I'll do that for future releases. | 23:28 |
| abentley | dev001, if you're not tracking trunk, you might be better off with packages. | 23:29 |
| dev001 | abentley: your point's noted. but a number of issues were addressed solved in bzr/2.3 for me, per admonition from in here. or are you suggesting packages for *plugins/extension* with bzr/2.3 branch? | 23:30 |
| poolie | hi abentley, afc, mkanat | 23:30 |
| mkanat | Hey poolie. :-) | 23:30 |
| abentley | dev001, I'm suggesting packages for bzr 2.3 and bzrtools. | 23:31 |
| abentley | poolie, hi. | 23:31 |
| dev001 | abentley: hm. catch22, then. | 23:31 |
| abentley | dev001, why? | 23:32 |
| dev001 | abentley: simply (admittedly, naively), the move from bzr pkgs to bzr/2.3 branch was something i did cuz told in here to do so (whining abt some such problem; the migrate fixed it). | 23:33 |
| dev001 | so prior-necessity dictates (dictated?) the bar/2.3 branch | 23:34 |
| dev001 | er, bzr | 23:34 |
| abentley | dev001, I don't think that packages of bzr 2.3 would introduce any problems that the 2.3 branch doesn't have. | 23:34 |
| abentley | dev001, anyhow, lp:bzrtools/2.3 now exists.. | 23:34 |
| dev001 | abentley: heh, well there's THAT solution! thanks :-) | 23:35 |
| abentley | dev001, np | 23:36 |
| * dev001 appreciates NOT having to use git muchly! ;-) | 23:37 | |
| dOxxx | jelmer: I think I've received nearly a 1000 emails today, courtesy of you via launchpad. | 23:51 |
| * maxb wonders if poolie is still around? | 23:55 | |
| maxb | If so, could you nod at https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885 and possibly send it to PQM? | 23:56 |
| poolie | maxb, hi | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!