Overhaul the release process docs

[hans]

Summary

We previously had two different documents: "How To Validate a New Release" and "How To Release LLVM To The Public", both with lots of text, but most of it pretty dated and not very informative.

Here's an attempt at providing a single doc that focuses on developers ("how do I get my patch merged") and users ("what's an LLVM release"), as well as providing details on who does what and when.

Please let me know what you think.

[dim]

The rest LGTM.

docs/ReleaseProcess.rst

19

Maybe say "aim to ship", since this kind of promise always tends to slip a little. :)

[hans]

docs/ReleaseProcess.rst

19

Actually, since 3.5 we've shipped on this schedule (except 3.6 which was two days early), so I wouldn't say that it always tends to slip :-)

I'd like to avoid adding weasel words here as long as we can keep this up.

[hans]

Tom, what do you think?

[sylvestre.ledru]

docs/ReleaseProcess.rst

64

You can add me for Debian packaging

[rengolin]

A few comments on this...

1. There is a lot of good information in HowToRelease that should not go to waste. I'm refactoring it now and should be *much* better.

2. We actually need two documents. One of them is for release testers and managers, and the other is for the public. The former tells about the whole process, the people that do it, how to do it, what do we expect, etc. The latter tells about the schedules, time it takes, process to report a bug from outside and the kind of bug we mark as release blocker.

3. The test-suite is *still* not being done by the test-release script, nor by just running "make test-suite", so we can't remove the LIT part yet. For ARM and AArch64, I *always* run the test-suite, and I seriously recommend every release tester to do the same, so until the way we wan just use make/ninja, we need the info here.

cheers,
--renato

[rengolin]

docs/ReleaseProcess.rst

64

I think we need two lists: one with the upstream testers (with arch+OS, not just OS *or* arch), and one for upstream distro packagers.

We need to have this table clear for all *supported* platforms that we do releases, including x86, x86_64, ARM, AArch64 and MIPS. If the other platforms want to claim "official support", they have to volunteer for release testing and add their names to this table.

We also need people testing different OSs on each platform, and that's where Sylvestre and others get in. I don't think we *need* different packages for different distros in the upstream release page, and the binary packages should be done in a minimal configuration that "can" work on newer distros.

But each distro maintainer, like Sylvestre, should be creating the packages directly (as they are doing), and thus, making the download link on the page redundant and potentially misleading.

[dsanders]

docs/ReleaseProcess.rst

93–94

FWIW, I've always used the clang+llvm-*.tar.xz tarballs for external testing since this is the package we release and doesn't have anything left over from the build

110

Did you mean pre-release here? Going by the reference to -final I think it should say release.

112–113

I'm not sure what is meant by 'non-release testing' here.

Also, should there be a bullet point for -svn-path? It's mostly useful for testing the tip of a branch (including trunk) before a tag has been created.

[hans]

Sorry for the slow reply. I've been on vacation, and am still traveling this week.

In D21880#473499, @rengolin wrote:

A few comments on this...

1. There is a lot of good information in HowToRelease that should not go to waste. I'm refactoring it now and should be *much* better.

Thanks for working on this. My feeling was that there was so much out-of-date info in these documents that it might be easier to nuke most of it and start over.

2. We actually need two documents. One of them is for release testers and managers, and the other is for the public. The former tells about the whole process, the people that do it, how to do it, what do we expect, etc. The latter tells about the schedules, time it takes, process to report a bug from outside and the kind of bug we mark as release blocker.

I think having two documents is confusing, at least in the current form.

ReleaseProcess.html is titled "How To Validate A Release". I think that's confusing, and that it should focus on describing the release process for LLVM developers and users.

HowToReleaseLLVM.html seems to have the purpose of describing what the release manager should do to create branches, etc. It seemed pretty out-dated so I deleted it. I suppose I'm the intended audience, but I never use it.

3. The test-suite is *still* not being done by the test-release script, nor by just running "make test-suite", so we can't remove the LIT part yet. For ARM and AArch64, I *always* run the test-suite, and I seriously recommend every release tester to do the same, so until the way we wan just use make/ninja, we need the info here.

OK, what do you think about removing the confusing HowToReleaseLLVM.html document, re-purposing ReleaseProcess.html to focus on describing the release process for LLVM devs and consumers, and have a sub-section in that about how to test a release?

I think the RELEASE_TESTERS.txt file is great, btw.