bzr-svn

Russel Winder russel.winder at concertant.com
Mon Dec 8 07:27:06 GMT 2008


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.  The
fact that it did not affect me was pure fluke.  By changing the
dependency with the commit that creates the new dependency, it makes
explicit to everyone using the development branch that there has been a
change.  Because people using the development branch must expect change
such as this when the problem arises it is not crucial, but something to
deal with.  In this case I could have switched back to using bzr.dev or
not updated by 0.4 checkout.

Dependency consistency at the point of release is clearly the most
crucial think, that is when everyone can and should expect everything to
work as it should.  when using development branches people can and
should expect there to be glitches.

>  > I guess I should stop using the branch and just use the released deb
>  > files.
> 
> Maybe.  There are ways to use beta test code in production
> environments (that is, after, the original definition of "beta"
> test).  They require a certain discipline, and it's up to you whether
> you want to apply that extra effort in return for access to the most
> recent features and fixes (and bugs<wink>), or simply to "pay back"
> the team for their effort.

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.

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.

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.

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081208/f632dd24/attachment.pgp 


More information about the bazaar mailing list