bzr-explorer is not compatible with bzr 2.6b1

cmd_launchpad_open now lives in bzrlib.plugins.launchpad.cmds.

And BTW there is nothing about such change in bzr's NEWS

I do not see a 1.3.0 release. Should this have been fix-committed instead of fix-released?

treaves пишет:
> I do not see a 1.3.0 release. Should this have been fix-committed
> instead of fix-released?

It depends. We prefer to use fix-released.

So then where do I download this release with the fix? I'm a bit confused.

treaves пишет:
> So then where do I download this release with the fix? I'm a bit
> confused.
>

bzr branch lp:bzr-explorer /path/to/plugins/explorer

--
All the dude wanted was his rug back

O.K., so it really is fix-committed, not fix-released.

I really do not care what you prefer, you should be correct; and calling this fix-released is not correct.

treaves пишет:
> O.K., so it really is fix-committed, not fix-released.
>
> I really do not care what you prefer, you should be correct; and calling
> this fix-released is not correct.

Are you using Mac installer? If so then it does not matter for you
whether it's released or not. Because you will get new version as part
of next installer build. Or you can get it directly from Launchpad branch.

And please, don't tell me that you don't care. If you were bzr-explorer
maintainer, you could call bug status as you wish and handle release
process. Have you ever tried to run project on Launchpad and made any
release?

--
All the dude wanted was his rug back

Yes, as a mater of fact, I do. And when me, or one of the other developers marks a bug as fix-committed, then the fix has been committed. And when that is released, the bug gets marked as fix-released.

See, these are actual words, not made up combinations of letters. And as such, they have a meaning. And the definition of committed, in the context of SCM, is that something has been added to the repository. And the definition of a release is that there is a binary build or package available for users to download.

I hope you've learned something today.

On Mon, Mar 26, 2012 at 02:30:37PM -0000, treaves wrote:
> Yes, as a mater of fact, I do. And when me, or one of the other
> developers marks a bug as fix-committed, then the fix has been
> committed. And when that is released, the bug gets marked as fix-
> released.
I appreciate that we should clearly communicate what the status of a
particular bug is. And that inconsistency in the way bug statusses are
used isn't helpful.

That said, I don't think it's as straightforward as you say.

If a change has been committed in a contributors branch but hasn't
been merged into the main branch, is it fixcommitted too? Or is it committed
when it lands on mainline, or on the currently supported series
branch? How should you distinguish between these states?

Similarly, is it released when it has been a part of an alpha release,
or only if it has ended up in a final release, if it has been part of
an RC?

What about for projects that don't do official releases but just have
a SCM branch? Should they keep their fixcommitted bugs open forever?

> See, these are actual words, not made up combinations of letters. And
> as such, they have a meaning. And the definition of committed, in the
> context of SCM, is that something has been added to the repository.
> And the definition of a release is that there is a binary build or
> package available for users to download.
Releasing something is (among other things) making it available for public use.

Of course, FOSS releases are traditionally done by publishing a tarball,
but the dictionary definition of "release" doesn't say anywhere that
it has to be a tarball.

> I hope you've learned something today.
You're welcome to question the way things are done. There's no need to
be condescending.

Cheers,

Jelmer

treaves пишет:
> Yes, as a mater of fact, I do. And when me, or one of the other
> developers marks a bug as fix-committed, then the fix has been
> committed. And when that is released, the bug gets marked as fix-
> released.
>
> See, these are actual words, not made up combinations of letters. And
> as such, they have a meaning. And the definition of committed, in the
> context of SCM, is that something has been added to the repository.
> And the definition of a release is that there is a binary build or
> package available for users to download.
>
> I hope you've learned something today.

Please, be maintainer of bzr-explorer then.

I hope you know what it means to change dozen or so bugs from
fix-committed to fix-released state. I've been there and done that.
Don't hope that I will listen to you. I do my best for bzr-explorer and
qbzr in my free time and I should listen to your sermons? NO, THANKS.

If you want to do it better - I will be happy to pass these projects to
your hands. Until then, please don't comment on this topic anymore.

--
All the dude wanted was his rug back

Excuse me, don't want to bother you but I just downloaded the v2.6b1 bundle for OSX and had the same error:

Traceback (most recent call last):
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 930, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 1141, in run_bzr
    ret = run(*run_argv)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 673, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 697, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/cleanup.py", line 136, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/plugins/explorer/lib/commands.py", line 161, in run
    window = explorer.QExplorerMainWindow(location_list=location_list,
  File "/Library/Python/2.6/site-packages/bzrlib/lazy_import.py", line 108, in __getattribute__
    obj = object.__getattribute__(self, '_resolve')()
  File "/Library/Python/2.6/site-packages/bzrlib/lazy_import.py", line 85, in _resolve
    obj = factory(self, scope, name)
  File "/Library/Python/2.6/site-packages/bzrlib/lazy_import.py", line 200, in _import
    module = __import__(module_python_path, scope, scope, [member], level=0)
  File "/Library/Python/2.6/site-packages/bzrlib/plugins/explorer/lib/explorer.py", line 32, in <module>
    from bzrlib.plugins.explorer.lib import (
  File "/Library/Python/2.6/site-packages/bzrlib/plugins/explorer/lib/hosted_url_resolver.py", line 21, in <module>
    from bzrlib.plugins.launchpad import cmd_launchpad_open
ImportError: cannot import name cmd_launchpad_open

bzr 2.6b1 on python 2.6.7 (Darwin-11.4.0-x86_64-i386-64bit)
arguments: ['/usr/local/bin/bzr', 'explorer']
plugins: bash_completion[2.6b1], bzrtools[2.5.0], changelog_merge[2.6b1],
    colo[0.4.0], email[unknown], explorer[1.2.2], fastimport[0.14.0dev],
    git[0.6.7], keychain[0.1.0], launchpad[2.6b1], loom[2.2.1dev],
    netrc_credential_store[2.6b1], news_merge[2.6b1], pipeline[1.4.0],
    po_merge[2.6b1], qbzr[0.22.1], rewrite[0.6.4dev], svn[1.2.1],
    upload[1.1.0], weave_fmt[2.6b1], xmloutput[0.8.8]
encoding: 'utf-8', fsenc: 'utf-8', lang: 'fr_FR.UTF-8'

Dominique Guardiola пишет:
> Excuse me, don't want to bother you but I just downloaded the v2.6b1
> bundle for OSX and had the same error:

Unfortunately, I'm NOT the maintainer of OSX installer, so I'm unable to
fix it.

But you can get the fixed version of bzr-explorer from Launchpad and put
it to your plugins directory:

cd ~/.bazaar/plugins
bzr checkout --lightweight lp:bzr-explorer explorer

Your copy of explorer will override the one from OSX bundle and explorer
should work for you.

HTH

--
All the dude wanted was his rug back