Open Stack

On 2020-06-10 23:56:41 +0200 (+0200), Thomas Goirand wrote:
[...]
> Is the re-tag of services THAT time/resource consuming?
[...]

It means divergent tooling and process for releasing our libraries
vs releasing our services, and additional cognitive load for
projects to need to decide which deliverables should follow what
release model.

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

You don't know that today for our libraries either, since they
branch from non-rc version numbers and may produce additional point
releases in their stable/$cycle branch up until near the coordinated
release.

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

Except that they typically branch long, long before the coordinated
release and need to have their version numbers included in
requirements lists for other projects' master branches. It might be
doable to have them use release candidates on the new stable branch
until close to coordinated release and then tag them all with
version numbers and update every requirements list to compensate,
but that seems like it would turn into a massive scramble vs the one
patch version here and there that they normally accrue late in the
cycle.

> With this proposal, every project will treat the scheduled first
> RC as the release time itself, and move on to work on master.

They already do. Right now when rc1 is tagged and the stable/$cycle
branch is created from it, subsequent fixes enter master and get
backported to stable/$cycle and then an rc2 (or 3, or 4...) is
tagged in stable/$cycle as needed. At coordinated release time
whatever the corresponding commit was for the last rcN tag was gets
re-tagged as the release version, and in most cases that's identical
to the rc1 tag (no additional fixes during release candidate
period). The new proposal would follow the same process, just not
stick rcN prefixes on the tags and increment the last number in the
tag instead, then not do any re-tagging of the last tag at
coordinated release time because the versions of the last tags are
already normal version numbers.

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

I don't see why you would expect this any more than today. Projects
backport patches from master to the new stable/$cycle branch during
this period already, the incentive to do that doesn't change based
on what the tags created in that branch look like.

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

You keep asserting this, but the plan is precisely intended to
maintain this period, and says nothing about getting rid of it.

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

The original plan as written explains exactly why:

    "We [...have] a confusing collection of release models with
    abstract rules for each and not much flexibility. Projects are
    forced to choose between those models for their deliverables,
    with limited guidance. And much of the rationale for those
    models (exercise release machinery early and often, trigger
    external testing...) is no longer valid."

We already ask far too much of our project teams, and simplifying
the release models and processes they have to understand and follow
should ease some of their overall burden, freeing up their time for
more important remaining tasks.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200610/591fca8d/attachment.sig>