Open Stack

On 6/10/20 6:56 PM, Jeremy Stanley wrote:
>> This means that we wont have tags for the pre-release.
> 
> We will, they'll just have release-like numbers on them

It doesn't make sense.

>> If the issue is just cosmetic as you say, then let's keep rc1 as
>> the name for the pre-release version.
> 
> The workflow difference is primarily cosmetic (other than not
> necessarily needing to re-tag the last release candidate at
> coordinated release time).

Is the re-tag of services THAT time/resource consuming?

> The issue it solves is not cosmetic: we
> currently have two primary release models, one for services and
> another for libraries. This would result in following the same model
> for services as we've been using to release libraries for years,
> just at a different point in the cycle than when libraries are
> released.

When I'll look into my Debian Q/A page [1] I wont be able to know if I
missed packaging final release just by looking at version numbers (ie:
track if there's still some RC version remaining and fix...).

I'd be for the opposite move: tagging libraries as RC before the final
release would make a lot of sense, and help everyone identify what these
versions represent.

On 6/10/20 6:33 PM, Mark Goddard wrote:
> I think the issue is that currently there is a period of time in which
> every project has a release candidate which can be packaged and
> tested, prior to the release. In the new model there is no obligation
> to release anything prior to GA, and I expect most teams would not.

There's also that above that Mark wrote...

On 6/10/20 7:05 PM, Jeremy Stanley wrote:
> You and I clearly read very different proposals then. My
> understanding is that this does not get rid of the period of time
> you're describing, just changes the tags we use in it:

With this proposal, every project will treat the scheduled first RC as
the release time itself, and move on to work on master. Even worse:
since they are supposed to be just RC, you'll see that projects will
care less to be on-time for it, and the final version from projects will
be cut in a period varying from start of what we used to call the RC1,
to the final release date.

So this effectively, removes the pre-release period which we used to
have dedicated for debugging and stabilising.

On 6/10/20 6:56 PM, Jeremy Stanley wrote:
> I think the proposal has probably confused some folks
> by saying, "stop having release candidates [...and instead have a]
> candidate for inclusion in the coordinated OpenStack release."

Jeremy, my opinion is that you are the person not understanding what
this proposal implies, and what consequence it will have on how projects
will release final versions.

> It would basically still be a "release candidate" in spirit, just not
> in name, and not using the same tagging scheme as we have
> traditionally used for release candidates of service projects.

Please keep release candidate not just "in spirit", but effectively,
with the correct name matching what they are supposed to be. Otherwise,
you're effectively removing what the RCs were.

If that is what you want to do (ie: stop having release candidates),
because of various reasons, just explain why and move on. I would
understand such a move:
- if we declare OpenStack more mature, and needing less care for
coordinated releases.
- if there's not enough people working on stable branches between RC and
final releases.
- if OpenStack isn't producing lots of bug-fixes after the first RCs,
and they are now useless.

I wouldn't understand if RC versions would be gone, just because numbers
don't look pretty. That's IMO a wrong answer to a wrong problem.

Cheers,

Thomas Goirand (zigo)

[1]
https://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org