| upmauro | alguem fala portuguẽs e pode me ajudar ? | 01:34 |
|---|---|---|
| === frakturfreak_ is now known as frakturfreak | ||
| === ereslibre_desk is now known as ereslibre | ||
| === ereslibre is now known as django | ||
| === django is now known as ereslibre | ||
| maxb | ouch. | 15:21 |
| * maxb gazes sadly on the number of plugins complaining about api versions against bzr.dev | 15:21 | |
| maxb | We really need a better way for handling this | 15:22 |
| maxb | Why was bzrlib.api_minimum_version bumped already? | 15:28 |
| aquarius | I'm trying to branch https://code.launchpad.net/~lemoncouch/dexter-rolodex/experimental-u1-support, but when I try "bzr branch lp:~lemoncouch/dexter-rolodex/experimental-u1-support", I get bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~postler/dexter-rolodex/dexter/". | 15:46 |
| aquarius | Possibly this means that that branch was stacked onto a branch that no longer exists? If so...how do I get the code? confused | 15:47 |
| mgedmin | I might be wrong, but I think the only way is to ask the user 'postler' to resurrect his branch | 15:50 |
| aquarius | that's unfortunate :( | 15:50 |
| mgedmin | this happened to me once, when I changed branch ownership | 15:50 |
| mgedmin | all branches that were forked from my branch became broken | 15:50 |
| mgedmin | I had to clone the main branch back to the old url | 15:51 |
| mgedmin | I'm pretty sure this is a launchpad bug, maybe fixed, maybe not yet | 15:51 |
| mgedmin | #launchpad is probably a good place to talk about this | 15:51 |
| aquarius | may give that a shot :) | 15:54 |
| maxb | I know this problem well | 15:55 |
| maxb | let me look at the branches concerned | 15:55 |
| maxb | Yes, it's a classic case of the usual launchpad bug | 15:56 |
| maxb | we need ~lemoncouch or an admin to fix the stacking location in their branch | 15:56 |
| aquarius | that's what I was thinking | 15:57 |
| maxb | (or if you want the content right now, it's possible to copy the branch locally via sftp, and fix the stacking location locally) | 15:57 |
| aquarius | well, atm I'm just browsing the diff on LP, which gives me the info I need | 15:58 |
| maxb | I've filed https://answers.launchpad.net/launchpad/+question/141568 to have the admins fix the branches. It'll probably happen on Monday or Tuesday | 16:05 |
| dOxxx | anybody know if vila will be on today? | 16:28 |
| james_w | dOxxx, maybe, depends if he spends all day looking round Dallas I guess | 16:33 |
| dOxxx | thanks | 17:09 |
| lifeless | he's on now :) | 17:12 |
| mgedmin | so, I'm trying to learn how to use shared repositories (because waiting for the network all the time sucks) | 17:30 |
| mgedmin | I have a mirror branch foo of lp:foo, and I accidentally pushed a different branch into this local one | 17:30 |
| mgedmin | how can I reset it to be a pure mirror of lp:foo again? | 17:30 |
| === Ursinha-afk is now known as Ursinha | ||
| mgedmin | bzr pull --overwrite? | 17:31 |
| === marienz_ is now known as marienz | ||
| maxb | yes, but that doesn't have anything to do with shared repositories | 17:38 |
| dev001 | hi. i just installed bzr trunk, as well as lp:bzr-svn. when i exec any cmd, i'm getting: "Unable to load plugin 'svn'. It requested API version (2, 3, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 0)". | 17:47 |
| dev001 | is this likely a bug, or simply an out-of-sync/un-updated repo? | 17:47 |
| maxb | dev001: bzr.dev recently moved to a new API version declaration. Almost every plugin that checks for API versions strictly will report errors | 17:52 |
| maxb | vila: You there? | 17:52 |
| vila | maxb: yup | 17:52 |
| maxb | vila: When opening 2.4, did it really make sense to bump api_minimum_version already? | 17:53 |
| vila | maxb: by 2 votes in favor one against and 2 abstain | 17:53 |
| maxb | "yuck" | 17:53 |
| vila | maxb: an option was to wait for one month | 17:53 |
| maxb | I suppose I should broach a discussion on changing our API policies to suck less | 17:54 |
| vila | maxb: but since we're sprinting, the expectation was that 1) most plugins can be fixed quickly, 2) this gives a slight incentive to release stable versions (and associated branch/series) compatible with 2.3 | 17:54 |
| vila | maxb: now would be a good time for this, yes | 17:55 |
| dev001 | maxb: sounds like switching to lp:bzr/2.3 is, then, the sane thing to do for "the resst of us" ... at least for now? | 17:55 |
| maxb | The key to which is "Are we really going to do anything at all in 2.4 which will break plugins built against 2.3?" | 17:55 |
| vila | maxb: keeping in mind that plugins that check *strictly* are *asking* about the observed result... | 17:56 |
| maxb | dev001: tracking lp:bzr is only for people who *want* the bleeding edge ;-) | 17:56 |
| vila | dev001: or use a PPA | 17:56 |
| dev001 | thx! | 17:57 |
| vila | maxb: as far as I'm concerned, I think that bumping the api is the best way to make it painful *now* to push plugin authors to do the right choice (and there are really many ways to deal with it) | 17:57 |
| vila | maxb: we offer enough different ways to track coherent sets of bzr/plugins for users to *also* make their own informed choice | 17:58 |
| fullermd | Wha? Nobody ever told me I was allowed to be coherent and informed... | 17:59 |
| vila | maxb: and until we have a better way express this compatibility story, I prefer to bump sooner rather than later | 17:59 |
| vila | fullermd: indeed, you're a special case, go get your medics | 17:59 |
| fullermd | Mom always told me I was 'special'... | 18:00 |
| vila | maxb: but anyway, the above was my personal opinion, I'd more than happy to see the topic discussed more broadly | 18:01 |
| vila | s/whatever/I'd be/ | 18:01 |
| dOxxx | vila: hey! | 18:03 |
| dOxxx | vila: are you going to be around for a while today? I'd like to talk about the mergetools stuff. | 18:03 |
| jelmer | dOxxx: he is one the phone :-) | 18:03 |
| dOxxx | ok | 18:04 |
| vila | dOxxx: still otp, but yes I'll be around | 18:18 |
| dOxxx | vila: ok. | 18:21 |
| vila | dOxxx: I'm back | 18:48 |
| dOxxx | vila: hey :) | 18:48 |
| dOxxx | vila: I'm tyring to pick up where I left off on the mergetools stuff | 18:49 |
| vila | dOxxx: cool ! | 18:49 |
| maxb | aarrgh | 18:49 |
| dOxxx | vila: I've replaced the Config.set_merge_tools with set_merge_tool and remove_merge_tool. | 18:49 |
| vila | from the top of my head, I think the main point was about checking the availability of mergetools | 18:49 |
| maxb | my bzr-svn has been doing the same thing over and over because it's not committing its sqlite cache at exit | 18:49 |
| dOxxx | vila: the difference between user-defined merge tools and the known merge tools? | 18:50 |
| vila | dOxxx: right, the fact that if you set known merge tools at a given point it can become obsolete, whereas if you check on demand, you're always right | 18:50 |
| dOxxx | vila: so Config.get_merge_tools and find_merge_tool should only return the user-defined tools? So how then do clients (e.g. qconflicts) find a known merge tool? do they have to query mergetools.known_merge_tools separately? | 18:52 |
| dOxxx | i.e. should Config methods only deal with the contents of the config file? | 18:52 |
| vila | dOxxx: yup, I think qconflicts should query against the potential ones and find which one are available | 18:53 |
| vila | dOxxx: and users should be able to manage the potential ones | 18:54 |
| dOxxx | vila: okay. so I'll add a find_known_merge_tool to the mergetools module, which clients will query Config first and then mergetools.find_known_merge_tool if it wasn't find in the Config | 18:54 |
| vila | dOxxx: yeah, something like that, maybe mergetools.check_availability | 18:55 |
| dOxxx | well, it's meant to return the MergeTool object itself so it can be invoked since that's when it's being called | 18:56 |
| dOxxx | check_availability implies boolean to me, so I'll stick with find :) | 18:56 |
| vila | dOxxx: ECONTEXT, I haven't re-read the proposals yet | 18:56 |
| dOxxx | vila: basically, qconflicts and the commandline stuff are given a merge tool *name* by the user, so they need a function to get the MergeTool object for that name. There has to be one in Config and there will need to be one in the mergetools module to get one of the predefined, i.e. 'known', merge tools, if it's not found in the config. | 18:58 |
| vila | dOxxx: that's it | 18:59 |
| dOxxx | cool | 18:59 |
| dOxxx | I has a plan! | 18:59 |
| dOxxx | :) | 18:59 |
| * vila re-read | 19:01 | |
| dOxxx | vila: I've pushed some changes already but still making the last few changes to separate user-defined and predefined merge tools. | 19:01 |
| vila | so, there is still duplication, remote_merge_tool is not needed now that bzr config is available, | 19:02 |
| dOxxx | vila: it's needed by qconfig | 19:02 |
| vila | put it there then :) | 19:02 |
| dOxxx | vila: but then qconfig has to know that the option is called 'bzr.mergetool.<name>'. That knowledge should be in Config. | 19:03 |
| dOxxx | then if we need to change it, it only has to change in one place | 19:03 |
| vila | not more than knowing that it should call remove_merge_tool | 19:03 |
| vila | dOxxx: we won't add accessors for any and all config variables, that's the point | 19:03 |
| dOxxx | then why aren't we doing file('bazaar.conf').write('blah')? | 19:04 |
| dOxxx | :) | 19:04 |
| dOxxx | oh | 19:04 |
| dOxxx | is this a change in policy? | 19:04 |
| vila | that's where we're heading yes, even if all the pieces are not there yet | 19:04 |
| dOxxx | so really, should I have anything in Config then? | 19:05 |
| vila | but even the current policy only requires get acessors | 19:05 |
| dOxxx | ah | 19:05 |
| dOxxx | so get_merge_tools and find_merge_tool and get_default_merge_tool are ok? | 19:05 |
| vila | get_merge_toolS is more tricky and should stay I think | 19:05 |
| vila | get_default_merge_tool is not needed | 19:06 |
| dOxxx | find_merge_tool is not needed either then | 19:06 |
| dOxxx | since it's pretty simple | 19:06 |
| dOxxx | but it does construct a MergeTool object | 19:06 |
| vila | I'd be ok with find_merge_tool since it handle the fallback to defaults | 19:06 |
| vila | and we don't have that piece yet | 19:06 |
| dOxxx | hmm now I'm a little confused. by defaults you mean the predefined merge tools in mergetools.known_merge_tools, right? | 19:07 |
| vila | exactly | 19:08 |
| vila | now, I see you have MergeTool.is_available, so may be there is a way to get rid of find_merge_tool, not sure | 19:09 |
| dOxxx | find_merge_tool is just looking up a MergeTool object by name | 19:09 |
| dOxxx | either in a Config or, as I was intending to do now, in the predefined list in the mergetools module | 19:09 |
| vila | yeah, I'm still confused about when you check the availability probably | 19:10 |
| dOxxx | that's a function that's on the MergeTool object, once it's been found. | 19:11 |
| vila | yeah | 19:11 |
| dOxxx | so, user selects tool by name through command-line or GUI and says "invoke this!" we have to then find the MergeTool object for that name and then check it's availability before invoking. | 19:11 |
| vila | I think ideally (but not now), I'd like known_merge_tools to be replaced by config options definitions providing the default value | 19:12 |
| vila | yup | 19:12 |
| dOxxx | vila: I see. So config is going to grow a defaults mechanism at some time | 19:12 |
| vila | yup | 19:12 |
| vila | dOxxx: and the lack of it right now is what makes your proposal so hard to land, sorry about that | 19:13 |
| dOxxx | ok, so for the moment, the find_merge_tool function Config will have to fake this defaults mechanism by using the known_merge_tools info in mergetools module. | 19:13 |
| vila | yup | 19:14 |
| dOxxx | okay! | 19:14 |
| dOxxx | I'll go hack on this and get back to you. | 19:14 |
| vila | cool | 19:14 |
| vila | dOxxx: do you think you'll be able to have a look at the osx installers too ? | 19:14 |
| dOxxx | vila: oh yeah, I was wondering what to do about plugin versions there? just look at whatever is current stable? | 19:15 |
| vila | dOxxx: I'm away from home so I can't build the 10.6 one (well, I *could* but there are quite a few hops to reach the right machine :-/) | 19:15 |
| dOxxx | I can do 10.6 no problem | 19:15 |
| vila | dOxxx: yup, making sure it's compatible with 2.3 (but I don't expect many plugins to have been upgraded to 2.4 at this point) | 19:16 |
| dOxxx | vila: ok | 19:16 |
| dOxxx | vila: anything that doesn't have a stable release tarball, I'll just use their trunk tip | 19:16 |
| vila | dOxxx: and then probably posting an excerpt of config.py to list which versions are used so we can nag the plugin authors to create appropriate series or not ;) | 19:17 |
| dOxxx | :) | 19:17 |
| dOxxx | or rather, I'll use the revision number that is currently the most recent on trunk. | 19:17 |
| vila | dOxxx: oh, and I didn't follow closely but should upgrade to qtx.7.y or something ? | 19:17 |
| dOxxx | looks like I should | 19:17 |
| vila | ok, so long compile times ahead for me :-p | 19:18 |
| dOxxx | :) | 19:18 |
| vila | dOxxx: just send me an email when I can pull the latest changes | 19:18 |
| dOxxx | vila: will do | 19:18 |
| vila | dOxxx: my tip is revno 111 so far with 'Release 2.3b4' as the commit message | 19:21 |
| dOxxx | yah I haven't made any changes on that yet | 19:22 |
| === dOxxx is now known as dOxxx_away | ||
| === dOxxx_away is now known as dOxxx | ||
| === r0bby is now known as robbyoconnor | ||
| === cody-somerville_ is now known as cody-somerville | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!