Re: [lldb-dev] [llvm-dev] RFC: Release process changes
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? 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] [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
Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update
On 3 Jun 2021, at 18:19, James Y Knight via llvm-dev wrote: > I've just tried out discourse for the first time. It is not clear to me how > to use it to replace mailing lists. It has a setting "mailing list mode", > which sounds like the right thing -- sending all messages via email. Except > that option is global -- all messages in all categories on the llvm > discourse instance. Which definitely isn't what I want at all. I don't want > to subscribe to MLIR, for example. > > In general, I'd say I'm pretty uncomfortable with switching from a mailing > list to discourse. Discourse seems entirely reasonable to use for > end-user-facing forums, but I'm rather unconvinced about its suitability as > a dev-list replacement. Other communities (e.g. python) seem to have a > split, still: mailing lists for dev-lists, and discourse for > end-user-facing forums. > > I'd also note that Mailman3 provides a lot more features than what we're > used to with mailman2, including the ability to interact/post through the > website. > > Maybe someone can convince me that I'm just being a curmudgeon, but at this > point, I'd say we ought to be investigating options to have Someone Else > manage the mailman service, and keep using mailing lists, rather than > attempting to switch to discourse. I think that mailing lists have proven repeatedly that they’re actually very bad for the sort of technical conversations we want to have in the community. It’s possible to put a lot of work into your mailing-list experience and end up with something that half-solves some of these problems, but it takes a lot of time and expertise, and you’re left with something that still suffers the inherent flaws of email. Let me try to explain why, using the ongoing byte-type RFC as a focusing example. First off, this is an important conversation that ought to be of interest to a large number of LLVM developers. Monitoring a high-traffic mailing list takes a lot of time; I would say that most LLVM developers don’t proactively keep up with llvm-dev. I only became aware of this conversation because someone thought to explicitly CC me into it. There are almost certainly some people who ought to be engaged in this thread who still aren’t aware of it. A major part of why that’s the case is that mailing lists lack structure beyond the Reference structure of threads. There is no inherent categorization or tagging in a mailing list; by default, readers see a jumble of every single thread. And people are often reluctant to split mailing lists by topic, and when they do sometimes conversations get unnaturally divided, or something that should be of broader interest gets unnecessarily pigeon-holed. So if I want to find things that are interesting to me, I have to look at every single active thread to see what’s going on. Now, in some cases, I can have that done automatically for me. I could, for example, set up a filter that puts all the RFC threads in a high-priority mailbox that I can scan more frequently. But that has two problems. First, not every generally-important thread is marked as an RFC; notably, this thread isn’t. If I set up this filter, I’d probably be a lot less likely to read the mail mailbox for the list, and so I’d probably miss most of these threads. And second, I can do that for myself, but I can’t make other people do it. There are people who aren’t reading and contributing to important threads because they aren’t aware of them. The lack of structure creates a firehose effect that undermines the ability of conversations to reach a broader consensus, no matter what I do locally. And honestly, I think that’s one of the biggest problems affecting LLVM right now: we have no good consensus mechanism as a community to change LLVM IR. We have RFC threads, and then we have “make a presentation at at an LLVM Developer’s Conference, probably the US one, and then convene a roundtable to try to get people on board with your plan.” As a result, I think there’s a lot of reluctance to change IR when, honestly, IR is supposed to be an evolving tool that needs to change in order to solve problems better. I’m not saying that the mailing list is the sole cause of this problem, but I do think it contributes. Secondly, what structure does exist for mailing lists is not good for technical conversations. The deep problem is the tree structure of threads, which is mathematically pleasing but manifestly leads to worse results. Different forks of the thread end up repeating the same arguments because people don’t see that that conversation has already happened — or worse, different forks *don’t* repeat the same arguments because the people involved in them aren’t aware of the rest of the thread. I’ve seen so many threads where different branches continued on to reach completely different conclusions, or where one contributor jumps from one branch to another, leaving the people who were only engaged in the old branch thinking that the thread
