Charm Store Series and Ubuntu Release

[Clint Byrum]

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