Dependencies in the PPA for Jaunty

Maritza Mendez martitzam at gmail.com
Mon Jun 15 20:08:06 BST 2009


On Mon, Jun 15, 2009 at 11:50 AM, Aaron Bentley <aaron at aaronbentley.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Maritza Mendez wrote:
> > I understand what you are saying.  Requiring bzrtools to test against
> > bzrRC is fine.  But we still need a mechanism to help people decide when
> > upgrading makes sense for them.  That's what I was really trying to say.
>
> Upgrading in what context?  If you're using the debs from the PPAs,
> you'll always have a known-good combination.  Same if you're using the
> Windows .exe installer.
>

By "upgrading" I mean grabbing the latest stable release in source form to
get the fixes I have identified as critical to my team even before they get
to the debs.  So what you're really saying is I should wait for the debs.  I
used to do that.  Then one time there was a noticeable delay between final
and debs, and I realized that I really did not have to wait for debs.  That
was probably a bad choice by me.

Are you saying that the kind of bzr-versus-plugins compatibility I am
seeking is guaranteed by the debs?  If so, great, thank you and I apologize!



> If you're running from a branch of bzr.dev, then you're living on the
> bleeding edge, and the process is more manual.  But we have frequent
> releases, so you don't have to live on the edge unless you really want to.
>

I do keep a local mirror of bzr.dev, but I don't use it unless I suspect a
problem is solved in dev that is not already in release.  I'm crazy but not
that crazy.  :)

> So winning mindshare
> will be well served by collecting the plugin compatibility documentation
> at one place.

I guess we could do this.  It would be nicer if plugins could just
> declare which Bazaar version they supported and have a page that
> automatically updated based on those values.
>

Yeah!



> > As I understand it, this job of making sure everything works together is
> > basically done the hard way by distrinbution packagers
>
> No, I don't think so.  Not everyone tracks the bzr version numbers like
> bzrtools does, but people are pretty explicit about which bzr versions
> are supported.  Certainly in the case of bzr-svn, you can assume it's
> *not* compatible with the latest bzr until a version comes out that
> specifically supports it.
>

That's exactly the kind of information I am seeking.  I'm not trying to say
one way is right and another way is wrong.  All I want is easy access to
information which will let an intelligent person make intelligent
decisions.  That information already exists, but it is not always obvious
how to get it.


>
> >, like the ubuntu
> > packagers.  But that happens so far upstream, compared to how fast the
> > bzr team fixes bugs.
>
> Do you mean downstream?  In common usage, the bzr team is the "upstream".
>

Sorry.  Lost in translation.  Yes, I mean later or downstream in workflow.
:)

>  And as you say, the plugins can usually be updated
> in a few minutes.  Distros are slower, for good reason.  So there seems
> to be a need for an intermediate layer, which gets the hard work of the
> talented bzr core and plugin developers out to users faster than a
> distro can or should but with at least some minimal promise of
> stability.

Are the PPAs not that intermediate layer?
>

If you say so.  Thanks!   Based on one or two bad data points, I thought
maybe the PPAs were not held to such a high standard.  If they are, then
that is exactly what I should be using.

Thanks.  I learned a lot from this.

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090615/6de43db3/attachment.htm 


More information about the bazaar mailing list