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

[Sean Silva]

On Wed, Apr 3, 2013 at 11:39 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:

> Sean Silva <silvas at purdue.edu> writes:
>
> > The largest barrier that I see, which nobody seems to have mentioned, is
> > the community culture.
> [snip]
>
> Well, the plan I described assumed "zero collaboration from the
> developers" for exactly the reasons you mentioned.
>

Indeed. I was just trying to bring it up as an explicit issue rather than
assuming a priori that it was insurmountable.


>
> IMO it is possible to bring a "maintenance branch" which is preferable
> to the development branch for those LLVM users searching for stability,
> without disturbing current development process. After all, you only need
> to make it a more attractive option than jumping into ToT tracking.
>

I'm not sure how difficult it actually is to follow ToT compared to one
huge pain when upgrading for our full releases. I think it would be
valuable to obtain feedback from projects that rely on LLVM as to how they
go about integrating LLVM into their project and how our releases (and
potentially dot-releases) would integrate into their development process.

I believe that the way that the Rust language is doing things is to keep a
separate fork of LLVM on github, where they put in the patches to work
around bugs that they find. Their main repository then keeps this LLVM fork
pinned on particular commits ofthe fork (using git's submodule
functionality). This has the benefit that they can easily cherry-pick
patches onto their fork whenever they want (or backport, if necessary).
They can then merge in major releases at their leisure, and I believe that
git is smart enough to recognize the cherry-picked patches and merge with
no hassles.
If multiple projects were to adopt this kind of "structured" approach to
depending on LLVM, I think that what is effectively a "stable branch" could
be achieved with just a tiny bit of coordination and sharing. Each project
fixes the issues that immediately affect them and share their
cherry-picking/backporting with other interested projects. This would
require minimal manpower from within the LLVM project proper (possibly just
one person in contact with the various dependent projects to make sure that
everyone is on the same page; a sort of "ambassador") and we would know
that the branch is fixing real issues that have come up in practice with no
effort wasted cherry-picking/backporting patches for a "theoretical"
stability gain.

i.e., we could empower our users to contribute the effort that they are
*already* putting into cherry-picking/backporting to maintain a "stable
community branch" for us.



>
> > Also, it's not clear that we have the infrastructure to test these dot
> > releases on all our supported platforms. IMHO, without that, it's hard to
> > have much confidence in the dot release, and I wouldn't want to put out
> > "LLVM 3.2.1, tested on Linux only".
>
> If you cover a large fraction of the users, why not?
>
>
I think that for a "personal" stable branch it would be an appropriate
policy.

However, for an "official LLVM-endorsed and supported" stable branch, such
a policy could potentially alienate the 1-"large fraction" of the users
that you don't cover, and those are exactly the users that we *need* in
order to help LLVM support their platforms better. This is a general social
phenomenon: larger and more-public organizational units need to be more
careful to ensure that they are not perceived as alienating or
discriminating. E.g. if you are serving dinner to close friends, nobody is
going to blame you for not having e.g. a vegetarian or gluten-free option.
But you can be sure that if the White House holds a dinner, they are going
to ensure that they have a vegetarian or gluten-free option.

So it might make sense for the a "stable branch" to be initially an
independent effort by a group of interested individuals who are willing to
put the time into maintaining it, rather than immediately an "official"
stable branch as in Tom's proposal. This will allow building out
infrastructure and automation for the stable release process and platform
support. For example, coming up with a clear procedure for making a
platform one of the tested platforms for the stable release (ideally, it
should be as simple as donating a machine running that platform and keeping
an eye on it).
If this effort shows that a stable branch delivers real value to our users,
for example if some linux distribution decides that it is sufficiently
valuable to package the stable dot-releases, or we receive lots of positive
feedback from our users who are using the stable branches, then it should
be straightforward to brand it with an official LLVM sticker.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/6cbee9be/attachment.html>