[llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros

[Renato Golin via llvm-dev]

Folks,

First, thanks everyone that replied, it made many things much more
clear to many people (especially me!).

But would be good to do a re-cap, since some discussions ended up
list-only, and too many people said too many things to keep track. I
read the whole thread again, and this is my summary of what people
do/want the most.

TL;DR version:

 * Upstream needs to be more effective at communicating and
formalising the process.
 * Downstream / Distros need to be respectively more vocal / involved
about testing ToT and releases.
 * Upstream may need to change some process (bugzilla meta, feature
freeze, more back-ports, git branches) to facilitate downstream help.
 * Downstream needs to be more pushy with their back-port suggestions,
so we do it upstream more often.
 * We all need to come up with a better way of tracking patches for
back-port (separate thread ongoing)

Now, the (slightly) longer version:

By far, the most important thing is cadence and transparency. We
already do a good job at the former, not so much at the latter.

The proposals were:
 - Formalise the dates/duration on a webpage, clarify volunteered
roles, channels (release list, etc).
 - Formalise how we deal with proposals (llvm-commits to release list
/ owner), some suggested using git branches (I like this, but svn).
 - Formalise how we deal with bugs (bugzilla meta, make it green),
this could also be used as back-port proposal.
 - Formalise how we deal with back-ports, how long we do, overlapping
minor releases, etc.

The other important factor is top-of-tree validation as a way to get
more stable releases. We have lots of buildbots and the downstream
release folks are already validating ToT enough. We need the distros
in as well.
Same goes for releases, but that process isn't clear, it needs to be.

The proposals were:
 - Have distros build all packages with ToT as often as possible, report bugs.
 - Do the same process on stable branches, at least once (RC1).
 - Downstream releases also need to acknowledge when a validation came
back green (instead of just report bugs).
 - All parties need to coordinate the process in the same place, for
example, a meta bug in bugzilla, and give their *ack* when things are
good for them.

The third big point was following changes on long running downstream
stable branches. Many releases/distros keep stable local branches for
many years, and have to back-port on their own or keep local patches
for that long.

The proposals were:
 - Better tracking of upstream patch streams, fixes for old stable
release bugs. Making a bug depend on an old release meta may help.
 - Distros and releases report keeping lots of local patches (some
already on trunk). Back-porting them to minor releases would help
everyone, keeping old releases for longer, too.
 - Create patch bundles and publish them somewhere (changelog?
bugzilla?) so that downstream knows all patches to back-port without
duplicating efforts.

Other interesting points were:
 - Moving versions for small projects / API users is not an easy task.
Having release numbers that make sense and multiple releases at a time
may help not introduce API changes to old releases.
 - Volume of changes is too great. Having a slow down (staged freeze)
may help developers invest more in stability just before the branch.
We sort of have that, needs formalisation.
 - If we have major bugs after the branch, we stop the whole process,
which makes it slower and more unpredictable. Feature freeze may help
with that, but can affect the branch date.
 - Volunteering is still required, but we could keep documented who
does what, and change the docs as that changes.
 - Upstreaming package maintenance scripts had mixed views, but I
still encourage those that want, to try.

cheers,
--renato