Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/26/2015 01:06 AM, Thomas Goirand wrote:
> 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.
> 

As was already said in the thread, they care about long support AND
their specific subset of shiny new features they need (and they don't
care about all other features that are not in their subjective list of
shiny ones).

> 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.
> 

That won't come up magically. If no people from Debian or IBM are
actively involved in solving issues for stable branches, long term
will be just a wish and not a reality. At the moment we have several
people from Red Hat (me, Alan) and Ubuntu (Chuck, Adam) side active in
the team. That would be great to see more diversity, and more hands
dirty with stable branches on daily basis.

> 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.
> 

Every downstream vendor would be happy to see upstream freely support
their product. :) But you get what you pay to upstream horizontal
initiatives like stable maintenance.

I've heard IBM still supports releases starting from C release!..

>> 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.

It's actually not true. I've coordinated multiple translation teams
for my language (Belarusian), and for what I can tell, the best
practice is to work on translations while development is ongoing. Yes,
it means some effort wasted, but it also means spreading the whole
effort throughout the year instead of doing all the work in
pre-release freeze time.

Freeze time is anyway good to make sure that no last minute patches
break translations, and I don't suggest we drop them completely.

> 
>> 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... :(
> 

- From Red Hat perspective, we put our effort in what we're interested
in. We're more interested in keeping the branch for the latest release
working, not about sticking to an old release that e.g. Debian chose
to put into their next official release, so unless someone from Debian
come to the team and start to invest into Icehouse, it will eventually
be dropped. That's life.

>> 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.

Here, I actually agree. There are lots of enhancements in dev workflow
to apply that would not require us renaming milestones into releases.

> 
> 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.

I would say we experience the same on Red Hat side (RDO). We start to
get consumers near first RC phase, when companies start to evaluate
their options for their next deployments (sticking to existing release
or investing into next big thing).

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU9Jk/AAoJEC5aWaUY1u57oGwH/0pVMTdtSJJimfhowNGSNQS1
BibqpWKGjhZ3+LZNt09+WYcBaXp0X2/X7apuZyB3NvVteA5m7DyNvFKg7W0DVaVf
P4QVDzHlmE6X5JCZEUpHWWGGHXe1rqchZLHwufMnLVAhrLJfp6QcEoyhGjFAAWLe
wVQwSP4oJDnMKxyKZUehPyfptbG6uvR3/y/TqwUa7ExfAkzd7Q2P05d63/8a9ZQV
bkuMKvzpYyuCpB53r7iuHWAeG838Xm5HxrusRvrQgMtuM32PuBwTIDDeF5Ey251W
Z+96FWgdnDiyprxRbrmft2QbFsFUl4znBl6jVemZLlnKE7CQ2OEqIvU0jnSkd70=
=Si0x
-----END PGP SIGNATURE-----