Open Stack

On Tue, Feb 24, 2015, Thierry Carrez <thierry at openstack.org> wrote:
> Joe Gordon wrote:
> > [...]
> > I think a lot of the frustration with our current cadence comes out of
> > the big stop everything (development, planning etc.), and stabilize the
> > release process. Which in turn isn't really making things more stable.
> 
> I guess I have a different position. I think the release candidate
> period is the only thing that makes your code drops actually usable.
> It's the only moment in the cycle where integrators test. It's the only
> moment in the cycle where developers work on bugs they did not file
> themselves, but focus on a project-wide priority list of release
> blockers. If you remove that period, then nobody will ever work on
> release blockers that do not directly affect them. Shorten that period
> to one week, and no integrator will have the time to run a proper QA
> program to detect those release blockers.
> 
> I understand that from your developer perspective it's annoying to have
> to work on project-wide priorities rather than your own, and therefore
> you'd like to get rid of those -- but the resulting drop in quality is
> just something we can't afford.

Speaking as an operator that deploys from trunk, code quality isn't our
biggest problem right now.

One of our biggest problems is merging our local branch with upstream.
There are a handful of contributing factors to this, but a major
part is the patches we need to carry locally until they are merged
upstream.

If we can get patches/features we develop merged upstream faster, that
would be the biggest help for us.

JE