Open Stack

On 06/08/2015 12:46 AM, Alan Pevec wrote:
>> How do you check if project X in version n works with project Y in
>> version m, using this non-scheduled point release "free for all" model?
> 
> That was an illusion of point releases, as Thierry said there wasn't
> significantly more testing and I don't remember any testing reports
> during stable freeze periods.

There is: the point releases end up in all distributions, and we all do
our own tests.

> All we had was upstream CI testing, but that's what we get for every commit.

The stable release gate is famously always broken, and now that we're
proposing to stop doing the point releases, it's going to be even worse.

>> Why every 2 weeks? Why every month?
> 
> Sure, no problem, every distro can update whenever it works for them,
> what is important for me is that we have a common reference points.
> With plan D that would be automatically generated maj.min.N where N is
> the number of commits since maj.min tag which doesn't depend on
> anyone's manually pushing git tag.

As long as we have a common reference point, manually or not, I'm satisfied.

>> Not synchronizing brings a bunch of problems. The only problem raised by
>> synchronous point releases is "we don't have enough resources", which I
>> fail to understand, given how cheap it is to tag a release. If the
>> release managers don't have enough time to do so, it is my view that
>> it's ok to give this power to individual projects. But that's orthogonal
>> to having synchronous point releases.
> 
> Tag is indeed cheap, this is more about reflecting reality and not
> keeping this "synchronized" illusion alive.

If distros are releasing packages based on the same tag, I fail to see
where we have an illusion.

> BTW point release process is more[1] than just pushing signed git tag,
> the most time consuming work is cats herding (i.e. pushing for reviews
> before the freeze) and Launchpad pruning.
> The former was hopeless and will be even more with big-tent and the
> latter we should avoid by automatically generated changelog.

So, if I get you right, you are saying that our QA work isn't working as
well as we want, and therefore, we should accept that fact, and get rid
of that QA work. While it's important to realize what our problems are,
I don't think this is going to the right direction still... :(

Cheers,

Thomas Goirand (zigo)