PPAs for juju api client and deployer

[Mark Canonical Ramm-Christensen]

The stable PPA should move faster than the release, and should work on
precise as well.  And can be a single point of documentation that makes the
getting started story easier for older Ubuntu versions.   So, I think it
should exist.

If the deployer depends on the API and we are promoting it and making it
part of the core juju story (which we are) then the API-client should be in
stable.

I agree about backports being conceptually better, and we should continue
to pursue that wherever possible. but I still see a valid use case for a
stable PPA.   (And ultimately for a pocket in cloud archive or some such
thing...)

--Mark


On Wed, Aug 21, 2013 at 4:34 PM, Marco Ceppi <marco.ceppi at canonical.com>wrote:

> On Wed, Aug 21, 2013 at 4:27 PM, Mark Canonical Ramm-Christensen <
> mark.ramm-christensen at canonical.com> wrote:
>
>> On Wed, Aug 21, 2013 at 3:50 PM, Antonio Rosales <
>> antonio.rosales at canonical.com> wrote:
>>
>> > This issue also came up if folks wanted a stable juju, but tools that
>> > are only housed in devel. The user would have to enable both stable
>> > and devel PPAs. The issue is when a user updates juju-core they will
>> > get the devel version, and not the expected stable version.  Thus +1
>> > on a tools PPA.
>>
>> I think if a tool is stable and promoted it should definitely go in the
>> main stable PPA.
>>
>
> I think if a tool is stable and promoted it should live in the archives,
> see my inline below.
>
>
>> I think there is a legitimate use case for devel of core to be separated
>> out from devel of all the tools -- but in that case it seems unlikely that
>> a user wants all of the devel tools, they just want one specific one that
>> solves their problem so that is a use case for tool specific PPA's more
>> than a general "tools" bucket.
>>
>> But lest we get tied up in generalities, I'd like to go back to the
>> specific projects that started this discussion:
>>
>> *Deployer*
>>
>>   * We are using promoting and integrating deployer into the GUI
>>   * Specific versions of juju-core have required specific versions of the
>> deployer already
>>   * We use it in cloud deployments
>>
>> I think that means we have to support it in stable.
>>
>> *API Client*
>>
>>   * We aren't yet telling anybody they have to use this and we don't
>> officially support it
>>
>
>> I think this means that it gets to stay in it's own PPA for now, but that
>> the above arguments would apply and we'd need to get it into devel/stable.
>>
>
> However, deployer depends on the API Client, so in order to install
> deployer from the PPA you'd have to know to add the specific API Client
> PPA. In addition Amulet, being released this week, depends on
> juju-deployer. It's by no means stable. So to add amulet you'll need to add
> it's custom PPA, then the stable ppa for deployer, then the other separate
> ppa for api client (or mixing devel and stable if that's what we're using).
> Now we're right back where we started with multiple PPA and confusion of
> where the tools are. This is why I constantly fall back to the centralized
> tools PPA. If a tool is stable, then we should be pushing it into saucy
> (like deployer is now) and working on getting it backported to precise.
> That should be the stable process. The PPA, as I have viewed them, are
> there for everyone else who either don't want to wait or are using a distro
> other than saucy or precise. For the most part, I think the backporting
> front better embodies the stable process rather than doing builds in a
> stable ppa. However, this is my opinion on the matter, even if this isn't
> correct we still run in to dependency issues. Should we put
> python-jujuclient (API Client) in stable because deployer is stable and
> uses it despite it's non-stable tag?
>
>
>>
>> So, from the specific use cases, I see strong value of getting supported
>> juju extension bits into the stable PPA, and significantly less in getting
>> them into a unified "devel" PPA.
>>
>> --Mark
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130821/1dcf9d4b/attachment-0001.html>