Charm Store Series and Ubuntu Release

[Nathan Williams]

Fwiw, if there's charms that drop out as releases move forward, i'd be happy to chip in where I can on any charms listed in a "needs love" list. I'm sure others feel the same.

Clint Byrum <clint at ubuntu.com> wrote:

>Excerpts from Gustavo Niemeyer's message of 2012-08-28 15:17:31 -0700:
>> On Tue, Aug 28, 2012 at 6:02 PM, Clint Byrum <clint at ubuntu.com> wrote:
>> > Nobody said we wouldn't test it, just that the LTS version will be left
>> > untouched unless it needs changes, and that minor improvements will land
>> > in the LTS, not just in the new dev release.
>> 
>> This seems a bit unrealistic. In practice what will happen is that
>> people will be working on their preferred release and will think "it's
>> most certainly working'" in the other N. I think we need a development
>> focus, whatever it is, where people put their love in. When someone
>> wants to change a non-focus release, they should pick up the
>> respective charm and make sure it's working *there*. Otherwise, it
>> feels somewhat optimistic to even have the non-LTS releases being
>> supported by charms, when no one is actively using them.
>
>Agreed, dev focus is needed. Whats hard to understand is what to do with
>charms whose maintainer does not care for a new dev focus.
>
>I suspect many charms will only be maintained in precise. As we open up
>quantal for charm dev, and move the focus to it, we would need to drop
>any charms whose maintainers don't want to make them work in quantal.
>
>That is the real issue I'm concerned about. With q, then r, then s, we
>might lose half the precise charms. Then t would come out, and the effort
>becomes rather.. large to get t's charm collection up to the level of p's.
>
>But, perhaps thats all ok. I actually don't see any problem with that.
>Our man power as a "charmers" team would be to make sure those important
>infrastructure charms work well in each series for users who want that series
>to work.
>
>Ok.. I think I'll write up something much simpler.
> 
>> 
>> > We can also just do this using bzr push to the other releases after
>> > tests pass and as long as the branches have not diverged. I just figured
>> > changing the way we view the repos, instead of hacking them into a shape
>> > we like, is a simpler task. Perhaps that was misguided though.
>> 
>> The model juju implements matches the problem domain. It was founded
>> onto the correct assumption that different Ubuntu releases have
>> different versions of different programs in different sets of
>> packages. If you're willing to ignore my advice and hack it together,
>> it's been proven that I can't prevent you to, but I'll at least make
>> it harder for you to shoot your own foot.
>> 
>> 
>
>For once, I think I appreciate the firm shaking and gentle slaps... ;)
>> gustavo @ http://niemeyer.net
>
>-- 
>Juju mailing list
>Juju at lists.ubuntu.com
>Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju