Homebrew packages for OS X updated for 2.7.0

[Richard Wilbur]

On Fri, Feb 19, 2016 at 11:35 AM, Fred McCann <fred at sharpnoodles.com> wrote:
[...]
> I’m more than happy to update the plugin list. Do I need an account to do
> that? I’m don’t see any edit options.

You can use your launchpad.net account to login and edit the wiki.
Just click the "login" link at the bottom of the page, click the
"Login" button on the next page, if your browser doesn't automatically
redirect click the "Continue" button, and you will find yourself at
the Ubuntu One (OpenID server) login page.  After you provide your
launchpad credentials, approve the release of authentication
information to wiki.bazaar.canonical.com and you will be authorized to
edit (the links should appear).

> I’m still working through these, but it seems like quite a few are
> abandoned and in some case have been rolled into bzr core. How can
> we get that cleaned up?

I'm creating a list of plugins that have been specifically orphaned
(previous maintainer asked for someone to take over).  It seems to me
that if no willing person steps up to adopt them, we could consider
putting them under the auspices of the bzr-core team, or some such,
which would lend more flexibility in authorizing maintenance and
releases.

I'm all for updating the list with what works.  I'd also be interested
in setting up some automated testing so it is easier to tell whether
or not they work without having to branch every plugin and run it's
test suite against current bzr trunk.

> I think the best is to make a clear cut about what works with bzr-2.7
> and what doesn't.

Yes.  Then we'll have a list of what plugins need some love.

> If enough people care and help we can then add more to the what works
> list by doing releases for the plugins whose trunk is owned by lp:~bzr
> (bzr-stats for example), it's harder if they aren't (bzrtools for
> example) in that case, reaching to the project owner and nicely asking
> for a release may be the way to go.

If we can offer a merge proposal for a branch with the fix, then we
might make the project owner's job even easier.

> It’s lousy advertising to list very old plugins that don’t work
> anymore.

I think it is unfortunate to list plugins that don't work anymore
under the "Working" status.  On the other hand, I'd be interested in
collecting those that don't work anymore in a separate list with
appropriate status so we don't advertise them as working but have a
chance to remedy the situation.

> Also, is there any plan/way to suggest that we look into rolling
> some fundamental plugins like xmloutput, bzrtools (or some portion
> of it), bisect, extmerge, etc into the core bzr codebase?
>
>
> There has been discussions about that, but it's up to the project owners
> to do so. I know that in some cases, copyright issues were raised and
> blocked the process.

I wonder how hard those issues would be to resolve--especially for the orphans?

> It seems like quite a few critical batteries are not included in
> the box.
>
>
> It's a hard balance to find between freedom to evolve in the plugins and
> the additional work to carry them inside the core bzr tree.

I understand for new ideas and things that are a work in progress, the
freedom to change/evolve as needs and desires dictate is very useful
and encourages the process.  On the other hand if the plugins are
orphaned, stable, or mature, it might be worth revisiting the
discussion on a case-by-case basis.

Richard