Open Stack

On Mon, 2021-11-29 at 13:09 +0000, Jeremy Stanley wrote:
> On 2021-11-29 13:21:52 +0100 (+0100), Jean-Philippe Evrard wrote:
> [...]
> > My experience at SUSE was that the branching model is even
> > debatable: It was more work, and after all, we were taking the
> > code we wanted, and put our patches on top if those didn't make
> > upstream/weren't backported on time for x reasons (valid or not
> > ;)). So basically, for me, the stable branches have very little
> > value nowdays from the community perspective (it would be good
> > enough if everybody is fixing master, IMO).
> [...]
> 
> The primary reason stable branches exist is to make it easier for us
> to test and publish backports of critical patches to older versions
> of the software, rather than expecting our downstream consumers to
> do that work themselves. If you're saying distribution package
> maintainers are going to do it anyway and ignore our published
> backports, then dropping the branching model may make sense, but
> I've seen evidence to suggest that at least some distros do consume
> our backports directly.

just speaking form personal experince backporting patches upstream and downstream for redhat osp.
i have much much higher confidence in backporting patches to downswtream by first backproting
them upstream via the stable branches due to the significantly better upstream ci before the patch
is merged. most of our downstream ci happens after the code is merged as part of a unifed build/compose that
is then tested by our QE often sever weeks after its merged before the release of our next downstream .z release.

We have some patch ci but its really minimal in comparison to the test coverage we have upstream on stable
branches and its also more work to do a downstream only backport or premtive downstream backport anyway.
since we skip releases downstream if i want to do a downstream only backport e.g. because its a feature i have
to backport acrross 3+ release to train in one go which is way harder then resolving conflicts  per release.
if im doing both an upstream backport and a premtive downstream backport to not have to wait for upstream to merge
its also kind of a pain as if i need to make revsions upstream we will get a merge confilct the next time our downstream
barnch is rebalsed.

so basically if i can i will always do an upstream only backport and wait for the change to by syned downstream via an import.
To me the stable brances privide great value, even more value if we allowed feature backports as it woudl elimiate
the need for us to carry those downstream. if we could backport features it we could almost avoid downstream branched entirely for
everything other then perhaps CVE, fixes or other very rare cases. even in there current state however i stongly think our stable
branchs add value and its a compelling aspect of our community. not all opensouce project maintain upstream stable branches as we do
and in such cases you are often forced to choose between runing the package from your disto or the project directly to get the fixes
and features you need.

while we do eventually stop importing from upstream into our downstream packages OSP13z15 which released in march this year
was a fulll import form stable/queens the  osp 16.2.2 next year will also be a fully import form stable/train once our cherry-pick only
release 16.2.1 is out the door to customers. while we do carry patches downstream which must be rebased on top of upstream every time
we import, upstream stable adds a lot of value and we mitigate the overhead of downstream patches by applying a very strict feature backport
policy which basically ammount to no api,db,rpc or versioned object changes. you would be suprised how many feature still can be backported
with those restrictions but it avoid the upgade and interoperablity impact of most feature backports.

tl;dr let please keep the upstream stable branches for as long as pepole are willing to maintain them.