Open Stack

Hi Andrey,

Sorry for the delay getting back to this. I had meant to wait for the responses
from the other projects included in the original thread, but never made it back
to follow up.

Officially governed projects are required to use the releases repo for driving
the automated release process. This ensure peer-reviewed releases and
consistency through the release. So to be a governed project, we really do need
to switch you over to this process.

Some other notes inline below.

Thanks,
Sean

> Hi Sean!
> 
> Thanks for raising this question.
> 
> As for Rally team, we are using self-tagging approach for several reasons:
>
> - Release notes
>
>   Check the difference between
> https://github.com/openstack/nova/releases/tag/17.0.2 and
> https://github.com/openstack/rally-openstack/releases/tag/1.0.0.
>   The first one includes just autogenerated metadata. The second one
> user-friendly notes (they are not ideal, but we are working on making them
> better).
>   I do not find a way to add custom release notes via openstack/releases
> project.

Nearly all projects have standardized on reno for release notes. This is the
preferred method for this and where general consumers of OpenStack deliverables
are now used to looking for these details. I would strongly recommend doing
that instead.

>
> - Time
>
>   Self-tagging the repo allows me to schedule/reschedule the release in
> whatever timeframe I decide without pinging anyone and waiting for folks to
> return from summit/PTG.
>   I do not want to offend anyone, but we all know that such events take
> much time for preparation, holding and resting after it.
>
>   Since there are no official OpenStack projects built on top of Rally,
> launching any of "integration" jobs while making Rally release is a wasting
> of time and money(resources).
>   Also, such jobs can block to make a release. I remember sometimes it can
> take weeks to pass all gates with tons of rechecks
>
>   https://github.com/openstack/releases#release-approval == "Freezes and no
> late releases". It is an opensource and I want to make releases on weekends
> if there is any
>   reason for doing this (critical fix or the last blocking feature is
> merged or whatever).

We do generally avoid releasing on Friday's or weekends, but now that our
requirements management has some checks, and especially for projects that are
not dependencies for other projects, we can certainly do releases on these days
as long as we are told of the urgency of getting them out there. The release
team does not want to be a bottleneck for getting other work done.