Re: [lldb-dev] [3.8 Release] Release status
On Mon, Feb 22, 2016 at 10:48 PM, Hans Wennborg wrote: > I had hoped to tag rc3 today (I feel like I've said this a lot > lately), but it's at least really, really close. I'm waiting for: > > - r261297 - Implement the likely resolution of core issue 253. > Still in post-commit review. > > - D17507 - The controlling expression for _Generic is unevaluated > New for today. Waiting for review. This one should hopefully be relatively straight-forward to review. ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev wrote: > Folks, > > There has been some discussion on IRC about SVN hosting and the perils > of doing it ourselves. The consensus on the current discussion was > that moving to a Git-only solution would have some disvantages, but > many advantages. Furthermore, not hosting our own repos would save us > a lot of headaches, admin costs and timed out connections. Not everyone thinks git is a step forward. Please do not force people to use a "git-only" solution. > TL;DR: GitHub + git submodules [1] could replace all the functionality > we have currently with SVN. > > (also GitLab, BitBucketc, etc). > > Here are some of the arguments made on IRC... > > 1. Due to SVN, we can't re-write history. If we use some GitHub > properties [2], we could have the same effect. > > 2. Due to SVN, we have a mandatory time sequence, so commits go first > in LLVM, then Clang (for example), and buildbots don't get lost. If we > use submodules [1], we can have a similar relationship, but in a more > explicit way, and the problem could be solved elegantly. I actually consider the monotonically increasing revisions to be a feature, but not sufficient to warrant a decision one way or the other. > 3. Some people still can only use SVN. For that, GitHub has an SVN > interface [3] to the repositories. Are we sure that github's svn integration works with common tools on Windows, like TortoiseSVN? > 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator, > etc. Not only this incurs in additional admin cost, but it also gets > outdated, locally modified, and it needs to be backed up, etc. GitHub > gives all that for us for free. > > 5. We can still use Bugzilla (and lock GitHub's own bug system), but > we can also use GitHub's system to manage releases (it's actually > quite good for that). > > 6. GitHub has automated testing of merge requests, meaning we can have > pre-commit tests enabled on a set of fast bots, triggered by GitHub's > own validation hooks. Even though that wouldn't cover everything, > having a few pre-commit bots would considerably reduce the need to > revert patches [citation needed]. > > 7. With git submodules, we'd probably want to follow the same style we > have today (llvm-projects/) instead of modelling how they look in > tree (llvm/tools/clang still as a symlink). > > 8. Once we're solo Git, we can shop around *much* more easily. By > using SVN, we're basically forced to host, or choose Source Forge. > Using just Git, we can choose GitLab, BitBucket and many others, if > GitHub is not appealing enough. Essentially, it doesn't matter where > you are, the tools are good, there and largely replaceable [citation > needed]. > > What do people think? Any issue not covered that we should? How would > that disrupt downstream users? Would it be a temporary disruption, but > with long lasting benefits? Or will it just break everything for you? I'm not opposed to moving to GitHub, provided its svn interface proves to meet our needs. I am opposed to switching to a git-only solution, but I'm unclear whether that's currently on the table or not. ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 4:27 PM, Renato Golin wrote: > On 31 May 2016 at 21:24, Aaron Ballman wrote: >> Are we sure that github's svn integration works with common tools on >> Windows, like TortoiseSVN? > > That's a good question. Can you try them out and report back? From my very simple testing, yes. However, since I don't use github for much, it's hard to feel comfortable with my level of testing. I'm sure for read-only access, this will be sufficient. For read/write access, I am less confident, so if others have had more experience with this on Windows, I would appreciate hearing about it. ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev wrote: > On 1 June 2016 at 17:02, John Criswell wrote: >> Do you have a set of volunteers lined up to do such a migration? Getting >> people willing to do the migration will obviously be key, and that was the >> one thing I didn't see in the original email. > > Hi John, > > Well, first we need to know if people are in favour, then if the > migration won't bring any serious problem, and then we can think of a > migration plan. :) > > So far, it seems people are mostly in favour, with a few that reported > being locked into SVN. I had anticipated that, and have proposed > GitHub's SVN integration, which allows read-write access, so it should > be mostly ok. We need more tests on that side to be sure, though. > > The biggest problem we're facing right now is how to sync the repos. > The existing llvm-repos format with all projects as sub-modules seem > to be a good candidate, but I still haven't seen a consensus on how > we'd do that. > > About the migration plan, most people seem to agree a step-by-step > process is necessary. So, first we move to git-only, possibly with > sub-modules, Despite people's reservations of a git-only repository? I mean, we still don't know that this will even work for people who wish to stay with SVN. I am really not comfortable with this decision based on "it should be mostly ok" from above, but maybe I am misunderstanding something. ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On Wed, Jun 1, 2016 at 3:10 PM, Renato Golin wrote: > On 1 June 2016 at 19:36, Aaron Ballman wrote: >> Despite people's reservations of a git-only repository? > > Hi Aaron, not at all! > > I was especially vague on my first email to make sure SVN folks would > be shoved on the side, but John had asked for a full plan *in the case > we move*, and I was just completing the picture. Oh! That makes perfect sense to me. Thank you for the clarification! > Having said that, I can't take that decision alone, and my own opinion > is irrelevant on the grand scheme. > > Right now, our main repo is in SVN with most people using Git. Our main repo is in SVN; I would say we don't know what most people are using (aside from "svn for write access because it's the only option"). > If the > vast majority vote for the move, it wouldn't be fair to continue to > force SVN on them, and it would be overall less effort for the few > people that prefer SVN to have a bit more work than they have today, > to save the majority of Git users the extra work. I have no idea how > much people is enough to move to Git, but unless we fix the sub-module > problem, there's no point in even trying. Fair points, but with the caveat that people using git today have a workable solution (as I understand it, and I could be totally wrong) using the git mirrors. That's not a reason to not transition from svn to git, however. > So, my personal points are: > > 1. We can only move IFF the Git solution is technically equivalent or > superior than what we have today. > > 2. We should only move IFF the vast majority will see benefits from > it, even if a small minority will see some increased effort. Of > course, the balance of efforts has to be overall positive. Agreed with both of these points. > 3. We should not move if there is no replacement for SVN users at the > moment. Agreed. > We should try to encourage SVN users to move to Git, to speed > up the move, though. This is implying that we will move, which I think should still be left as a vague question mark until we have more answers. Based on that, I think it's premature to encourage anyone to switch to git. > I'm assuming the SVN vs. Git argument is not just a personal thing, > but a tooling / infrastructure issue. The bigger picture here is not > which VCS is better, but getting rid of a huge infrastructure cost > from our part, which nowadays means moving to Git or using > SourceForge. I agree that there are infrastructure costs to consider. I just hope we don't consider those at the expense of a functioning system that people are used to using and already have workflows based on. Git may be the new shiny, but it's not what we use today for LLVM. It's sometimes easy to forget there's also cost with telling the community "please go learn a new, very different toolset so that you can continue to contribute to the project." I'm not making a claim that the costs aren't worth the gains (because this might very well be the correct time to switch VCS), but I am worried when emails make it sound like switching to git-only is a foregone conclusion, which is a bit of a strange way to start a discussion about whether the community wants to switch. That being said, I like that we're discussing what a switch would look like were one to occur so that we can suss out all the pros and cons! ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?
On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight wrote: > IMO, if we're switching to git, we should just be clear up front that all > committers will be expected to switch to git as well -- or at least, if they > want to use something else (e.g. mercurial's git bridge/etc), that it's > their own problem. So anyone still using svn should not expect it to work? That sounds like a great way to alienate (at least some) active contributors. However, I do agree that clarity would be nice regarding whether the decision to switch to git has been "finalized" or not. > It is truly NOT that big an imposition to require the use of git. One thing to keep in mind is how well supported the tools are for the platforms we have contributors actively developing on. As a data point, I'm on Windows. Last time I tried using TortoiseGit (which admittedly was over a year ago), it was not ready for production use due to crashes with simple operations. On the other hand, TortoiseSVN works very well. While I can certainly make use of the command line, I don't predominately live in one like others might on non-Windows systems. So yes, it may be an imposition to require the use of git. I've not used the git integration in MSVC, so I can't speak to how well that may work with a project as complex as ours (perhaps someone else has experience and can speak to it), but that may also be a viable alternative for those of us on Windows that are already using MSVC. Other GUI alternatives may also exist that I'm simply unaware of. > And knowing how to use git at at least a basic level is an important skill > for a > lot of software development now -- no matter what LLVM does, so I don't feel > bad for making anyone spend time learning how to use it. > > I really don't think that promising and requiring that svn-client using > people (especially committers: read-only access seems a lot less potentially > problematic) will keep getting a good development experience after the > migration is a good idea. I mean, if SVN also happens to work with the > chosen hosting/workflow in the end, that's fine, I guess. But, I feel that > should be considered a "if it works, that's okay, but it's not recommended, > and is not guaranteed" kind of thing. I'm uncomfortable with the idea of jettisoning SVN entirely right out of the gate. ~Aaron > Making that a requirement locks us into the use of github as the primary > repository: no other git hosting has svn support, afaik. > It means we can't introduce any workflows that wouldn't work well for svn > users -- or if we do, that such users will probably complain anew when that > happens. > And if github's svn bridge turns out to have fatal problems, do we then > abandon the migration? > > > > On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev > wrote: >> >> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev >> wrote: >> > On 1 June 2016 at 17:02, John Criswell wrote: >> >> Do you have a set of volunteers lined up to do such a migration? >> >> Getting >> >> people willing to do the migration will obviously be key, and that was >> >> the >> >> one thing I didn't see in the original email. >> > >> > Hi John, >> > >> > Well, first we need to know if people are in favour, then if the >> > migration won't bring any serious problem, and then we can think of a >> > migration plan. :) >> > >> > So far, it seems people are mostly in favour, with a few that reported >> > being locked into SVN. I had anticipated that, and have proposed >> > GitHub's SVN integration, which allows read-write access, so it should >> > be mostly ok. We need more tests on that side to be sure, though. >> > >> > The biggest problem we're facing right now is how to sync the repos. >> > The existing llvm-repos format with all projects as sub-modules seem >> > to be a good candidate, but I still haven't seen a consensus on how >> > we'd do that. >> > >> > About the migration plan, most people seem to agree a step-by-step >> > process is necessary. So, first we move to git-only, possibly with >> > sub-modules, >> >> Despite people's reservations of a git-only repository? I mean, we >> still don't know that this will even work for people who wish to stay >> with SVN. I am really not comfortable with this decision based on "it >> should be mostly ok" from above, but maybe I am misunderstanding >> something. >> >> ~Aaron >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)
On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote: > I think we should start two other threads: one about git tooling on Windows > and one about infrastructure problems migrating to git. Some developers on Windows prefer to use GUI tools like TortoiseSVN to command line tools for version control. The last time I tried TortoiseGit on Windows (which was over a year ago), it did not feel ready for production use on a complex project to me (I had crashes on simple operations, and it seems I was not alone in seeing flaky behavior: https://gitlab.com/tortoisegit/tortoisegit/issues/1738 and https://gitlab.com/tortoisegit/tortoisegit/issues/2494 as examples). Are there suitable GUI tools for git on Windows for projects as complex as LLVM? I believe MSVC has some integration, but I've not used it before. Perhaps other tools exist that match the integration and stability that TortoiseSVN has with Explorer? I bring this up as a possible minor concern because asking people to switch from one set of command line commands to another set of command line commands is a different beast than asking people to switch from Explorer-integrated menus and dialogs to the command line (that's a drastically different workflow to achieve the same end result of source code version control). ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Thank you for raising this question! I think 3.10 makes sense until we have a strong enough breaking change (in anything, not just LLVM bit code) to warrant bumping to 4.0. ~Aaron On Mon, Jun 13, 2016 at 7:54 PM, Hans Wennborg via cfe-dev wrote: > Breaking this out into a separate thread since it's kind of a separate > issue, and to make sure people see it. > > If you have opinions on this, please chime in. I'd like to collect as > many arguments here as possible to make a good decision. The main > contestants are 4.0 and 3.10, and I've seen folks being equally > surprised by both. > > Brain-dump so far: > > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0 > comes after 3.9. > > - There are special bitcode stability rules [1] concerning major > version bumps. 2.0 and 3.0 had major IR changes, but since there > aren't any this time, we should go to 3.10. > > - The bitcode stability rules allow for breakage with major versions, > but it doesn't require it, so 4.0 is fine. > > - But maybe we want to save 4.0 for when we do have a significant IR change? > > - We've never had an x.10 version before; maybe that would be > confusing? Perhaps it's simply time to move on (like Linux 2.6.39 -> > 3.0 and 3.19 -> 4.0). > > - Since we do time-based rather than feature-based releases, the major > version number shouldn't mean anything special anyway (e.g. big IR > changes or not), so 4.0? > > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is > a tuple after all. > > - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases in > between would correspond to minor version bumps, which would make > sense (and catch up with GCC!). > > - It's just a number, no big deal; flip a coin or something. > > What do you think? > > - Hans > > > [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
Thank you for your continuing efforts on the Code of Conduct! I appreciate the efforts and strongly support this direction. ~Aaron On Thu, Jun 30, 2016 at 2:55 PM, Chandler Carruth via cfe-dev wrote: > Hello folks, > > As mentioned some time ago[1], we’ve had a long (looong) series of > discussions about establishing a code-of-conduct for the LLVM project as a > whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 > code review. > > The discussion has largely died down for some time, and towards the end > there has been pretty wide support for the draft wording we have now. It > isn’t perfect, and there are still some important questions around forming > the advisory committee to handle reporting, but I think the wording is at a > good point of compromise in a challenging area. > > Based on the support, I’m going to land the patch that adds the draft. I’m > hoping this will immediately provide good advice and guidance, and I’m > hoping to see motion on setting up a reasonable advisory committee and > resolving any issues around reporting so we can make this an official part > of the community. > > I sending this as a heads up so folks are aware, not to start a new > discussion thread. There are existing discussion threads[2] on llvm-dev if > folks want to join in active discussion or we can start fresh ones, but I > would encourage people to carefully read the discussion that has already > taken place to avoid revisiting areas that have already been heavily > discussed. > > Also, many thanks to the folks who provided all their opinions on the > mailing list threads and in person in long discussions about this topic. > > Thanks, > -Chandler > > [1]: Prior announcements: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html > http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html > http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html > > [2]: Existing threads: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via cfe-dev
wrote:
>
> This has been on my mind for quite some time, but recently it's been popping
> up more and more seeing some of the issues people have run into.
>
> Before people get the wrong idea, let me make one thing clear. **I am not
> proposing we stop supporting the CMake Visual Studio generator. I am only
> proposing we stop supporting actually compiling with the generated project**.
> Yes the distinction is important, and I'll elaborate more on why later.
> First though, here are some of the issues with the VS generator:
>
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't be
> able to successfully build. We can (and have) updated the documentation to
> indicate this, but it's not intuitive and still bites people because for some
> reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail
> sometimes. See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It seems
> the parallel build scheduler does not do a good job and can bring a machine
> down. This is not the first time though, every couple of months there's a
> thread about how building or running tests from within VS doesn't work.
> 4) Supporting it is a continuous source of errors and mistakes when writing
> tests. The VS generator outputs a project which can build Debug / Release
> with a single project. This means that `CMAKE_BUILD_TYPE=Debug` is a no-op
> on this generator. The reason this matters for the test suite is because
> `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the location of
> the binaries. You need `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}`
> instead.
>
> There is a continuous source of problems in our CMake [1, 2, 3, 4, 5]. It
> also affects tests, and every time someone adds a new lit site configuration,
> they have to remember to add this magic block of code:
>
> # Support substitution of the tools_dir with user parameters. This is
> # used when we can't determine the tool dir at configuration time.
> try:
> config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
> config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
> except KeyError:
> e = sys.exc_info()[1]
> key, = e.args
> lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" %
> (key,key))
>
> to the file (even though only about 2 people actually understand what this
> does), which has caused problems several times.
>
> 5) VSCode and Visual Studio both support opening CMake projects directly now,
> which bypasses MSBuild. I don't know how well Visual Studio supports LLVM's
> CMake, but the last time I tried it with VSCode on Linux it worked fine.
>
>
>
> I mentioned earlier that the distinction between not *building* with a
> VS-generated project and not supporting the VS generator is important.
>
> I don't want to speak for everyone, but I believe that *most* people use the
> VS generator because they want IDE support for their projects. They want to
> be able to browse code, hit F5 to debug, F9 to set breakpoints, etc. They
> don't necessarily care that Ctrl+Shift+B is how the code is generated versus
> some other incantation. I'm asserting that it's possible to still have all
> the things people actually want from the VS generator without actually
> building from inside of VS. In fact, I've been doing this for several years.
> The workflow is:
>
> 1) Run CMake twice, generating to separate output directories. Once using -G
> "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
>
> 2) Open the VS one. You have full IDE support.
>
> 3) Instead of hitting Ctrl+Shift+B to build, have a command prompt window
> open and type ninja. Wait for it to complete. If you want to you can make a
> custom tool command in Visual Studio so that you can access this from a
> keyboard shortcut.
>
> 4) When you want to debug, set your startup project (as you normally would),
> right click and hit properties, go to Debugging, change Command from
> $(TargetPath) to to debug>.
>
> 5) Hit F5.
>
> In short, with only 2 simple additional steps (run CMake an extra time, and
> type a path into a window), people can have the exact workflow they are used
> to, plus faster builds, minus all of the problems and complexities associated
> with building from within VS.
>
> And we can simplify our CMake logic and lit configuration files as well.
As someone who almost exclusively uses MSVC and not Ninja on Windows,
I'll have to try this workflow out to see how it works for me in
practice. Unfortunately, I won't really be able to test it for a few
weeks.
However, I'm concerned by the idea that we want to drop support for
building with the standard workflow in a toolchain that's as popular
as MSVC is. "Here's a simp
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
wrote:
>
> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > We held a round-table at the llvm dev conference about what other pieces of
> > Github infrastructure we may want to use. This thread in particular is
> > about switching to github issue tracking. Use of other parts of Github
> > functionality was also discussed -- but that should be for other email
> > threads.
> >
> > Most of the ideas here were from other people. I /believe/ this proposal
> > represents the overall feeling of the folks at the round-table, in spirit
> > if not in exact details, but nobody else has reviewed this text, so I can't
> > make any specific such claim as to who the "we" represents, other than
> > myself. Just assume all the good ideas here were from others, and all the
> > bad parts I misremembered or invented.
> >
> >
>
> Hi,
>
> I want to restart this discussion. There seemed to be support for this,
> but we got held up trying to decide on the appropriate set of tags to
> use to classify issues.
>
> I propose that we move forward with this proposal and disable creation of
> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
> issues from that date forward.
>
> I think that for choosing the tags to use, we should just take requests
> from the community over the next week and add whatever is asked for. The main
> purpose of adding tags is so we can setup cc lists for bugs, so I think this
> is a good way to ensure that we have tags people care about. We can always
> add more tags later if necessary.
>
> What does everyone think about this?
What did we decide to do with all the existing issues in Bugzilla?
~Aaron
>
> -Tom
>
>
> > Background
> >
> > Our bugzilla installation is...not great. It's been not-great for a long
> > time now.
> >
> > Last year, I argued against switching to github issues. I was somewhat
> > optimistic that it was possible to improve our bugzilla in some incremental
> > ways...but we haven't. Additionally, the upstream bugzilla project was
> > supposed to make a new release of bugzilla ("harmony"), based on
> > bugzilla.mozilla.org 's fork, which is much
> > nicer. I thought we would be able to upgrade to that. But there has been no
> > such release, and not much apparent progress towards such. I can't say with
> > any confidence that there will ever be. I no longer believe it really makes
> > sense to continue using bugzilla.
> >
> > This year, we again discussed switching. This time, nobody really spoke up
> > in opposition. So, this time, instead of debating /whether/ we should
> > switch, we discussed /how/ we should switch. And came up with a plan to
> > switch quickly.
> >
> > GitHub issues may not be perfect, but I see other similarly-large projects
> > using it quite successfully (e.g. rust-lang/rust) -- so I believe it should
> > be good for us, as well. Importantly, Github Issues is significantly less
> > user-hostile than our bugzilla is, for new contributors and downstream
> > developers who just want to tell us about bugs!
> >
> >
> > Proposal
> >
> > We propose to enable Github issues for the llvm-project repository in
> > approximately two weeks from now, and instruct everyone to start filing new
> > issues there, rather than in bugzilla.
> >
> > Some things we'd like to get in place before turning on Github's Issue
> > tracker:
> > 1. Updated documentation.
> > 2. An initial set of issue tags we'd like to use for triaging/categorizing
> > issues.
> > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or
> > maybe not.
> >
> > But more important are the things we do /not/ want to make prerequisites
> > for turning on Github issues:
> >
> > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the
> > existing issues to GitHub as a prerequisite for switching. We will thus
> > expect that people continue using bugzilla for commenting on the existing
> > bugs -- for the moment.
> >
> > We do /not/ want to build supplementary notification systems to make github
> > issues send additional emails that it is unable to send itself. We will
> > only support what GitHub supports. That means:
> > - You can subscribe to notification emails for activity in the entire
> > llvm-project repository.
> > - You can subscribe to notification emails on an individual issue.
> > - Someone else can CC you on an individual issue to get your attention, and
> > you will get notifications from that (unless you opt-out).
> > - No emails will be sent to llvm-b...@llvm.org
> > for github issues.
> > - There is no builtin way for users to subscribe to emails for bugs that
> > have a given label (for example, all "clang" issues, or all x86 issues).
> >
> > Further steps
> >
> > After we migrate, there's still things we want to do:
> >
> > 1. Discuss and setup new an
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
My concern about switching is that I will now need to use two issue
trackers instead of one when doing things like searching for related bugs.
~Aaron
On Thu, Jan 30, 2020, 1:31 PM Tom Stellard wrote:
> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> > wrote:
> >>
> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >>> We held a round-table at the llvm dev conference about what other
> pieces of Github infrastructure we may want to use. This thread in
> particular is about switching to github issue tracking. Use of other parts
> of Github functionality was also discussed -- but that should be for other
> email threads.
> >>>
> >>> Most of the ideas here were from other people. I /believe/ this
> proposal represents the overall feeling of the folks at the round-table, in
> spirit if not in exact details, but nobody else has reviewed this text, so
> I can't make any specific such claim as to who the "we" represents, other
> than myself. Just assume all the good ideas here were from others, and all
> the bad parts I misremembered or invented.
> >>>
> >>>
> >>
> >> Hi,
> >>
> >> I want to restart this discussion. There seemed to be support for this,
> >> but we got held up trying to decide on the appropriate set of tags to
> >> use to classify issues.
> >>
> >> I propose that we move forward with this proposal and disable creation
> of
> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed via
> GitHub
> >> issues from that date forward.
> >>
> >> I think that for choosing the tags to use, we should just take requests
> >> from the community over the next week and add whatever is asked for.
> The main
> >> purpose of adding tags is so we can setup cc lists for bugs, so I think
> this
> >> is a good way to ensure that we have tags people care about. We can
> always
> >> add more tags later if necessary.
> >>
> >> What does everyone think about this?
> >
> > What did we decide to do with all the existing issues in Bugzilla?
> >
>
> This is undecided. The first step of this proposal only affects new
> issues.
> Existing issues will remain in bugzilla and will be updated there too. At
> some point in the future bugzilla will become read-only and/or the issues
> will
> be migrated somewhere else, but no decision has been made about how to do
> that yet.
>
> -Tom
>
> > ~Aaron
> >
> >>
> >> -Tom
> >>
> >>
> >>> Background
> >>>
> >>> Our bugzilla installation is...not great. It's been not-great for a
> long time now.
> >>>
> >>> Last year, I argued against switching to github issues. I was somewhat
> optimistic that it was possible to improve our bugzilla in some incremental
> ways...but we haven't. Additionally, the upstream bugzilla project was
> supposed to make a new release of bugzilla ("harmony"), based on
> bugzilla.mozilla.org 's fork, which is much
> nicer. I thought we would be able to upgrade to that. But there has been no
> such release, and not much apparent progress towards such. I can't say with
> any confidence that there will ever be. I no longer believe it really makes
> sense to continue using bugzilla.
> >>>
> >>> This year, we again discussed switching. This time, nobody really
> spoke up in opposition. So, this time, instead of debating /whether/ we
> should switch, we discussed /how/ we should switch. And came up with a plan
> to switch quickly.
> >>>
> >>> GitHub issues may not be perfect, but I see other similarly-large
> projects using it quite successfully (e.g. rust-lang/rust) -- so I believe
> it should be good for us, as well. Importantly, Github Issues is
> significantly less user-hostile than our bugzilla is, for new contributors
> and downstream developers who just want to tell us about bugs!
> >>>
> >>>
> >>> Proposal
> >>>
> >>> We propose to enable Github issues for the llvm-project repository in
> approximately two weeks from now, and instruct everyone to start filing new
> issues there, rather than in bugzilla.
> >>>
> >>> Some things we'd like to get in place before turning on Github's Issue
> tracker:
> >>> 1. Updated documentation.
> >>> 2. An initial set of issue tags we'd like to use for
> triaging/categorizing issues.
> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates.
> Or maybe not.
> >>>
> >>> But more important are the things we do /not/ want to make
> prerequisites for turning on Github issues:
> >>>
> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to
> migrate the existing issues to GitHub as a prerequisite for switching. We
> will thus expect that people continue using bugzilla for commenting on the
> existing bugs -- for the moment.
> >>>
> >>> We do /not/ want to build supplementary notification systems to make
> github issues send additional emails that it is unable to send itself. We
> will only support what GitHub supports. That means:
> >>> - You can subscribe to notification emails
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
wrote:
>
> On 02/10/2020 07:40 PM, Tom Stellard wrote:
> > On 01/30/2020 12:47 PM, David Major wrote:
> >> Would it make sense to wait until 10.0.0 is released, in order to keep all
> >> the blockers in one place?
> >>
> >
> > Yes, I think this makes sense, let's postpone until then.
> >
>
> Hi,
>
> 10.0.0-rc4 was just released, and I think we are at the point in the release
> cycle
> where it is safe to begin the migration to GitHub issues.
>
> I would like to propose doing the migration in one week (March 23). This
> means
> making the existing bugzilla read-only, and updating the documentation to
> tell users
> to file issues at GitHub. We are still trying to figure out the best way to
> import bugs
> from bugzilla into GitHub, so this step will be done at a later date.
>
> For the initial list of tags, I propose we generate the list based on the
> most commonly
> used categories in bugzilla. This should be enough to get us started and we
> can always
> add more tags as we go.
>
> I've also implemented a notification system using GitHub actions that will
> make
> it possible to subscribe to individual issue tags, so we would enable this on
> Monday
> as well.
>
> What does everyone think?
I am uncomfortable switching to GitHub issues unless the initial
result is that we have ONE set of bugs to track (I do not want to have
to search and maintain separate bug lists). Moving bugs from Bugzilla
at an unspecified future time is a deal-breaker for me, so -1.
~Aaron
>
> Thanks,
> Tom
>
>
> > -Tom
> >
> >>
> >>
> >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev
> >> mailto:llvm-...@lists.llvm.org>> wrote:
> >>
> >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> >> > mailto:cfe-...@lists.llvm.org>> wrote:
> >> >>
> >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >> >>> We held a round-table at the llvm dev conference about what other
> >> pieces of Github infrastructure we may want to use. This thread in
> >> particular is about switching to github issue tracking. Use of other parts
> >> of Github functionality was also discussed -- but that should be for other
> >> email threads.
> >> >>>
> >> >>> Most of the ideas here were from other people. I /believe/ this
> >> proposal represents the overall feeling of the folks at the round-table,
> >> in spirit if not in exact details, but nobody else has reviewed this text,
> >> so I can't make any specific such claim as to who the "we" represents,
> >> other than myself. Just assume all the good ideas here were from others,
> >> and all the bad parts I misremembered or invented.
> >> >>>
> >> >>>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I want to restart this discussion. There seemed to be support for
> >> this,
> >> >> but we got held up trying to decide on the appropriate set of tags
> >> to
> >> >> use to classify issues.
> >> >>
> >> >> I propose that we move forward with this proposal and disable
> >> creation of
> >> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed
> >> via GitHub
> >> >> issues from that date forward.
> >> >>
> >> >> I think that for choosing the tags to use, we should just take
> >> requests
> >> >> from the community over the next week and add whatever is asked
> >> for. The main
> >> >> purpose of adding tags is so we can setup cc lists for bugs, so I
> >> think this
> >> >> is a good way to ensure that we have tags people care about. We
> >> can always
> >> >> add more tags later if necessary.
> >> >>
> >> >> What does everyone think about this?
> >> >
> >> > What did we decide to do with all the existing issues in Bugzilla?
> >> >
> >>
> >> This is undecided. The first step of this proposal only affects new
> >> issues.
> >> Existing issues will remain in bugzilla and will be updated there too.
> >> At
> >> some point in the future bugzilla will become read-only and/or the
> >> issues will
> >> be migrated somewhere else, but no decision has been made about how to
> >> do that yet.
> >>
> >> -Tom
> >>
> >> > ~Aaron
> >> >
> >> >>
> >> >> -Tom
> >> >>
> >> >>
> >> >>> Background
> >> >>>
> >> >>> Our bugzilla installation is...not great. It's been not-great for
> >> a long time now.
> >> >>>
> >> >>> Last year, I argued against switching to github issues. I was
> >> somewhat optimistic that it was possible to improve our bugzilla in some
> >> incremental ways...but we haven't. Additionally, the upstream bugzilla
> >> project was supposed to make a new release of bugzilla ("harmony"), based
> >> on bugzilla.mozilla.org
> >> 's fork, which is much nicer. I thought we
> >> would be
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] [cfe-dev] Release Manager Transition
On Wed, Oct 21, 2020 at 8:13 AM Hans Wennborg via cfe-dev wrote: > > After almost six years and twelve major releases (3.6 through 11), I > have decided to step down as release manager. Thank you so much for all your hard work as release manager and congratulations on so many successful releases! > While I have enjoyed the process a lot, especially working with so > many people in the community, it has taken a lot of time which I now > want to use for other work. > > Tom Stellard, who already does the stable (a.k.a. "dot") releases, > says he'd be willing to manage also the major releases, so I hereby > nominate him to take over. +1 to Tom taking over, thank you for volunteering! ~Aaron > > Thanks, > Hans > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-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] [RFC] Deprecate email code reviews in favor of Phabricator
On Mon, May 3, 2021 at 1:24 PM Krzysztof Parzyszek via cfe-dev wrote: > > Statement: > > Our current code review policy states[1]: > > “Code reviews are conducted, in order of preference, on our web-based > code-review tool (see Code Reviews with Phabricator), by email on the > relevant project’s commit mailing list, on the project’s development list, or > on the bug tracker.” > > This proposal is to limit code reviews only to Phabricator. This would apply > to all projects in the LLVM monorepo. With the change in effect, the amended > policy would read: > > “Code reviews are conducted on our web-based code-review tool (see Code > Reviews with Phabricator).” Personally, I am in favor of this policy for initiating code reviews, but am opposed to it for post-commit feedback. The problem, as I see it, is that not every change *gets* code review via Phab and the email lists are the only place on which to provide that post-commit feedback. This largely comes up in two ways: NFC changes and changes made by code owners in the area of the compiler which they own. We still need *some* mechanism by which to provide them post-commit feedback. Currently, the way we provide that is frequently via an email reply to the commit message on the *-commits list so that the issue can be seen by both the patch author and the community at large. > Current situation: > > In a recent llvm-dev thread[2], Christian Kühnel pointed out that pre-commit > code reviews rarely originate via an email (most are started on Phabricator), > although, as others pointed out, email responses to an ongoing review are not > uncommon. (That thread also contains examples of mishaps related to the > email-Phabricator interactions, or email handling itself.) > I don’t have specific information about post-commit reviews. It seems like > the most common form is an email reply to the auto-generated commit message, > although (in my personal experience), “raising a concern” in the commit on > Phabricator or commenting in the pre-commit review is usually sufficient to > get author’s attention. > We have Phabricator patches that automatically apply email comments to the > Phabricator reviews, although reportedly this functionality is not fully > reliable[3,4]. This can cause review comments to be lost in the email > traffic. > > > > Benefits: > > Single way of doing code reviews: code reviews are a key part of the > development process, and having one way of performing them would make the > process clearer and unambiguous. > Review authors and reviewers would only need to monitor one source of > comments without the fear that a review comment may end up overlooked. > Local Phabricator extensions would no longer be needed. > > > > Concerns: > > For post-commit reviews, the commenter would need to find either the original > review, or the Phabricator commit (e.g. > https://reviews.llvm.org/rG06234f758e19). Those are communicated (perhaps > ironically) via email, which implies that those automatic emails should > remain in place. The Phab commit message does not have any subscribers though, and so my understanding is that comments on that Phab interface are not communicated out to the community as a whole, which means the community may miss out on important post-commit-review information like general awareness of the problem, workarounds people can use until the author corrects something, alternative ideas on how to fix the issue, etc. Or do I misunderstand the way Phab works in this workflow? Also, "the commenter would need to find the Phabricator commit" concerns me -- adding extra burden on the people providing feedback means that *some* amount of those people will struggle enough to simply not provide that feedback. Responding to an email is about as low as I think we can set that bar, so the current approach has better ergonomics for giving feedback. When I look at an existing NFC commit email (https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20210503/368413.html), I don't see any direct link back to the Phabricator commit, so I have to know to get the hash and try using that with an https://reviews.llvm.org/rG in front of it. None of the existing links in the email get me to where I'd need to go to add my review feedback, but hitting the Reply button in my mail client will work. Adding a third link and telling people "click on the link in the email" means they've got a 50/50 shot of getting the right link because one of the links goes to GitHub where you can also add comments. > The current policy has been in place for a long time and it’s expected that > some people will continue using email for reviews out of habit or due to lack > of awareness of the policy change. > Because of the larger variety, email clients may offer better accessibility > options than web browsers. > > > > Potential future direction: > > This section presents a potential future evolution of the review process. > Christian has condu
Re: [lldb-dev] [cfe-dev] [RFC] Deprecate email code reviews in favor of Phabricator
On Tue, May 4, 2021 at 9:56 AM wrote: > > > You're right that doing post-commit reviews on Phabricator is not > > seamless---the rG link is not included anywhere. Hopefully that could be > > fixed with some Phabricator configuration tweaks, like sending the commit > > email to the -commits list. > > The commit email has a URL: link, e.g. this recent one (which has no > Dn review): > > URL: > https://github.com/llvm/llvm-project/commit/b04148f77713c92ee57b33b7b858ad18ce8d78e3 > > Does that take you to a different place than the rG link would? > Seems like they ought to go to the same place. That sends you to the GitHub commit for the change. The corresponding rG link would be: https://reviews.llvm.org/rGb04148f77713c92ee57b33b7b858ad18ce8d78e3 ~Aaron ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [RFC] Deprecate email code reviews in favor of Phabricator
On Tue, May 4, 2021 at 8:35 PM Mehdi AMINI wrote: > > > > On Tue, May 4, 2021 at 4:24 AM Aaron Ballman via cfe-dev > wrote: >> >> On Mon, May 3, 2021 at 1:24 PM Krzysztof Parzyszek via cfe-dev >> wrote: >> > >> > Statement: >> > >> > Our current code review policy states[1]: >> > >> > “Code reviews are conducted, in order of preference, on our web-based >> > code-review tool (see Code Reviews with Phabricator), by email on the >> > relevant project’s commit mailing list, on the project’s development list, >> > or on the bug tracker.” >> > >> > This proposal is to limit code reviews only to Phabricator. This would >> > apply to all projects in the LLVM monorepo. With the change in effect, >> > the amended policy would read: >> > >> > “Code reviews are conducted on our web-based code-review tool (see Code >> > Reviews with Phabricator).” >> >> Personally, I am in favor of this policy for initiating code reviews, >> but am opposed to it for post-commit feedback. The problem, as I see >> it, is that not every change *gets* code review via Phab and the email >> lists are the only place on which to provide that post-commit >> feedback. This largely comes up in two ways: NFC changes and changes >> made by code owners in the area of the compiler which they own. We >> still need *some* mechanism by which to provide them post-commit >> feedback. Currently, the way we provide that is frequently via an >> email reply to the commit message on the *-commits list so that the >> issue can be seen by both the patch author and the community at large. >> >> > Current situation: >> > >> > In a recent llvm-dev thread[2], Christian Kühnel pointed out that >> > pre-commit code reviews rarely originate via an email (most are started on >> > Phabricator), although, as others pointed out, email responses to an >> > ongoing review are not uncommon. (That thread also contains examples of >> > mishaps related to the email-Phabricator interactions, or email handling >> > itself.) >> > I don’t have specific information about post-commit reviews. It seems >> > like the most common form is an email reply to the auto-generated commit >> > message, although (in my personal experience), “raising a concern” in the >> > commit on Phabricator or commenting in the pre-commit review is usually >> > sufficient to get author’s attention. >> > We have Phabricator patches that automatically apply email comments to the >> > Phabricator reviews, although reportedly this functionality is not fully >> > reliable[3,4]. This can cause review comments to be lost in the email >> > traffic. >> > >> > >> > >> > Benefits: >> > >> > Single way of doing code reviews: code reviews are a key part of the >> > development process, and having one way of performing them would make the >> > process clearer and unambiguous. >> > Review authors and reviewers would only need to monitor one source of >> > comments without the fear that a review comment may end up overlooked. >> > Local Phabricator extensions would no longer be needed. >> > >> > >> > >> > Concerns: >> > >> > For post-commit reviews, the commenter would need to find either the >> > original review, or the Phabricator commit (e.g. >> > https://reviews.llvm.org/rG06234f758e19). Those are communicated (perhaps >> > ironically) via email, which implies that those automatic emails should >> > remain in place. >> >> The Phab commit message does not have any subscribers though, and so >> my understanding is that comments on that Phab interface are not >> communicated out to the community as a whole, which means the >> community may miss out on important post-commit-review information >> like general awareness of the problem, workarounds people can use >> until the author corrects something, alternative ideas on how to fix >> the issue, etc. Or do I misunderstand the way Phab works in this >> workflow? >> >> Also, "the commenter would need to find the Phabricator commit" >> concerns me -- adding extra burden on the people providing feedback >> means that *some* amount of those people will struggle enough to >> simply not provide that feedback. Responding to an email is about as >> low as I think we can set that bar, so the current approach has better >> ergonomics for giving feedback. When I look at an existing NFC commit >> email >> (https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20210503/368413.html), >> I don't see any direct link back to the Phabricator commit, so I have >> to know to get the hash and try using that with an >> https://reviews.llvm.org/rG in front of it. > > > This is a simple problem to solve by fixing the format of the emails that are > sent, I believe we have control over this right now. We could: > > - add the https://reviews.llvm.org/rG to every email, and not to GitHub. > - make sure that the lists are subscribed on the commits on Phab so that > notifications are generated to the list on post-commit feedback. > >> >> None of the existing links
Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update
On Thu, Jun 3, 2021 at 6:20 PM 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. +1 to this. I've tried discourse in the past and not found it to be a palatable replacement for mailing lists. Some of that is certainly inertia (I've been using mailing lists for a *long time*) that I could work to overcome, but my preference is to continue with mailing lists. ~Aaron > > > On Tue, Jun 1, 2021 at 4:50 PM Tom Stellard via cfe-dev > wrote: >> >> Hi, >> >> We recently[1] ran into some issues with the mailing lists that caused >> us to disable automatic approval of subscriptions. Over the past few >> months, the LLVM Foundation Board of Directors have been investigating >> solutions to this issue and are recommending that the project move its >> discussion forum from mailman to Discourse[2]. >> >> The proposed migration plan is to move the discussion lists (e.g *-dev, >> *-users lists) to Discourse as soon as possible. The commit email lists >> (*-commits lists) will remain on mailman until a not-yet-determined date >> in the future, after which they will be replaced by something else. >> Some commit lists alternatives include Discourse and GitHub commit >> comments (but there may be others). >> >> Here are the reasons why the LLVM Foundation Board of Directors is >> recommending this change: >> >> - The LLVM project discussion lists cannot be adequately maintained by our >>current volunteer infrastructure staff and without changes we run the >>risk of a major outage. >> >> - We are able to make this change without significant impact to user's or >>developer's daily workflows because Discourse supports email subscriptions >>and posting (NOTE: if you are concerned that your workflow may be impacted >>by this change, please contact the Infrastructure Working Group[3], so >>they can help test your workflow with Discourse.) >> >> - Discourse gives us additional features that will benefit the community: >>- Easy to signup and subscribe to categories >>- Better moderation tools. >>- Web-based user interface. >>- Ability to send announcements to multiple categories to avoid having to >> cross-post community wide announcements. >> >> - A subset of the community (MLIR) have been experimenting with Discourse >>for over a year and are able to provide feedback about this experience >>to the Board of Directors. >> >> We did also consider one alternative, which was migrating our lists to a >> mailman hosting service. However, we concluded that with all the work it >> would take to migrate our lists to another service, it would be better >> if we moved to a service (like Discourse) that provided more features >> than what we have now. >> >> We understand that moving to Discourse is a change for the community and >> that people may be worried about this having a negative impact on their >> participation in the project. As mentioned above, we believe that this >> change can be done without significant impact to anyone’s workflows. >> If you disagree, please contact the Infrastructure Working Group, to >> document the impact to your workflow, so we can work together to find >> a solution for your issue. >> >> If you have any other questions or comments you can raise them on this >> thread and please keep criticisms constructive and on topic. >> >> >> LLVM Foundation Board of Directors >> >> [1] https://lists.llvm.org/pipermail/llvm-dev/2021-March/149027.html >> [2] https://www.discourse.org/ >> [3] https://github.com/llvm/llvm-iwg >> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > ___ > LLVM Developers mailin
Re: [lldb-dev] [cfe-dev] Mailing List Status Update
On Mon, Jun 14, 2021 at 5:41 PM James Y Knight via cfe-dev
wrote:
>
> On Thu, Jun 3, 2021 at 6:19 PM James Y Knight 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.
>
>
> FWIW, it would seem that one secret trick here is to NOT check "mailing list
> mode" -- that option is mostly there to confuse you, I guess.
>
>> 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.
>
>
> On that last point, I've gone ahead and asked the folks at osci.io ("Open
> Source Community Infrastructure") if they'd be willing to host our mailing
> lists. They are a group at RedHat whose mission is to support infrastructure
> for open-source community projects, and they host mailman3 lists for a number
> of other open-source groups, already (https://www.osci.io/tenants/). So, I
> believe they have the necessary experience and expertise.
>
> They have said they indeed are willing and have the capacity to run this for
> us as a service, if we'd like. We'd still need to be responsible for things
> like list moderation, but they'd run the mailman installation on their
> infrastructure. In my opinion, we ought to take this option, rather than
> trying to push a migration to discourse.
>
> To me, it seems this would be a much clearer upgrade path, and would solve
> the hosting/volunteer-admin issue -- including for commit lists -- giving the
> current maintainers quicker relief from the undesired task of running the
> list service. Additionally, since it would be a migration to Mailman3, we
> would get many of the additional features mentioned as desirable, e.g.
> searchable archives and posting from the website.
Thank you for checking into a mailman3 hosting option, I think this
approach would make me feel the most comfortable (far more comfortable
than switching to Discord).
~Aaron
>
>> On Tue, Jun 1, 2021 at 4:50 PM Tom Stellard via cfe-dev
>> wrote:
>>>
>>> Hi,
>>>
>>> We recently[1] ran into some issues with the mailing lists that caused
>>> us to disable automatic approval of subscriptions. Over the past few
>>> months, the LLVM Foundation Board of Directors have been investigating
>>> solutions to this issue and are recommending that the project move its
>>> discussion forum from mailman to Discourse[2].
>>>
>>> The proposed migration plan is to move the discussion lists (e.g *-dev,
>>> *-users lists) to Discourse as soon as possible. The commit email lists
>>> (*-commits lists) will remain on mailman until a not-yet-determined date
>>> in the future, after which they will be replaced by something else.
>>> Some commit lists alternatives include Discourse and GitHub commit
>>> comments (but there may be others).
>>>
>>> Here are the reasons why the LLVM Foundation Board of Directors is
>>> recommending this change:
>>>
>>> - The LLVM project discussion lists cannot be adequately maintained by our
>>>current volunteer infrastructure staff and without changes we run the
>>>risk of a major outage.
>>>
>>> - We are able to make this change without significant impact to user's or
>>>developer's daily workflows because Discourse supports email
>>> subscriptions
>>>and posting (NOTE: if you are concerned that your workflow may be
>>> impacted
>>>by this change, please contact the Infrastructure Working Group[3], so
>>>they can help test your workflow with Discourse.)
>>>
>>> - Discourse gives us additional features that will benefit the community:
>>>- Easy to signup and subscribe to categories
>>>- Better moderation tools.
>>>- Web-based user interface.
>>>- Ability to send announcements to multiple categories to avoid having to
>>> cross-post community wide announcements.
>>>
>>> - A subset of the community (MLIR) have been experimenting with Discourse
>>>for over a year and are able to provide feedback about this
Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update
On Wed, Jun 23, 2021 at 12:51 AM Chris Lattner via cfe-dev wrote: > > On Jun 22, 2021, at 6:01 PM, James Y Knight wrote: > > On Mon, Jun 21, 2021 at 3:53 PM Chris Lattner via cfe-dev > wrote: >> >> On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev >> wrote: >> >> Specific to the dev lists, I'm very hesitant about moving from mailing lists >> to discourse. Why? >> >> Well, the first and most basic is I'm worried about having core >> infrastructure out of our own control. For all their problems, mailing >> lists are widely supported, there are many vendors/contractors available. >> For discourse, as far as I can tell, there's one vendor. It's very much a >> take it or leave it situation. The ability to preserve discussion archives >> through a transition away from discourse someday concerns me. I regularly >> and routinely need to dig back through llvm-dev threads which are years old. >> I've also recently had some severely negative customer experiences with >> other tools (most recently discord), and the thought of having my >> employability and ability to contribute to open source tied to my ability to >> get a response from customer service teams at some third party vendor I have >> no leverage with, bluntly, scares me. >> >> Second, I feel that we've overstated the difficulty of maintaining mailing >> lists. I have to acknowledge that I have little first hand experience >> administering mailman, so maybe I'm way off here. >> >> Hi Philip, >> >> First, despite the similar names, Discord is very different than Discourse. >> Here I’m only commenting about Discourse, I have no opinion about Discord. >> >> >> In this case, I think we need to highly weight the opinions of the people >> actively mainlining the existing systems. It has become clear that the >> priority isn’t “control our own lists”, it is “make sure they stay up” and >> “get LLVM people out of maintaining them”. >> >> The ongoing load of maintaining these lists (including moderation) and of >> dealing with the security issues that keep coming up are carried by several >> individuals, not by the entire community. I’m concerned about those >> individuals, but I’m also more broadly concerned about *any* individuals >> being solely responsible for LLVM infra. Effectively every case we’ve had >> where an individual has driving LLVM infra turns out to be a problem. LLVM >> as a project isn’t good at running web scale infra, but we highly depend on >> it. > > > I agree that the maintenance issue is definitely a problem which needs to be > solved. And there is some urgency, given the recent problems which resulted > in a need to manually subscribe people to the lists. > > But, the proposal on the table doesn't appear to actually address this issue, > because the maintainers of llvm mailman will still continue to be responsible > for keeping it functioning, for the mailing lists which were not proposed to > be migrated. On the other hand, having osci.io run a mailman3 service for us > does seem to be a way to solve this -- and doesn't require discarding mailing > lists entirely. > > > I’m not deeply familiar with osci.io, but hosted mailman services all suffer > from a major problem: they don’t solve the moderation problem. Can you explain the moderation problem a bit? As a current mailing list moderator, I'm unaware of unsolved issues in this space and the only mentions about moderation on this thread are vague "we could have better moderation tools" kind of comments without justification as to why they're important enough to necessitate a switch away from email. > More generally, I don’t see how that addresses the many other issues that > were raised repeatedly on this thread. We went through many of these same discussions a while ago about moving away from IRC and email at the same time. There was no community consensus during that discussion, but for various reasons the end result was a fracturing of the community (some people went to Discord, some people stayed on IRC, and now both communities have to tell members "if you don't get an answer here, try on the other service or the mailing lists"). IMO, this left us with a community that's less approachable because new people are never really certain if they're asking their questions "in the right place", especially when a failure to get an answer to their question requires them to try again on a different service. I am worried that a switch from email on the -dev mailing lists to using Discourse will result in a similar fracturing, as discussions will still be possible via email on -commits. To me personally, the possibility of further fracturing the community is a concern I think we need to take very seriously. ~Aaron > > -Chris > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-d
