Open Stack

Hi,

On Wed, Jun 10, 2020 at 11:59 PM Thomas Goirand <zigo at debian.org> wrote:

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

How do you solve it for thousands of other packages that don't do RC?


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

In ironic we have been doing what Thierry proposed for years without seeing
any negative effects.

And yes, the first RC *is* a release, so the projects will pretty
rightfully treat it like that.


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

Maybe it works this way for Nova and other core projects, but it has never
worked for everyone else. People either consume master (like RDO) or final
releases (like pretty much every final consumer).

Maybe, judging by your messages, Debian was actually the (only) consumer
that cared about RC releases, although I cannot comment on how much actual
testing we got specifically from people installing RC releases from Debian.

Dmitry


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200618/1c40e797/attachment.html>