I've found a reliable workaround: the thing works if I create a
branch explicitly owned by me (and *not* by the team to which I
belong and which should normally own the branch). In this example
my username is saiu and my team is marionnet-drivers; I want to
make a branch called 0.90.x, owned by marionnet-drivers .
After creating the branch like that, I can change its ownership with
launchpad, and attach it to a release series.
Instead if I simply do
bzr push --verbose lp:ocamlbricks/0.90.x
I observe the behavior reported by Vadim Nevorotin. Vadim, is your
situation similar?
Anyway, this definitely *is* a bug. Even if according to the intended
semantics I weren't allowed to make a branch owned by my team (but why
shouldn't I be able to?), I think that
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
is a pretty bad way of signaling the error condition.
I've found a reliable workaround: the thing works if I create a
branch explicitly owned by me (and *not* by the team to which I
belong and which should normally own the branch). In this example
my username is saiu and my team is marionnet-drivers; I want to
make a branch called 0.90.x, owned by marionnet-drivers .
First of all, I login:
bzr launchpad-login saiu
This works:
bzr push --verbose lp:~saiu/ocamlbricks/0.90.x
After creating the branch like that, I can change its ownership with
launchpad, and attach it to a release series.
Instead if I simply do
bzr push --verbose lp:ocamlbricks/0.90.x
I observe the behavior reported by Vadim Nevorotin. Vadim, is your
situation similar?
Anyway, this definitely *is* a bug. Even if according to the intended RuntimeError' > ignored
semantics I weren't allowed to make a branch owned by my team (but why
shouldn't I be able to?), I think that
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.
is a pretty bad way of signaling the error condition.