Homebrew packages for OS X updated for 2.7.0

[Vincent Ladeuil]

>>>>> Fred McCann <fred at sharpnoodles.com> writes:

    >> On Feb 18, 2016, at 2:01 PM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
    >> 
    >>> bzr-builder: stable 0.7.3
    >>> bzr-colo: stable 0.4.0
    >>> bzr-rewrite: stable 0.6.3
    >> 
    >> Do you have branches/revisions references for that ?
    >> 
    >> Any kind of revision will do: revno, revision-id, tag, as long as there
    >> is a public branch for that.
    >> 

    > All of these have stable releases that appear to be working with bzr
    > 2.7.0. Landing them in homebrew is just a matter of getting some
    > approvals. bzr-rewrite has now been accepted.

I'm not sure what that means as I don't know what a homebrew package
is. The most important missing bit for me is: can you add patches as
part of the package (like in debian/ubuntu) ?

    >> 
    >>> bzr-stats
    >> 
    >> That one is not working ? Wow, that's quite a surprise. What's the issue ?
    >> 

    > https://bugs.launchpad.net/bzr-stats/+bug/1545883

Dupe https://bugs.launchpad.net/bzr-stats/+bug/1040560

We need a new release or a new tarball.

Sorry for being a bit vague and talking about different solutions :-)

But the two main important bits are:

- can you add patches to a homebrew package (in which case you're in the
  same boat as debian/ubuntu and don't need a new release),

- what branches/revisions are you using, even without doing a release,
  every plugin/project can build tarballs named
  bzr-xxx-1.2.3~bzrrevno234.tar.gz which may suit your needs

    >>> bzr-bisect
    >>> bzr-difftools
    >>> bzr-extmerge
    >> 
    >> Branches/revisions references ?
    >> 

Please ?

It's hard to know what kind of issues you're dealing with without
knowing which code you're using :-}

    > I just took over bzr-extmerge, merged some very long standing proposals, and
    > cut a release. It seems like this is still a core plugin

Just to be on the same page, we generally call core plugins the ones
that are under bzrlib/plugins in the lp:bzr tree.

    > (it’s referenced in the documentation:
    > http://doc.bazaar.canonical.com/latest/en/user-guide/resolving_conflicts.html),
    > 
    > but it also had never had a formal release.

https://launchpad.net/bzr-extmerge/trunk says....

WOW !

Looks like someone did a release since :)

Congrats !

    > I also pushed that out as a package to the homebrew folks for
    > bzr-extmerge, and it’s pending approval.



    > While I was poking around, I also noticed that bzrtools latest release is not working with bzr 2.7.0:

    > https://bugs.launchpad.net/bzrtools/+bug/1547121

Damn it, it's fixed in debian and ubuntu by getting rid of the
compatibility check that is causing issues at each release (but replaced
by a different one in debian/ubuntu that is *also* causing issues ;)

long story short, I fixed it in debian/ubuntu without realizing you'll
face it for homebrew.

That needs to be fixed upstream indeed.

<snip/>

    > I admit, I’m new on the dev side of things, but I’m willing to
    > pitch in to make 2.7.0 + whatever plugins stable. On the topic of
    > plugins, it does seem like the list of plugins on the bzr wiki is
    > out of date:

    > http://wiki.bazaar.canonical.com/BzrPlugins

It's a wiki so feel free to update it, especially with the work you're
doing right now, you're the most knowledgeable.

    > 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 think the best is to make a clear cut about what works with bzr-2.7
and what doesn't.

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.

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

Agree.

    > 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.

    > 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.

    Vincent