On 02/24/2015 12:27 PM, Daniel P. Berrange wrote:
> I'm actually trying to judge it from the POV of users, not just
> developers. I find it pretty untenable that in the fast moving
> world of cloud, users have to wait as long as 6 months for a
> feature to get into a openstack release, often much longer.

If you were trying to judge from the POV of users, then you would
consider that basically, they don't really care the brand new shiny
feature which just appear. They care having a long time support for
whatever version of OpenStack they have installed, without having the
head-aches of upgrading which is famously painful with OpenStack. This
shows clearly on our user surveys which are presented on every summit:
users are lagging behind, with a majority still running with OpenStack
releases which are already EOL.

In fact, if you want to judge from the POV of our users, we should *SLOW
DOWN* our release cycles, and probably move to something like one
release every year or 2. We should also try to have longer periods of
support for our stable releases, which would (with my Debian package
maintainer hat on!) help distributions to do such security support.

Debian Jessie will be released in a few month from now, just before
Icehouse (which it ships) will be EOL. RedHat, Canonical, IBM, and so
many more are also on the same (sinking) ship.

As for my employer side of things, we've seen numerous cases with our
customer requesting for LTS, which we have to provide by ourselves,
since it's not supported upstream.

> I think the majority of
> translation work can be done in parallel with dev work and the freeze
> time just needs to tie up the small remaining bits.

It'd be nice indeed, but I've never seen any project (open source or
not) working this way for translations.

> Documentation is again something I'd expect to be done more or less
> in parallel with dev.

Let's go back to reality: the Juno install-guide is still not finished,
and the doc team is lagging behind.

> It would be reasonable for the vulnerability team to take the decision
> that they'll support fixes for master, and any branches that the stable
> team decide to support. ie they would not neccessarily have to commit
> to shipping fixes for every single release made.

I've been crying for this type of decision. IE: drop Juno support early,
and continue to maintain Icehouse for longer. I wish this happens, but
the release team always complained that nobody works on maintaining the
gate for the stable branches. Unless this changes, I don't see hope... :(

> I really not trying to focus on the developers woes. I'm trying to focus on
> making OpenStack better serve our users. My main motiviation here is that I
> think we're doing a pretty terrible job at getting work done that is important
> to our users in a timely manner. This is caused by a workflow & release cycle
> that is negatively impacting the developers.

Our workflow and the release cycle are 2 separate things. From my POV,
it'd be a mistake to believe switching to a different release cycle will
fix our workflow.

Also, I'd like to point out something: it's been 2 years that I do
release each and every beta release we do. But either they are bug free
(you bet... :)), or nobody uses them (more likely), because I've *never
ever* received some bug reports about them. Reasonably, there's no
consumer for beta releases.

Hoping my point of view is helpful,


Thomas Goirand (zigo)

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to