Re: [lldb-dev] [Release-testers] 10.0.1-rc1 release has been tagged
Hi, Uploaded binaries for ARM & AArch64: e7cdf76722c9f5b90ec3f5d0e6cf5545badc6a7eaf8477b764a25845aee9a844 clang+llvm-10.0.1-rc1-aarch64-linux-gnu.tar.xz a11427f38283a522a22f4799c40518b09b72bdd4170ecb456544b459f74d1fc3 clang+llvm-10.0.1-rc1-armv7a-linux-gnueabihf.tar.xz AArch64 is green (yay! IIRC 10.0.0 had an issue). For ARM we still have PR44157 & PR44158 (which we also had for llvm 10.0.0), and I have also opened PR46092 and PR46093 for some new failures. I'll try to have a quick look to see if they're environment problems or if we can bisect them. Cheers, Diana On Mon, 25 May 2020 at 23:31, Michał Górny via Release-testers < release-test...@lists.llvm.org> wrote: > On Tue, 2020-05-19 at 18:22 -0700, Tom Stellard via Release-testers > wrote: > > Hi, > > > > I have just tagged the 10.0.1-rc1 release. Testers can begin testing > and uploading > > binaries. > > > > If you still want to get a fix into the 10.0.1 release, you still have > about a month > > to get your fix in. To request a patch be backported to the > release/10.x branch, > > file a bug and mark it as a blocker of the release-10.0.1 meta bug. > > > > Ok, it turns out my issues were due to py3.7+. I've requested > backporting one lit patch and with it, there are no new regressions. > > However, it made me notice that some clangd unittest are failing to > execute with duplicate command-line option errors but the errors are > ignored by lit. It happens when clang is linked to dylib, and it is > non-trivial to fix and I'm not sure if I'll be able to fix it myself. > Any and all help appreciated. > > I've tried to see if it is fixed in master but I can't seem to manage to > find a recent clang revision that wouldn't segfault all the way. > > -- > Best regards, > Michał Górny > > ___ > Release-testers mailing list > release-test...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] RFC: Release process changes
That all makes sense to me. The new process sgtm. On Wed, May 27, 2020 at 5:20 AM Tom Stellard wrote: > > On 05/25/2020 05:48 AM, Hans Wennborg wrote: > > On Thu, May 21, 2020 at 8:59 PM Tom Stellard via Openmp-dev > > wrote: > >> > >> Hi, > >> > >> I would like to propose a few changes to the LLVM release process. The > >> current process is documented here: > >> https://llvm.org/docs/HowToReleaseLLVM.html > >> > >> There are two parts to this proposal. The first is a list of > >> clarifications, > >> which are things we are currently doing that aren't documented. The second > >> is a list of changes which would actually modify how releases are currently > >> managed. > >> > >> > >> > >> *** Proposed Clarifications *** > >> > >> > >> > >> ** Release manager is allowed to commit changes to the release branch > >> without > >> code owner approval. However, the release manager is encouraged to > >> consult > >> with code owners or patch reviewers for non-trivial changes. > >> > >> It's not practical to get code owner approval every time. Either because > >> there > >> is no code owner or because the number of backports is too high (e.g. > >> pre-rc1 / pre-rc2). > >> This proposed clarification matches how releases are currently managed. > > > > +1 > > > > Maybe even stronger than "is allowed to commit", I think we should > > really think about it as the release manager owning the branch, and > > has full authority over what goes into it or not. Consulting code > > owners often makes sense of course, but for many patches, consulting > > the code owner (when there is one) is an unnecessary slowdown. > > > >> ** There is no official release criteria. > >> > >> We have time-based releases and when the release is 'ready' has been > >> up to the discretion of the release manager. Changing the release > >> criteria is out of the scope of this proposal, but I do think it would > >> be good to have a discussion about this as a community, so I'm going to > >> start a separate thread to discuss this. > >> > >> > >> > >> *** Proposed Changes *** > >> > >> > >> > >> ** Create a time-based bug-fix release schedule. After each major > >> release, make > >>a new bug-fix release every 2 weeks for 12 weeks (6 releases total). > >> > >> ** Eliminate release candidates for bug-fix releases. > >> > >> The current unofficial bug-fix release schedule is: > >> > >> X.Y.1-rc1 (6 weeks after major release) > >> X.Y.1-rc2 (10 weeks after major release) > >> X.Y.1-final (12 weeks after major release) > >> > >> I think this change will improve the overall test coverage of the release > >> branch. > >> I don't think the branch itself or even the release candidates get the same > >> level of testing as the final releases. If we are consistently > >> snapshotting > >> the release branch and putting out releases, I think this will make it > >> easier > >> and thus more likely that users will test out the release branch code. > >> > >> Additionally, with more frequent bug-fix release it removes the need to > >> have > >> release candidate releases. Every bug-fix release (up until the last one) > >> would serve the same purpose as our current release candidates in that they > >> are intended to give users an easier way to test the code before the final > >> release. > > > > My first thought is that doing all these releases sounds like a lot of > > work. Would you be doing all of them, or would there be some other > > arrangement? I suppose if we release this often, and also skip the > > RCs, we might become more efficient at it :-) > > > > Yes, I would plan to do all the releases. For 9.0.1, there were > 3 RCs, so 4 releases in total. Doing 6 instead of 4 is not that much > more work in my opinion. Also, we may end up skipping releases if > there aren't any new changes in the branch. But doing extra > releases would be good motivation to try to automates more parts of the > release process. > > If we do feel like 6 is too many we could lengthen the interval to 3 weeks, > which would give us just 4 releases. > > > Secondly, is having this many releases useful for downstream? One > > concern might be that downstream consumers just wait for the .6 one, > > and then there's no benefit and also no extra testing of the branch. > > Is it mainly increasing test coverage of the branch that's the > > motivation, or is it the demand for more bug-fix releases? > > > > From me as a distro package maintainer, I'm more likely to package > a final release than a bug-fix release. Especially if I know there won't > be another release candidate or final release coming very soon after. > > Besides increasing testing coverage, I think it helps other projects > avoid having to do things like this: https://lkml.org/lkml/2020/5/5/1446 > In this case, the kernel release cycle is about 2 months, so they can't > wait 3 months for a fix. > > > > Not having at least one release candidate sounds a bit scary to be. > > Without them w
Re: [lldb-dev] [llvm-dev] 10.0.1-rc1 release has been tagged
On 05/27/2020 01:04 PM, Machiel van Hooren wrote: > Hi, > > In this release as well as the 10.0.0 release, llvm fails to build on Windows > with the latest Visual Studio version (16.6.0) when building for debug. > See https://llvm.discourse.group/t/llvm-not-building-in-vusual-studio/1139/3 > Can you file a bug for this? -Tom > Something seems to go wrong with the debug build of llvm-tblgen.exe > > This problem does not exist on the current master branch. > > Machiel > > On 20-May-20 03:22, Tom Stellard via llvm-dev wrote: >> Hi, >> >> I have just tagged the 10.0.1-rc1 release. Testers can begin testing and >> uploading >> binaries. >> >> If you still want to get a fix into the 10.0.1 release, you still have about >> a month >> to get your fix in. To request a patch be backported to the release/10.x >> branch, >> file a bug and mark it as a blocker of the release-10.0.1 meta bug. >> >> -Tom >> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] RFC: Release qualification criteria
On 05/25/2020 06:10 AM, Hans Wennborg wrote: > On Thu, May 21, 2020 at 8:59 PM Tom Stellard via Openmp-dev > wrote: >> >> Hi, >> >> I'm splitting this discussion off of my RFC for release process >> changes. >> >> We currently have no official release qualification criteria. In >> other words, we don't have any blocking tests that need to pass in >> order to make a new release. >> >> We do time-based releases, which is not always compatible with having >> quality-based criteria for tagging a final release. So, I think another >> way to look at this issue is to talk about what kinds of CI testing we >> have for trunk and if there are any additional kinds of >> testing (e.g. compile-time performance) that we want to prioritize. >> >> So, for the purposes of this discussion, I see 2 main questions: >> >> 1. Should we define some set of blocking tests that need to pass before a >> release >>can happen? > > I suppose we could have a baseline about clang bootstrap + lit tests > (what test-release.sh does essentially) passes on major platforms. > I think for testing like this that can be easily automated we're almost better off just adding these as CI tests from trunk rather than having them gate releases. -Tom > But the really interesting question for me is really what kind of bugs > we're considering as release blocking. It's the trade-off between > shipping on (or not too much behind schedule) and delaying to > investigate more issues that's tricky.. > >> >> 2. What gaps do we currently have in our CI testing? > > The latest release made it clear we don't track compile time very > well, or at least not well enough to catch the regressions in that > release early enough. > > Also I think there's no 32-bit Windows buildbot anymore :/ > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
