On 10/20/2013 05:25 AM, Cristian Tomoiaga wrote:
Hello Thomas,
I am sorry to send a reply a little late on this. I plan on working with
Debian for my Openstack setups (now I'm on a rhel based setup) and I
would really like the latest OpenStack release available.
I was initially planning to setup my own mirrors since I always seem to
need features from the next OpenStack release. For example Grizzly for
me looks too old and some features that were supposed to land on
Havana are now scheduled for Icehouse.
Given this, I would pretty much like to have J in Debian Jessie.
I'm not sure how to approach this or if it's worth the effort on your
part given the latest issues you submitted for Havana and since most
likely some features in K will probably make me switch to separate
mirrors anyway. However, taking into account the rapid development of
OpenStack my guess is that the J release should land in Jessie if
possible.
I will also try to find some time and help out as much as I can with this.
Let me know what you decide , probably after the summit.
Hi Cristian,
Thanks for your above comments.
Unfortunately, even if I agree with you that the latest is best, and
that having a maximum of feature is just cool, my decision will *not* be
motivated by that. The only thing will care will be the ease
maintainability in the Debian stable release.
Maintaining security for OpenStack Essex in Wheezy is currently a major
pain, because it's not supported upstream. It'd be really great, from my
point of view, if the OpenStack community decided to have an LTS
release. Maybe it didn't make sense at the time of Essex. Probably, as
the time passes and OpenStack matures, it will make more sense now and
later to have an LTS. Though this isn't my decision, and my
understanding of it, is that the amount of people interested by doing
the security backport work this is close to one (eg: only myself).
So, if there's still no LTS for OpenStack next April, and things
continue to be maintained the way they are right now in OpenStack (that
is, release + 1 year), then I have 2 options. Either I will follow
Canonical, and hope that we can have a joined effort for security fixing
(currently, it's not happening at all, so this would have to change), or
just package the very latest (release J), so that backporting of
patches is less painful that backporting to Icehouse. This way, I'd also
get 1 year of free security support instead of 6 months, which is
something already...
Also, another problem is being able to get enough patches of the point
release into the frozen Testing distribution. When OpenStack releases,
there's always a bug here and there that are annoying, but discovered
later, on point releases. So 2013.1.4 could make more sense, quality
wise, as it will have the time to be polished and cleaned. Wheezy has
been released with 2012.1.1, and not 2012.1.4, because it was frozen at
the end of June, and nobody took care of applying the upstream patches
and convincing the release team that they are needed. To get this
happening with the J release of OpenStack, every patch will be reviewed
and will need justification, which takes a lot of time for both the
package maintainer and the release team, so it'd be nice to avoid it.
Last thing: I will need to support upgrades from Essex to whatever will
be in Jessie. It'd be nice if I can avoid doing this alone. I'm not sure
if the OpenStack project is bound to support that, or if Canonical will
be doing the work.
Oh, and one last thing: whatever happen, I will continue to package the
very latest OpenStack version either in Sid, or in Experimental, and
continue to provide Wheezy / Jessie backports. So if you want the very
latest version of OpenStack in Debian, you'll have it available.
I hope the above gives you a more clear picture of what's going on in my
mind. I have a year to take a decision... :)
Cheers,
Thomas Goirand (zigo)
P.S: CC-ing the Debian release team list, to get their opinion.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
