Re: [lldb-dev] [llvm-dev] [Openmp-dev] RFC: Release process changes
On Mon, 25 May 2020 at 23:10, Hans Wennborg via llvm-dev wrote: > +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. Agree, with one condition: this is a "best effort" to speed up the process, not to create a tug-of-war between release managers and code owners. All rules still apply: developers can ask for post-commit reversal if a problem is found, which can delay the release further and create merge problems if it flip-flops for too long. > My first thought is that doing all these releases sounds like a lot of > work. Indeed. And AFAIK we don't have that many users for them. Most users use some form of "internally thoroughly tested stable master". Back then, we agreed to intermediate releases somewhat reluctantly, but the overall value of having a "hind-sight more stable final release" is appealing. Multiple of them? Not sure. To me it sounds like we're replacing one process with three steps, where the final step's quality is "guaranteed to our best ability" for 6 one-step processes, but where the quality of any intermediate step is bound to the same testing rules. If we test them like "final", now we have *a lot* more work in between, and if we test them like "RC1", then we can't guarantee quality. There is a lot more work than just running a three-stage check + test-suite. Distros test on their packages, users test on their projects, etc. I don't think we can scale that process every two weeks. I'm happy to be wrong, and if distros, languages and downstream projects are happy with it, so am I. But I'd ask them first (ie not in llvm-dev), before taking a decision... cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Release process changes
These changes and clarifications make sense to me. On Thu, 21 May 2020, 12:00 Tom Stellard via llvm-dev, < llvm-...@lists.llvm.org> 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. > > > ** 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. > > > ** Create clear rules for what kind of backports are accepted during each >release phase. > > * Before RC1:Patches should be limited to bug fixes, important optimization > improvements, or completion of features that were started before the > branch > was created. As with all phases, release managers and code owners can > reject > patches that are deemed too invasive. > > * Before RC2: Patches should be limited to bug fixes or backend specific > improvements that are determined to be very safe. > > * Before RC3/Final: Major Release* Patches should be limited to critical > bugs or regressions. > > * Bug fix releases: Patches should be limited to bug fixes or very safe > and critical performance improvements. Patches must maintain both API > and > ABI compatibility with the previous major release. > > * Final bug fix release: Patches should be limited to critical bug fixes > only. > > > > What does everyone thing about these changes? > > > -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] [llvm-dev] RFC: Release process changes
On 05/21/2020 05:54 PM, John McCall wrote: > On 21 May 2020, at 14:59, Tom Stellard via llvm-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. > > If this is how things are currently managed, it’s hard to argue against it, > but I do think that — independently — we should make a stronger effort to > ensure that we have active code owners covering the entire codebase. > > My sense is that the ownership problem is deepest in two specific parts > of the project: compiler-rt and LLVM itself. Do you agree? > There are usually less backports for compiler-rt, so that hasn't been an issue for me, but I do agree that LLVM itself could use more code owners. -Tom > John. > >> >> >> ** 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. >> >> >> ** Create clear rules for what kind of backports are accepted during each >>release phase. >> >> * Before RC1:Patches should be limited to bug fixes, important optimization >> improvements, or completion of features that were started before the branch >> was created. As with all phases, release managers and code owners can >> reject >> patches that are deemed too invasive. >> >> * Before RC2: Patches should be limited to bug fixes or backend specific >> improvements that are determined to be very safe. >> >> * Before RC3/Final: Major Release* Patches should be limited to critical >> bugs or regressions. >> >> * Bug fix releases: Patches should be limited to bug fixes or very safe >> and critical performance improvements. Patches must maintain both API and >> ABI compatibility with the previous major release. >> >> * Final bug fix release: Patches should be limited to critical bug fixes >> only. >> >> >> >> What does everyone thing about these changes? >> >> >> -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] [cfe-dev] [llvm-dev] [Openmp-dev] RFC: Release process changes
On Tue, May 26, 2020 at 4:22 AM Renato Golin via cfe-dev wrote: > > On Mon, 25 May 2020 at 23:10, Hans Wennborg via llvm-dev > wrote: > > +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. > > Agree, with one condition: this is a "best effort" to speed up the > process, not to create a tug-of-war between release managers and code > owners. > > All rules still apply: developers can ask for post-commit reversal if > a problem is found, which can delay the release further and create > merge problems if it flip-flops for too long. I think the proposed release processes make sense to me, and agree with Renato's points. ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Release process changes
On 26 May 2020, at 18:24, Tom Stellard wrote: On 05/21/2020 05:54 PM, John McCall wrote: On 21 May 2020, at 14:59, Tom Stellard via llvm-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. If this is how things are currently managed, it’s hard to argue against it, but I do think that — independently — we should make a stronger effort to ensure that we have active code owners covering the entire codebase. My sense is that the ownership problem is deepest in two specific parts of the project: compiler-rt and LLVM itself. Do you agree? There are usually less backports for compiler-rt, so that hasn't been an issue for me, but I do agree that LLVM itself could use more code owners. Okay, thanks. John. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 46047] New: inconsistent behaviors at -O3
https://bugs.llvm.org/show_bug.cgi?id=46047
Bug ID: 46047
Summary: inconsistent behaviors at -O3
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -O3 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 11
Breakpoint 1: where = a.out`main + 79 at small.c:11:3, address =
0x0040117f
(lldb) r
Process 565482 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 565482 exited with status = 0 (0x)
(lldb)
/
As showed above, Line 11 is not hit by LLDB when setting breakpoint at Line 11.
However, Line 11 is hit by LLDB when using step-i.
/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:6:10, address =
0x00401131
(lldb) r
Process 565440 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 565440 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401131 a.out`main at small.c:6:10
3
4int main() {
5 for (int e=0; e<10; e++)
-> 6d[e] = 1;
7 if (d[0])
8c = a = (b == 0 || 1 % b);
9 if (a != 1)
(lldb) si -c 10
Process 565440 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401197 a.out`main at small.c:11:3
8c = a = (b == 0 || 1 % b);
9 if (a != 1)
10 abort();
-> 11 return 0;
12 }
(lldb)
$ cat small.c
#include
int a, b, c, d[10];
int main() {
for (int e=0; e<10; e++)
d[e] = 1;
if (d[0])
c = a = (b == 0 || 1 % b);
if (a != 1)
abort();
return 0;
}
--- Comment #1 from Yibiao Yang (杨已彪) ---
Created attachment 23535
--> https://bugs.llvm.org/attachment.cgi?id=23535&action=edit
the binary
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 46049] New: inconsistent behaviors at -O2
https://bugs.llvm.org/show_bug.cgi?id=46049
Bug ID: 46049
Summary: inconsistent behaviors at -O2
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -g -O2 small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 6
Breakpoint 1: where = a.out`main + 29 at small.c:6:7, address =
0x0040112d
(lldb) r
Process 578366 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 578366 exited with status = 0 (0x)
(lldb)
/
As showed above, Line 6 is not hit by lldb when setting breakpoint.
However, it was hit by lldb when using step-i
*/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main at small.c:4:7, address = 0x00401110
(lldb) r
Process 578410 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 578410 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401110 a.out`main at small.c:4:7
1int a, b, d=1;
2
3int main() {
-> 4 if (d)
5a = b==0;
6 if (a!=1)
7return 1;
(lldb) si -c 7
Process 578410 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401133 a.out`main at small.c:6:8
3int main() {
4 if (d)
5a = b==0;
-> 6 if (a!=1)
7return 1;
8 return 0;
9}
(lldb)
$ cat small.c
int a, b, d=1;
int main() {
if (d)
a = b==0;
if (a!=1)
return 1;
return 0;
}
--- Comment #1 from Yibiao Yang (杨已彪) ---
Created attachment 23536
--> https://bugs.llvm.org/attachment.cgi?id=23536&action=edit
the binary
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Release process changes
This set of changes sounds good to me. Thanks! -eric On Thu, May 21, 2020 at 12:00 PM Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> 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. > > > ** 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. > > > ** Create clear rules for what kind of backports are accepted during each >release phase. > > * Before RC1:Patches should be limited to bug fixes, important optimization > improvements, or completion of features that were started before the > branch > was created. As with all phases, release managers and code owners can > reject > patches that are deemed too invasive. > > * Before RC2: Patches should be limited to bug fixes or backend specific > improvements that are determined to be very safe. > > * Before RC3/Final: Major Release* Patches should be limited to critical > bugs or regressions. > > * Bug fix releases: Patches should be limited to bug fixes or very safe > and critical performance improvements. Patches must maintain both API > and > ABI compatibility with the previous major release. > > * Final bug fix release: Patches should be limited to critical bug fixes > only. > > > > What does everyone thing about these changes? > > > -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 process changes
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 we could get into a situation where everything works fine > on the release manager's machines, but is completely broken on other > platforms, and no way to fix until the next dot release. Maybe that > kind of breakage is less likely after the major release, but it still > seems it could make these dot releases less stable? > I think in order to
