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