[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Óscar Fuentes]

Tom Stellard <tom at stellard.net> writes:

> I would really like to see the LLVM project start to make official bug fix
> releases (e.g. 3.3.1, 3.3.2, etc.).  I think that this would be useful for a
> lot of the users of LLVM, especially projects that use LLVM as a library.
[snip]
> What does everyone think?  Would something like this be doable?

As a LLVM library user I considered creating a bug fix branch and
devoted some time to study how it would run. Unlike your proposal, my
premise was to assume zero collaboration from the developers and the
LLVM project infrastructure itself (just to cover the worst case.) It
would run by just monitoring bugzilla and commit notifications in the
mailing lists and cherry picking changes into a git repo hosted in
Github.

The goal was to monotonically increase the quality of the branch. I
concluded that it is doable with about 10 hours/week, although there are
some serious constraints. From the top of my head, in no particular
order:

1. One must assume that the development branch will diverge fast on the
   "hot" areas, which are precisely those were most bugs tend to happen.
   So not all fixes could be imported.

2. The covered platforms might be limited (in my case, just
   x86/Linux/Windows and x86_64/Linux.) Unless you have the necessary
   machines or put too much trust on the bug fix author.

3. There would be cases where you cannot decide if a patch that fixes a
   bug jeopardizes the global quality of the branch, so when in doubt,
   those fixes should be ignored. This could be alleviated somewhat
   asking the opinion of the relevant developers but, as mentioned, I
   didn't count on them.

4. At some point, the development branch would be so far away that it
   would make little sense to keep maintaining the bug fix branch. In
   that regard, the lifetime of the bug fix branch would start with a
   Y.X release and end with a Y.(X+1) release, unless for the cases
   where applying a fix to a previous version would be a no-brainer.

5. There would be no bug fix releases. As mentioned, the bug fix branch
   quality must monotonically grow over time. The idea of a release
   implies "bug fixing the bug fixes", something you can not do unless
   the developers are working with you. And it doesn't make much sense
   when you work on a relatively short period (see point 4.) So in this
   point, it must be stressed that risky bug fixes should be held back
   or incorporated on special branches if they are important enough.

There are other factors/ideas involved, such as semi-automatically
detecting changes that touches areas modified by a previous bug fix (for
examining them in detail), if completely ignoring the areas not
specifically covered by the review process (see point 2), using a
stage-based process where fixes advance on a series of "maturity level"
branches, etc.