bzr-svn

[Martin Pool]

On Sun, Dec 7, 2008 at 11:27 PM, Russel Winder
<russel.winder at concertant.com> wrote:
> Stephen,
>
> On Sat, 2008-12-06 at 11:38 +0900, Stephen J. Turnbull wrote:
>> Russel Winder writes:
>>
>>  > Can I make a suggestion:  The version dependency should change with the
>>  > commit that makes the breaking change.  This way issues get flagged
>>  > during the development phase in a way that makes people aware before
>>  > there might be a problem.
>>
>> You're asking the impossible.  On the one hand, you say "it works for
>> me, why do you break it with a version dependency?"  Now you're saying
>> "make sure it doesn't work for anybody, so that they'll be aware that
>> it might not work for others."
>
> Yes and no -- but I don't think I am being contradictory.  In a
> development branch, it seems reasonable to me for the developer(s) to be
> able to change dependencies.  It seems right for the dependencies to
> correctly reflect the actual dependencies.  In the 0.4.16 release Jelmer
> put in a dependency but only expressed it at the very last moment.

Ideally, it would be as you first described: developers would make a
specific decision to depend on a later api and would then update the
declared dependency at the moment they commit that change.  (And you
can even imagine having automatic cross-version tests that check
they've done it.)

However, reality is not always quite that nice.  As was discussed on
this list, we only discovered this dependency when a bug was reported
(http://launchpad.net/bugs/293440 or something similar), and so it was
at that point the dependency was updated.

> For me the beta PPA is just like using the development branches,
> consistency is not guaranteed.  So in a sense using the beta PPA is
> worse than using the development branches directly as Aptitude gets in
> the way.

We'd certainly aim to have everything released consistently and
simultaneously, and we should keep pushing ourselves when we don't get
there.  However, it's not going to be precisely synchronous for the
same reason.  However, we probably can have this flux happen in the
beta ppa and then move things only to the release ppa when there's a
final set.  I also filed a bug against PPAs so that now (I think) it
will give you a reasonable choice to get the most recent of whatever
consistent set you need.

> History shows I think that I have been most vocal, and probably a "right
> pain in the arse", about the Subversion plugin, bzr-svn.  This is
> because Bazaar has Just Worked (tm) for my Bazaar branches but most of
> my work has been with Subversion repositories.

Well, we appreciate your constructive criticism.

>
> I think it entirely appropriate to express once again, my thanks to
> Jelmer for his patience in dealing with my emails and bug reports, and
> for progressing my needs.  We are almost in the position where the Gant
> and Gradle projects will switch formally to using Bazaar as the main VCS
> with the mainline stored in a Subversion repository at Codehaus and use
> made of Launchpad for experimental branches.  Once this happens I can
> start a campaign to get the Groovy project moved to the same workflow.
>
>>  > Can I make a bit of a plea:  Can whoever is doing the 1.10 roll out make
>>  > sure that:
>>  >
>>  >    bzr
>>  >    bzrtool
>>  >    bzr-svn
>>  >
>>  > all have packages in the release PPA at the same time.
>>
>> They do ... if you wait long enough.  The problem with the suggestion
>> of coordinating them so that the releases are (nearly enough)
>> simultaneous is that (a) there is no "who (singular)"; I believe that
>> all three have different maintainers, and bzr itself doesn't even have
>> a consistent release engineer---the role rotates, and (b) some people
>> don't need all those tools, why should they wait if one of the
>> maintainers is on vacation or traveling?
>
> I understand your point but John managed to make the bzr 1.10, bzrtools
> 1.10, bzr-svn 0.4.16 roll out happen as close to at the same time as
> makes no difference which shows that it can be done.  For me this sets
> the bar for future releases.
>
> Also ram at macports.org did the same for the MacPorts distribution.
>
> This just leaves the Windows distribution.  This doesn't affect me as I
> don't use WIndows, but sadly it remains the majority platform.

We currently build Windows on a shared virtual host because there are
a lot of dependencies that have to be manually installed.
Unfortunately the host is down and we're dependent on the provider to
fix it; naturally we're also looking around for whether we should do
this somewhere else.

Once we're through this episode, we should have an environment and a
script that will stamp out Windows builds pretty quickly.

In the meantime, there is documentation on the list of how to build it
and if someone else would like to step up and make a build that would
be great.

-- 
Martin <http://launchpad.net/~mbp/>