[00:07] jelmer, doesn't like the upgrade :-( [00:07] Noldorin, which upgrade? [00:07] jelmer, to newest bzr-git/dulwich [00:07] Unable to load plugin u'git' from u'C:/Program Files (x86)/Bazaar/plugins' [00:07] bzr: ERROR: exceptions.KeyError: "Key 'git' already registered" [00:08] Noldorin, the bzr log file should have more information [00:09] oh wait; randomly working now hmm [00:09] bzr doesn't like symlinks in program files :O [00:12] jelmer, so a bit more playing around seems to reveal that this problem is due to the fact parent directories are not actually created (added to the git database?) before they get used [00:13] git doesn't track directories period, neh? [00:14] fullermd, hmm, maybe that's the problem then? [00:14] no it doesn't [00:15] Noldorin: With git? One of them anyway ;) [00:15] fullermd, no with this bug jelmer and i are discussing about bzr-git :-) [00:15] fullermd, though i agree, it's a problem with git too hah [00:17] jelmer, thoughts? [00:20] Noldorin, I'm looking [00:20] ok :-) [00:33] right, so it's definitely one of the renames into tests/ failing... [00:34] *continues debugging* [00:35] * jelmer_ writes a testcase [00:44] hi alll, I'm trying to use bzrlib (from python), but I keep getting an unsupported protocol exception. I'm using the remote_branch_url example from http://wiki.bazaar.canonical.com/BzrLib, straight copy-paste. bzrlib.version_info=(2, 4, 0, 'final', 0). Any ideas? [00:46] jelmer_, the minimal mergeset that creates the issue is tests/IrcDotNet/ and tests/TraceAndTestImpactSettings.tracesettings [00:46] there are probably other equivalent minimals [00:47] yshavit: that example lacks this code: "from bzrlib.plugin import load_plugins; load_plugins()" [00:48] Noldorin, thanks [00:48] jelmer_: thanks! is there someone I should email about that? [00:49] yshavit, I'm updating the page [00:50] jelmer_: even better. Thanks for the quick help. [00:50] jelmer, sure. just some more playing around tells me (and trying to create new test branches which i dpush) that it's a highly order-dependent issue [00:51] jelmer, if you're digging through the code right now, i'll be here ready to assist :-) [00:51] (just not sure if there's much more i can do by *myself*) [00:55] Noldorin, thanks [00:56] jelmer, will be here watching TV for the next 2 hours about, so feel free to ping me with progress at any time then [00:56] heh, ok [00:56] I might get some sleep soon and look closer into this tomorrow [00:57] jelmer, heh okay, sure. i will be around tomorrow too [00:57] we are both in European time zones i suppose? [00:58] jelmer_: is there any page that's somewhere between that front page and the autogenerated pydocs? A tutorial-type thing? I can't find one on google. [00:59] yshavit, for the API? Not really. I generally just look at the tests in bzr itself for inspiration [00:59] what are you trying to do? [00:59] jelmer: ah, okay [00:59] jelmer_: for now, just merge. I've got the branch branched locally (through bzrlib) [01:00] jelmer_: but in the larger scope, I'm also trying to teach myself how to fish :) [01:12] jelmer, well, feel free to ping me tomorrow after about 1pm, if that works for you better... [05:12] hi all === maxb_ is now known as maxb [06:10] hi vila [06:22] hey poolie, hi all :) [06:31] jelmer: do we need to follow https://wiki.ubuntu.com/FreezeExceptionProcess for 2.4.1 on oneiric or is there some shortcut since we don't " introduce a new upstream version with new features and/or ABI/API changes" ? [06:31] zzzzzz [06:31] ;) [06:31] :) [06:33] jelmer, poolie: I think we qualify for "FeatureFreeze for bugfix-only updates" which says "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it." [06:33] poolie: by the way, can *you* upload ? [06:33] i probably can, yes [06:33] since you said it was already up i just wanted to understand the situation [06:34] that was a rhetoric question, AIUI jelmer should already have the branch/package ready for that [06:34] i'm not sure if it's more appropriate to request a sync or to merge and upload [06:34] ok [06:34] poolie: justasec, searching the IRC log [06:35] of course xchat history threshold is just where it shouldn't [06:35] vila, so that "biweekly meetings" thread is quite relevant to our discussion last night [06:36] Sep 13 17:30:51 vila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building.. [06:36] oh ok, cool [06:36] poolie: which thread ?!?!?! [06:37] on udd [06:37] you are subscribed? [06:37] AFAIK, yes [06:38] ubuntu-devel@lists.u.c right ? [06:38] no, https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel [06:39] right, both end up in the same mailbox here [06:40] ok [06:40] ... wth, I have a filter for it but I'm not subscribed ??? [06:41] vila, i wouldn't say bug 849715 is a really high priority unless it's trivial [06:41] damn, yes I am subscribed [06:41] Launchpad bug 849715 in bzr Upload plugin "fails when upload_location becomes unreachable and doesn't provide an escape path" [High,Confirmed] https://launchpad.net/bugs/849715 [06:41] classic case of of course per-project priority vs team priority [06:41] poolie: high in the plugin context and yes it's trivial [06:42] I agree it's not high in the team context [06:42] so you've got it? [06:42] i mean, got the mail from the udd list? [06:42] yup [06:42] marked as read [06:43] except for james's one which I didn't recognize as matching your reference [06:44] ok, read, I see your point, and I can only repeat that having goals bigger than bugs but smaller than strategic goals will help [06:46] huh, did james_w moved from UTC+1 tz to UTC-4 tz ? [06:48] hi [06:48] yes, to canada [06:48] so, bug#788072 [06:49] we've got two servers being bitten by it now [06:49] bradm, does it consistently fail? [06:49] oooooh [06:49] did something on this machine change when it started happeing? [06:49] poolie: seems to be consistent [06:50] I can't say if anything changed, its a lp builder so I don't know what else has been going on [06:50] bug #788072 [06:50] Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,Incomplete] https://launchpad.net/bugs/788072 [06:50] there's been general package upgrades, I don't usually use these machines all that often so I can't say when it started [06:50] how urgent is it to fix this? [06:50] we could change it so that it at least doesn't mask the error [06:51] if we try a fix, would you be able to run bzr eg from a branch to see if it fails the same way [06:51] I think its breaking our use of puppet on the boxes, since we've got etc in bzr [06:51] for that matter, can you see if it works the same way with the latest bzr 2.3 from the ppa? [06:51] I can certainly try some stuff [06:52] bradm: AIUI, we have never been able to reproduce it and my last debug attempts with lamont pretty much convinced me it was a weird local install issue [06:53] vila, in the standup yesterday you said something about making udd robust about lp downtime [06:53] vila: fwiw, I don't know if we can rule that out, since these are both lp buildds, its possible there's something local [06:53] poolie: yup, that's my targets for today [06:53] i guess that's https://bugs.launchpad.net/udd/+bug/795321 assigned to jr, not obviously started [06:53] Ubuntu bug 795321 in Launchpad itself "udd importer should make tea while launchpad is down" [High,Triaged] [06:53] bradm: oh, new context then ! Can you add that to the bug ? [06:53] poolie: yup [06:54] i'm not sure that increasing the parallelism is all that important at the moment compared to some specific failures [06:54] this is interesting, one of them is bzr 3.2.1 [06:54] er, 2.3.1 even [06:54] silly fingers [06:55] poolie: you mean bug #724893 ? [06:55] Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893 [06:55] and the other is 2.3.3 [06:55] poolie: the issue here is not to increase parallelism but that this bug can happen *now* triggered by any tweak anywhere [06:56] ok [06:56] does that show up as an actual import failure? [06:56] if so we should be able to measure how many suffer from it [06:56] poolie: what ? bug #724893 ? [06:56] Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893 [06:56] yes, that [06:57] morning all [06:57] poolie: it's not package specific at all, it's a bug in the design and we are lucky that it doesn't trigger more often [06:57] let's finish with bradm first [06:57] bradm, that's worth adding too [06:57] so the short story is, if we have something we think will help, you can deploy and test it? [06:57] poolie: I'd say so, given that the existing bzr stuff is busted [06:58] ok [06:58] i assigned it to the team [06:58] hi jam [06:59] just added a comment about the 2nd server and them being lp buildds [06:59] vila, i know it's not caused by the particular package, but my question is whether the import logs will tell us how often it occurs [06:59] if it's not actually often, it doesn't need to be critical [07:00] ok, I resign, downgrade it to low if you wish, the day we'll encounter it because some totally unrelated optimization make the imports faster... we'll marked it critical [07:01] i'm just trying to understand the situation [07:02] poolie: both mass_import and import_package want to update a db, as of today, there is no contention because imports are slow enough [07:02] increasing parallelism (as I did as an experiment) revealed the bug and made it obvious [07:02] but the bug is there nevertheless [07:03] My 2c, if we don't have to stop everything and work on it, it isn't "Critical", it can be "High", it can be in our "bugs to work on next" list, but that doesn't make it *Critical*. [07:03] I don't think we still have the logs for the last debian massive import where this occured [07:03] I don't think anyone has said it isn't a bug [07:03] or worth fixing, etc. [07:04] jam: you already said that in the comment and I disagreed and still do [07:04] vila: then why aren't you working on it *right now*, if it is critical [07:04] ? [07:04] vila, jam said what? [07:04] If *you* feel it is critical, then certainly it should trump the config stuff you are doing, etc. [07:04] poolie: I said I didn't feel the bug was "Critical" [07:05] vila: I'm not trying to start the argument again. But that is what Critical is supposed to mean. At least in my understanding. [07:05] "This bug should be fixed before all High priority bugs" [07:05] jam, that is what critical ought to mean [07:05] in fact "even ahead of other work that's already in progress" [07:05] to me it means a bug that can break the whole package importer [07:05] we haven't always been great about doing it but we shouldn't dilute it ay further [07:05] and that needs to be fixed to resurrect it [07:09] poolie: anyway, let me know if you need any more info, or have something for us to try [07:10] jam: I didn't start working on it because: 1) you pointed me to wal which is more complicated than a file-based locking, 2) as mentioned repeatedly this doesn't occur *yet* and I see nothing in the pipe that will trigger it (once 2.4 (and its optimizations) is deployed on jubany, I may reconsider) [07:11] bradm, ok, i will, i'm not personally going to start on it now [07:11] vila, il'l see if i can get your config things unblocked soon [07:11] poolie: no worries [07:11] oneiric's borked, biab [07:11] jam: I'd appreciate if you could make more constructive suggestions about config instead of considering a pet project, there are numerous, real and deep issues around this area [07:13] poolie: looks like this bug has been around for a bit and it seems to only be hitting 2 servers, so its not ultra high priority [07:13] ok [07:13] it would be nice to know why only those two [07:13] if you know when the problem started perhaps you can attach the dpkg.log [07:15] poolie: the server I'm seeing started within the last day or so I'm guessing from some puppet stuff [07:16] poolie: but the last thing in dpkg.log was apache stuff about 2 weeks ago [07:16] halp! puppet! [07:16] bradm: why are those builds still using bzr < 2.3.4 (not strictly related but well, who knows, may be some upgrade went wrong) [07:17] vila: I don't know, but they're fully up to date according to the current sources.list on them [07:17] bradm: 8-/ no -updates there ? [07:18] another random lp buildd has 2.3.1 as well [07:18] err wait, what ubuntu release are they based on ? [07:18] vila: hardy [07:18] ha, ok, thanks [07:19] hmm, I think jelmer has backported 2.4 for hardy-cat recently [07:19] these definately have hardy-cat on them [07:19] or is it jelmer_ :) [07:19] interesting, and hardy-cat-buildd [07:20] dunno about that last one but I'm pretty sure jelmer is already trying to address some buildd issues so I think he targeted the right one [07:20] vila: if there is a hardy-cat versoin of 2.4 its not on our servers [07:20] vila: I do see lucid-cat 2.4 [07:21] bradm: https://launchpad.net/~canonical-bazaar/+archive/cat-proposed IIUC [07:22] vila: interesting - I don't know the mechanics by which that makes it into our hardy-cat suites, lamont would know more I'd say [07:23] right, so let's postpone that part of the discussion for when jelmer and lamont are around [07:23] for sure [07:23] I'm just a lowly GSA seeing a problem on one server ;) [07:23] bradm: sure, thanks for chiming in here [07:24] no worries, let me know if you need more info or anything [07:24] bradm: do you have a direct access to one of the failing servers to try some diagnosis ? [07:24] vila: sure [07:24] vila: I'll be EODing shortly, but I can do some stuff [07:25] bradm: no problem, start reading the comments in bug #788072 and see if you can follow the proposed steps starting in comment #2 [07:25] Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Medium,Confirmed] https://launchpad.net/bugs/788072 [07:27] vila: BZR_PDB=1 bzr st looks the same as bzr st [07:27] bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH [07:27] vila: I can't get anything from bzr version or bzr plugins -v other than the error [07:28] good, you're in the right context then (hopefully) [07:28] bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH [07:28] bradm: python -V (just to be sure) [07:29] $ python -V [07:29] Python 2.5.2 [07:29] ok [07:29] bradm: and the python import above ? [07:30] $ PYTHONPATH=/var/lib/python-support/python2.5 python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' [07:30] /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so [07:30] * vila blinks [07:30] and if you remove the PYTHONPATH ? [07:30] $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' [07:30] Traceback (most recent call last): [07:30] File "", line 1, in [07:30] ImportError: No module named _chunks_to_lines_pyx [07:30] $ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' [07:30] Traceback (most recent call last): [07:31] File "", line 1, in [07:31] ImportError: No module named _chunks_to_lines_pyx [07:31] that's the issue, the install is broken [07:31] well [07:31] the install and the context are not what bzr is expected may be more accurate and less offensive ;) [07:32] awesome, I can poke some other servers to see the difference tomorrow [07:32] bradm: find / -name _chunks_to_lines_pyx.so -print ? Or something equivalent [07:32] bradm: but if you can relate this missing files with failing servers, yeah, that would narrow down the problem space [07:33] $ sudo find / -name _chunks_to_lines_pyx.so -print [07:33] /var/lib/python-support/python2.4/bzrlib/_chunks_to_lines_pyx.so [07:33] /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so [07:33] /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so [07:33] /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so [07:34] interesting, similar on another working server except it doesn't have a /var/lib/python-support/python2.4/bzrlib [07:34] if it has python-2.5 we don't care [07:34] right, since we're using python 2.5 [07:34] but the /var/lib/python-support part... I'm not sure we ever search there, let me check [07:35] oho, interesting [07:36] on a working server: [07:36] $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' [07:36] /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so [07:36] python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()' [07:36] $ python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()' [07:36] /usr/lib/python2.5/site-packages [07:37] same on a working system [07:37] on a failing server ? ha, rats [07:38] okey, I've got a 4 year old boy wanting some attention, I'll have to take this up again tomorrow [07:38] bradm: ok, no worries, that may be something in this area, some missing symlink here or there, hard to guess [07:39] bradm: take care of your boy :) [07:39] vila: will do - thanks for the help, its given me somewhere to look :) [07:41] vila, i'm reading the stacks patch now [07:44] poolie: \o/ [08:08] vila, i answered [08:08] can you tell me: why a registry? [08:10] poolie: 1) you asked for it :) 2) it simplifies many issues including centralizing the way to get a stack, overriding by a plugin, etc [08:12] it doesn't address (yet) more convenient ways to build stacks (more on that soon, but roughly a stack is already a list of tuples (store, section_matcher(context)) plus one optional mutable store, to reach one read/write by store we need to centralize the way stores are acquired so they can be shared, the stack registry is a first step [08:12] poolie: i.e. it's harder to track all stores if everybody build stacks at call sites instead of using a registry [08:13] poolie: we've been there (no registry) in other areas and always ended up fixing the issues by introducing a registry, [08:14] the only exception I can think of is transports but we already encountered issues that a registry could address (replacing or behind transport.get_transport) [08:18] why is a registry better for that than just having named functions? [08:19] poolie: because we all agree it was better when we start using registries ? [08:20] started [08:20] uh [08:20] i don't think it's just universally better [08:20] it solves some particular problems [08:20] it's not obvious to me those problems exist in this case [08:21] i don't think people ought to build the stacks inline, but the simplest solution to that seems to be to have functions that build them [08:24] vila? [08:24] poolie: searching the relevant mp [08:27] i need to stop soon [08:27] can we just talk? [08:28] ok [08:28] here is fine [08:29] I can't find it back, but *I* don't care about whether we use a registry or named functions at this point, I seem to recall that you suggested a registry for stacks in some discussion so I took that route [08:29] does accessing branches with bzr+ssh://user:pass@host/ type urls work in the way one might hope? === lool- is now known as lool [08:30] along this route I indeed found that a registry was addressing some issues so I followed up on this route [08:31] from a pure syntactic point of view, as explained in the cover letter, this makes sense too, [08:31] so this proposal is only about introducing the registry [08:32] it doesn't show *how* it helps addressing the other issues to keep it small [08:32] ok [08:32] what are the issues? [08:33] mwhudson: yes [08:33] single point of access to control which stack is returned for a single context (this became a blocker when jelmer mentioned that subversion.conf was already implementing some additional feature that requires more flexibility when building branch stacks) [08:34] this can addressed differently but since this is now needed *and* that a stack registry provides *one* way to address it, I just went ahead [08:34] s/can/can be/ [08:34] jam: thanks [08:34] single point of access to control which stores are used so they can be shared, [08:35] mwhudson: of course, it leaves your password in bash history, kills babies, etc. :) [08:35] jam: yeah yeay [08:35] is this to say that bzr-svn wants to hook into the creation of some stacks? [08:35] yes [08:35] jam: you can use authorization.conf too right? [08:35] mwhudson: You might look at authentication.conf, but I'm pretty sure it doesn't support passwords for ssh [08:35] so one other possible way to do this would be for it to override Branch.get_config? [08:35] since we figure "you already have ssh/config to set up a key" [08:35] which is more secure anyway [08:35] otherwise migrating the branch options to the new config scheme will break the UUID default values for options [08:36] jam: is there a chance that a user:pass in a url might end up in a traceback or other console output? [08:36] jam: presumably that's fixable though [08:36] mwhudson: I *believe* we are good about omitting :pass from anything we log [08:36] poolie: yes, but that makes it harder to migrate the options [08:36] poolie: and also harder to control which stores are used [08:37] mwhudson: http://paste.ubuntu.com/688966/ [08:37] "does not appear in base" means it doesn't show up in stuff like tracebacks [08:37] jam: ah nice [08:38] we strip it from the URL, and then hide it around as necessary [08:38] poolie: s/harder/different/ if you prefer but the proposal is an incremental progress in *one* direction [08:39] wull [08:39] *well, it's adding some complexity [08:39] which one ? [08:39] it's reasonable to ask why it's there [08:39] for who ? [08:40] adding a registry rather than just having functions [08:40] so the point of a registry is, in short, so that plugins can control how stacks are created for some particular purposes? [08:41] but you objected (rightly) that these functions are not good examples of how to build stacks and indeed they don't address the issues I mentioned above [08:41] which issues? [08:41] taking command line overrides into account needs a central place, not requiring eveybody to modify these functions [08:42] "which issues?" : overriding by plugins, centralizing store access [08:43] couldn't handling command line options be done by just saying there's a global stack, which most others build upon, that includes per-command options? [08:44] I never talked about per-command options, [08:44] i meant per-process [08:44] command line overides [08:44] can you elaborate about build upon > [08:44] can you elaborate about build upon ? [08:45] to me it means having helpers to create the appropriate list of (stores, section_matcher(context)) [08:45] basically just that branch_stack() should return stack(BranchStore(branch), LocationStore(), global_stack()) [08:45] and one central place to ensure the command-line overrides always dominate [08:46] then global_stack can include system-wide, per-user, and command-line parts [08:46] wrong [08:46] command-line overrides should come first [08:46] ok, i see [08:46] that's true [08:46] how does a registry help with this? [08:46] or do you want stacks to be able to be build recursively ? [08:46] it provides this central point [08:46] place [08:47] but how is it more central than the config module holding some functions? [08:48] (I think recursive stacks are neat, but introduce complexity for users as well as devs so I'm more against than for) [08:48] some functions all implementing the same rules ? [08:49] but, it's not *more* central, it's just *as* central [08:49] and again, it's just one way, there are others, this one just seem to be the easiest and fastest... [08:49] <_arch> Hi [08:50] poolie: what is this added complexity you're seeing there ? [08:50] even get_config() or get_config_stack() are still possible, they are just implemented by querying the registry, [08:50] how is that complex ? [08:50] it's basically just one more level of indirection to go through the registry [08:51] it's not enormously complex, i just don't think you're communicating why it's helpful [08:51] it's not obvious to me how it's going to help with plugins [08:51] i assume the point of having it is to enable things from plugins? [08:52] perhaps one way to move this along would be for you to give some illustrative cases of what plugins want to do with this and how they would do it through the registry? [08:53] <_arch> I have a problem: During commit, I want to inject my new revision number to each modified file [08:53] hi _arch, you want http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html [08:53] <_arch> I checked that out but I'm not sure if it helps. The $Revision-Id$ has a bunch of stuff I don't want apparently. [08:54] poolie: how will plugins implement command-line overrides ? [08:54] vila i'd probably just do that in the core [08:54] poolie: do you want them to explicitly change their stack builder ? [08:55] poolie: but how will they get the feature from the core ? [08:55] <_arch> So I figured I'll try to write a quick start_commit hook myself which injects the revno to the modified files [08:55] poolie: how would you output the help associated with a stack ? [08:55] <_arch> however I seem to have absolutely no clue of where to begin :) [08:55] poolie: how would support the plugin specific configs with 'bzr config' ? [08:55] vila, i'm interested in the answers but i'm also suggesting that if in future you explain some cases like this in the mp, it might be better understood [08:56] that doesn't match my understanding of small piece easy to propose :-/ [08:57] " but how will they get the feature from the core ?" - i'm not sure what you mean, but if you mean "how will they see values from the command line", i'd expect that all of the *_stack() functions will return a stack that looks at the command line [08:57] I'm not addressing rewriting 'bzr config' for now [08:57] poolie: indeed, that puts the responsibility on the plugin authors [08:57] i'm not sure if there needs to be help for a stack or whether that needs to be exposed to the user as such [08:57] you should do this and this and don't forget this, instead of: register your stack [08:57] i would not expect it needs any plugin changes [08:58] ... [08:58] " doesn't match my understanding of small piece easy to propose "-- i think generally, saying "previously, you couldn't do X. now, it works like so" is pretty helpful to establishing the change is worthwhile [08:58] that can be either in the mp or in a bug [08:58] but we have no idea today that plugins implement config files, nor do we have any way to know they do [09:00] _arch, are you saying the problem is that bzr-keywords just puts in too much text? like the revision id and you just want the number? [09:00] <_arch> yeah [09:00] maybe then the easiest thing is to just add another option to bzr-keywords? [09:00] you should be able to just go off the existing code [09:01] <_arch> Hmm, true. I'll check that out, thanks [09:01] if you fix it, please push up a branch so we can merge it [09:01] ask here if you need any help [09:01] vila, that might be true we don't know whether plugins are looking at config files but i don't see why it's actually a problem [09:01] <_arch> Right I'll check out the source and see if I can make something out of it. [09:02] poolie: no, I said *we* don't know that plugins use their own config files and/or if they introduce new features for our own config files [09:03] ok [09:03] is this a bug? [09:03] and if jelmer didn't mention that subversion.conf use [UUID] sections I would have break it by migrating the branch options [09:03] bug #832036 [09:03] Launchpad bug 832036 in Bazaar "Needs a config stack registry" [High,In progress] https://launchpad.net/bugs/832036 [09:04] we're running into circles [09:04] yeah, but that's basically the same problem [09:04] that bug does not describe an actual problem [09:04] ok, we don't have problems [09:05] better un-migrate the global options and forget about that [09:05] is that sarcasm? [09:06] obviously I'm not able to explain the issues in a way we can agree upon [09:06] :/ [09:06] sorry [09:07] no, it's just that I suck at this particular point and therefore cannot progress, so it's wasted time [09:07] ok [09:07] let's shelve this until it's clear it's solving a pressing problem for plugins [09:07] does it block anything else? [09:08] https://bugs.launchpad.net/bzr/+bugs?field.tag=config i.e. 40 bugs, plus all the ones I failed to file [09:09] i think 832036 is a good example of a bad bug, because it specifies a solution, not a problem [09:09] are you saying this blocks all those bugs? [09:09]