Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Tom Stellard via lldb-dev]

On Fri, Jun 10, 2016 at 01:38:22PM -0700, Hans Wennborg via llvm-dev wrote:
> Hello everyone,
> 
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
> 
> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.
> 
> 
> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
> 

The 4.1 release gives us the opportunity to drop support for 3.x
bitcode formats, so  I don't think we should move to 4.x until we have
older bitcode features that we really want to drop.  There should
probably be a separate discussion thread about this.

-Tom




> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
> 
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
> 

This is a great idea.

-Tom

> Let me know what you think.
> 
> Cheers,
> Hans
> 
> 
>  [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Tom Stellard via lldb-dev]

On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> > The 4.1 release gives us the opportunity to drop support for 3.x
> > bitcode formats, so  I don't think we should move to 4.x until we have
> > older bitcode features that we really want to drop.  There should
> > probably be a separate discussion thread about this.
> 
> It give the opportunity, not the obligation. Given that I think it is
> an independent issue and would suggest we just keep the revisions
> simple and switch trunk to 4.0.
> 

Hi Rafael,

The main issue I see with automatically moving to 4.0, is that if a year
from now we decide we want to drop a bitcode feature, we can't really do
it unless we bump the major version again to 5.0.  If we continue on
with 3.x, then we still have the flexibility to drop bitcode features
when we decide it's necessary.

-Tom

> Cheers,
> Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Tom Stellard via lldb-dev]

Hi Bernhard,

Can you file a bug for this at www.llvm.org/bugs? Make sure to set
the version to 3.8 and assign it to me.  You should also reference
PR27071 in the bug report.

-Tom

On Mon, Aug 01, 2016 at 09:44:07AM -0700, Hans Wennborg wrote:
> Ouch :-(
> 
> Well, if we ever do a 3.8.2, that should be included. +Tom in case
> he's maintaining a list.
> 
> On Mon, Aug 1, 2016 at 12:18 AM, Michael Kuperstein  wrote:
> > The crash dump looks like it's probably PR27071.
> > The bug was introduced in r261387 (which was merged into 3.8) and fixed in
> > r264465 (which apparently wasn't).
> >
> > On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer
> >  wrote:
> >>
> >> Hi,
> >> On the OpenMandriva side, x86_64 passes all checks. We're having some
> >> problems with other architectures though (see below):
> >>
> >> x86_64 succeeded, packages are here:
> >> https://abf.openmandriva.org/build_lists/76792
> >>
> >> i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
> >> using to build 3.9):
> >>
> >> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> >> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support
> >> -Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security
> >> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> >> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
> >> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
> >> -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W
> >> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> >> -Wmissing-field-initializers -pedantic -Wno-long-long
> >> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> >> -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections
> >> -fdata-sections -Os  -pipe -Wformat -Werror=format-security
> >> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> >> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
> >> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
> >> -D_FILE_OFFSET_BITS=64 -MD -MT
> >> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF
> >> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
> >> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
> >> ../lib/Support/PrettyStackTrace.cpp
> >> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
> >> llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
> >> MachineOperand accessor"' failed.
> >> #0 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> >> (/usr/lib/libLLVMSupport.so.3.8+0x95075)
> >> #1 0xf4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
> >> #2 0xf4abbbf1 llvm::sys::RunSignalHandlers()
> >> (/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
> >> #3 0xf4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
> >> #4 0xf7714d20  0xd20 __GI_raise
> >> #5 0xf7714d20
> >> #6 0xf7714d20 __GI_abort (+0xd20)
> >> #7 0xf4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
> >> #8 0xf46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
> >> #9 0xf464b126 (/lib/libc.so.6+0x21126)
> >> #10 0xf464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr
> >> const*) const (/lib/libc.so.6+0x21162)
> >> #11 0xf65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
> >> #12 0xf667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
> >> #13 0xf61029dc
> >> llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
> >> (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
> >> #14 0xf6105002 llvm::FPPassManager::runOnFunction(llvm::Function&)
> >> (/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
> >> #15 0xf60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
> >> (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
> >> #16 0xf50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&)
> >> (/usr/lib/libLLVMCore.so.3.8+0x19de6f)
> >> #17 0xf50d816b llvm::legacy::PassManager::run(llvm::Module&)
> >> (/usr/lib/libLLVMCore.so.3.8+0x19e16b)
> >> #18 0xf50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
> >> clang::CodeGenOptions const&, clang::TargetOptions const&,
> >> clang::LangOptions const&, llvm::StringRef, llvm::Module*,
> >> clang::BackendAction, llvm::raw_pwrite_stream*)
> >> (/usr/lib/libLLVMCore.so.3.8+0x19e57f)
> >> #19 0xf50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
> >> #20 0xf59fc72c clang::ParseAST(clang::Sema&, bool, bool)
> >> (/usr/lib/libclangCodeGen.so.3.8+0x6972c)
> >> #21 0xf5b2cd85 clang::ASTFrontendAction::ExecuteAction()
> >> (/usr/lib/libclangCodeGen.so.3.8+0x199d85)
> >> #22 0xf3b2b294 clang::CodeGenAction::ExecuteAction()
> >> (/usr/lib/libclangParse.so.3.8+0x24294)
> >> #23 0xf582583e clang::FrontendAction::Execute()
> >> (/usr/lib/libclangFrontend.so.3.8+0x8783e)
> >> #24 0xf5b2d3e1
> >> clang::CompilerInstance::E

Re: [lldb-dev] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Tom Stellard via lldb-dev]

On Mon, Dec 05, 2016 at 06:58:01PM +, Renato Golin via cfe-dev wrote:
> On 5 December 2016 at 18:42, Dimitry Andric via Release-testers
>  wrote:
> > Maybe I didn't pay enough attention, but where is the general outline
> > for this versioning scheme documented?  And are we still going to do
> > 4.1, 4.2, etc?
> 
> This is the thread:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2016-June/101044.html
> 
> 
> > Note that this is a pretty close follow-up to the 3.9.1 release.  There
> > is a minor risk of "release burn-out" here... :)
> 
> They're completely different trees, so should only be a problem if we
> haven't finished by then.
> 
> 3.9.1 convergence took a lot longer than expected because of the
> number of back-ports. With interest in the point-releases growing, I
> think we should try a "half-way" schedule for the point releases, to
> make sure that doesn't happen again.
> 

We are actually pretty close to a halfway schedule for the stable
releases right now.  3.9.0 was released Sep 2, and the 3.9.1
release was scheduled for December 5 (though it's running behind as
usual).

It just seems close together because the major release process has
a longer period of RC releases and stablilization.

-Tom

> cheers,
> --renato
> ___
> 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] Tips for building with LLVM_LINK_LLVM_DYLIB=ON

[Tom Stellard via lldb-dev]

Hi, 

We've been having trouble with some strange lldb failures when building lldb
with -DLLVM_LINK_LLVM_DYLIB=ON.  For example, this command segfaults
with -DLLVM_LINK_LLVM_DYLIB=ON but not if we omit that option:

echo "int main(void) { return 0; }" |  gcc -x c -g - && \
   lldb -b a.out -o 'b main' -o 'r' -o 'expr printf("hello")'


Does anyone have a working LLVM_LINK_LLVM_DYLIB=ON build and if so,
could you share the cmake flags you are using?

These are the flags that I used:

-DBUILD_SHARED_LIBS:BOOL=OFF
-DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_BUILD_LLVM_DYLIB=ON
-DLLVM_LINK_LLVM_DYLIB=ON

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Reminder: Today is the deadline for 5.0.1 Merge Requests

[Tom Stellard via lldb-dev]

Hi,

Today is the official deadline for making 5.0.1 merge requests.  Any merge 
request
made before the end of today is guaranteed to get into the 5.0.1 release if it 
is
approved by the code owner and release manager.

After today, I will still accept merge requests, but they must be approved by
the code owner and release manager prior to the Nov 22 Merge Deadline in order
to get into the release (i.e. we will not delay the release if we are still
waiting for a review).

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [6.0.0 Release] Scheduling the release

[Tom Stellard via lldb-dev]

On 12/06/2017 09:28 AM, Hans Wennborg via cfe-dev wrote:
> Hello everyone,
> 
> It's time to start making plans for the 6.0.0 release.
> 
> Following our regular schedule, the branch would occur about two weeks
> into January, on Wednesday 17 January 2018, with the goal of shipping
> early March. This is the schedule I would propose.
> 
> However, one large consumer of the branch has asked if we could start
> earlier this time, branching on 3 January instead (not moving the ship
> date), to get a longer period for stabilization that syncs with their
> internal process.
> 
> While I'm hesitant to change the schedule because I think it's
> important that it's predictable, there is a benefit of having large
> users "in sync" with the upstream release branch, as that means more
> people testing the same code.
> 
> I will be out of the office the first weeks of January (and I'm
> guessing other members of the community might be too), so while I
> could get the branch started on the 3rd, it would be a kind of
> "slow-start" of the process, but still allow those who want to start
> testing and nominating merges to do so.
> 
> Ultimately, it comes down to what the community prefers. Should we
> stick to the regular schedule, or should we do the "slow-start" two
> weeks early this time?
> 
> Let me know what you think, especially those of you involved in the
> release testing.
> 

I'm fine with an earlier branch date.  If we are worried about changing
the schedule, we could always keep the rc1 date the same and allow
people to finish up features in the release branch during the "slow-start"
period.

-Tom

> Cheers,
> Hans
> ___
> 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] [RFC] LLVM bug lifecycle BoF - triaging

[Tom Stellard via lldb-dev]

On 10/04/2018 02:55 AM, Kristof Beyls via lldb-dev wrote:
> Hi all,
> 
> I’d like to share a few thoughts and analysis results on the LLVM bug life 
> cycle, especially the reporting/triaging part.
> 
> As one of the few people creating llvm bugzilla accounts when people request 
> an account, I started to have a feel that many reported bugs, especially by 
> first-time reporters, never get any reply or feedback, let alone be acted on.
> If people go through the effort of requesting an account, and then reporting 
> the bug, they show motivation to contribute to the project. However, if then 
> they see zero return on their effort spent, even if it’s just a confirmation 
> of the bug indeed being real or an explanation of what they thought to be a 
> bug isn’t actually a bug, I fear as a community we disincentify a large 
> number of potential long-term contributors.
> 
> The above was all based on gut feel, so I tried to gather a bit more data to 
> see if my feel was correct or not.
> I scraped the bugs in bugzilla and post-processed them a bit. Below is a 
> chart showing, year by year, how long it takes for a reported bug to get any 
> comment from anyone besides to original reporter. If the bug is still open 
> and didn’t have any reaction after half a year the chart categorizes is as an 
> “infinite” response time.
> 
>  
> It shows that in recent years the chance of never getting a response to a bug 
> report has been increasing.
> For some bugs - e.g. an experienced LLVM developer records a 
> not-that-important bug in bugzilla - that may be just fine.
> However, I assume that for people reporting a bug for the first time, the 
> majority may look at least for confirmation that what they reported is 
> actually a bug.
> The chart shows (blue bars) that about 50% of first-time bug reporters never 
> get any reply.
> 
> I also plotted which components get the most reported bugs that don’t get any 
> reaction and remain open:
> 
> The percentage at the top of the bars is the percentage of bugs against that 
> component that never get any reaction. The bar height shows the absolute 
> numbers.
> 
> 
> I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev 
> meeting in San Jose (https://llvmdev18.sched.com/event/H2T3, 17th of October, 
> 10.30am), we can discuss what could be done to improve the experience for 
> first-time reporters and also to reduce the number of bug reports that 
> seemingly get ignored completely.
> By sending this email, I hope to trigger discussion before the BoF, both by 
> attendees and non-attendees, so that we have a more fruitful outcome.
> 
> At first sight, to me, it seems that the following actions would help:
> 
>   * Let’s introduce some form of “triaged” state in bugzilla, to represent 
> that a bug report has been accepted as describing a real problem; able to be 
> acted on (e.g. has a suitable reproducer); and not being a duplicate of 
> another bug report. Looking at 
> https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug,
>  maybe the best way to achieve this would be for newly raised bugs to by 
> default go to an “UNCONFIRMED” state instead of “NEW”? Moving the status to 
> “NEW” or “CONFIRMED” would indicate the bug has been triaged.
>   * Would it help to have one or multiple people per component that volunteer 
> to triage new bugs?
>   * With the majority of developers being part of a team working on a product 
> based on LLVM, I would assume that it is in the interest of most that 
> reported bugs at least get evaluated/triaged? What is stopping those 
> developers to find the time to do some triaging? Would a better notification 
> mechanism be useful to notify when new bugs on a specific component come in 
> that you could triage? Maybe per component try to have a few people on the 
> “default CC list”, which seems easy to set up as a bugzilla administrator.

I think adding relevant people to the "default CC list" is a really
good idea.  I tend to get pretty good response rates on bugs
when I add people to the CC list.  Even with old bugs that have
been dormant for a while.

-Tom


>   * Should we get rid of the "new-bugs/new bugs” component if we won’t have 
> people triaging them?
>   * Should we have some description of what a reasonable triage of a bug 
> looks like? If we write such a page, we could also use that page to describe 
> what we think should get recorded when closing bugs.
> 
> 
> Thanks,
> 
> Kristof
> 
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Updates on SVN to GitHub migration

[Tom Stellard via lldb-dev]

TLDR: Official monorepo repository will be published on
Tuesday, Oct 23, 2018.  After this date, you should modify
your workflows to use the monorepo ASAP.  Current workflows
will be supported for at most 1 more year.

Hi,

We had 2 round-tables this week at the Developer Meeting to
discuss the SVN to GitHub migration, and I wanted to update
the rest of the community on what we discussed.

The most important outcome from that meeting is that we
now have a timeline for completing the transition which looks
like this:

Tues Oct 23, 2018:

The latest monorepo prototype[1] will be moved over to the LLVM
organization github project[2] and will begin mirroring the current
SVN repository.  Commits will still be made to the SVN repository
just as they are today.

All community members should begin migrating their workflows that
rely on SVN or the current git mirrors to use the new monorepo.  

For CI jobs or internal mirrors pulling from SVN or
http://llvm.org/git/*.git you should modify them to pull from
the new monorepo and also to deal with the new repository
layout.

For Developers, you should begin using the new monorepo
for your development and using the provided scripts[3]
to commit your code.  These scripts will allow to commit
to SVN from the monorepo without using git-svn






[1] https://github.com/llvm-git-prototype/llvm
[2] https://github.com/llvm/
[3] 
https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Updates on SVN to GitHub migration

[Tom Stellard via lldb-dev]

On 10/19/2018 05:47 PM, Tom Stellard via lldb-dev wrote:
> TLDR: Official monorepo repository will be published on
> Tuesday, Oct 23, 2018.  After this date, you should modify
> your workflows to use the monorepo ASAP.  Current workflows
> will be supported for at most 1 more year.
> 
> Hi,
> 
> We had 2 round-tables this week at the Developer Meeting to
> discuss the SVN to GitHub migration, and I wanted to update
> the rest of the community on what we discussed.
> 
> The most important outcome from that meeting is that we
> now have a timeline for completing the transition which looks
> like this:
> 

Step 1:
> Tues Oct 23, 2018:
> 
> The latest monorepo prototype[1] will be moved over to the LLVM
> organization github project[2] and will begin mirroring the current
> SVN repository.  Commits will still be made to the SVN repository
> just as they are today.
> 
> All community members should begin migrating their workflows that
> rely on SVN or the current git mirrors to use the new monorepo.  
> 
> For CI jobs or internal mirrors pulling from SVN or
> http://llvm.org/git/*.git you should modify them to pull from
> the new monorepo and also to deal with the new repository
> layout.
> 
> For Developers, you should begin using the new monorepo
> for your development and using the provided scripts[3]
> to commit your code.  These scripts will allow to commit
> to SVN from the monorepo without using git-svn
> 
> 

Sorry hit send before I was done.  Here is the rest of the mail:

Step 2:

Around the time of next year's developer meeting (1 year at the most),
we will turn off commit access to the SVN server and enable commit
access to the monorepo.  At this point the monorepo will become the
'one source of truth' for the project.  Community members *must* have
updated their workflows by this date and are encouraged to begin
updating workflows ASAP.

A lot of people asked at the developer meeting about the future
of bugzilla and phabricator and whether or not we will use
github issues and pull requests.  These are important questions,
but are unrelated to the migration of the code.

We also came up with a TODO list for things we want to accomplish
as a community in the next year and beyond related to github.  I
am working on putting these into bugzilla so we can track progress
better and I will send a follow-up email about this.

-Tom

> 
> 
> 
> 
> [1] https://github.com/llvm-git-prototype/llvm
> [2] https://github.com/llvm/
> [3] 
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [llvm-dev] Updates on SVN to GitHub migration

[Tom Stellard via lldb-dev]

On 10/22/2018 08:31 AM, David Greene wrote:
> I had a short side-conversation at one of the roundtables about existing
> users of the subproject repositories.  It would be helpful to have
> instructions about the best way to move local branches in those
> repositories to the monorepo and some scripts to help with the
> transition.  I know someone posted an example project a while ago with
> some scripts but my sense is that those scripts were particular to that
> project and maybe not generally applicable.
> 
> Once the monorepo goes live (tomorrow?), what happens to the existing
> subproject mirrors?  Do they get wiped away and replaced with history
> from the monorepo?  Or are entirely new mirrors created?  Or do they
> just continue to mirror SVN until SVN becomes read-only?
> 

After Tuesday, the existing sub-projects mirrors will continue to mirror SVN
as they do today.  It's undecided what will happen once SVN becomes read-only.

-Tom

> The first option would essentially be a rewrite of history for the
> subproject repositories.  We'll need to know if/when that is going to
> happen.
> 
>   -David
> 
> Jonas Hahnfeld via Openmp-dev  writes:
> 
>> (+openmp-dev, they should know about this!)
>>
>> Recapping the "Concerns"
>> (https://llvm.org/docs/Proposals/GitHubMove.html#id12) there is a
>> proposal of "single-subproject Git mirrors" for people who are only
>> contributing to standalone subprojects. I think this will be easy in
>> the transition period, we can just continue to move the current
>> official git mirrors. Will this "service" be continued after GitHub
>> becomes the 'one source of truth'? I'd strongly vote for yes, but I'm
>> not sure how that's going to work on a technical level.
>>
>> Thanks,
>> Jonas
>>
>> On 2018-10-20 03:14, Tom Stellard via llvm-dev wrote:
>>> On 10/19/2018 05:47 PM, Tom Stellard via lldb-dev wrote:
>>>> TLDR: Official monorepo repository will be published on
>>>> Tuesday, Oct 23, 2018.  After this date, you should modify
>>>> your workflows to use the monorepo ASAP.  Current workflows
>>>> will be supported for at most 1 more year.
>>>>
>>>> Hi,
>>>>
>>>> We had 2 round-tables this week at the Developer Meeting to
>>>> discuss the SVN to GitHub migration, and I wanted to update
>>>> the rest of the community on what we discussed.
>>>>
>>>> The most important outcome from that meeting is that we
>>>> now have a timeline for completing the transition which looks
>>>> like this:
>>>>
>>>
>>> Step 1:
>>>> Tues Oct 23, 2018:
>>>>
>>>> The latest monorepo prototype[1] will be moved over to the LLVM
>>>> organization github project[2] and will begin mirroring the current
>>>> SVN repository.  Commits will still be made to the SVN repository
>>>> just as they are today.
>>>>
>>>> All community members should begin migrating their workflows that
>>>> rely on SVN or the current git mirrors to use the new monorepo.
>>>>
>>>> For CI jobs or internal mirrors pulling from SVN or
>>>> http://llvm.org/git/*.git you should modify them to pull from
>>>> the new monorepo and also to deal with the new repository
>>>> layout.
>>>>
>>>> For Developers, you should begin using the new monorepo
>>>> for your development and using the provided scripts[3]
>>>> to commit your code.  These scripts will allow to commit
>>>> to SVN from the monorepo without using git-svn
>>>>
>>>>
>>>
>>> Sorry hit send before I was done.  Here is the rest of the mail:
>>>
>>> Step 2:
>>>
>>> Around the time of next year's developer meeting (1 year at the most),
>>> we will turn off commit access to the SVN server and enable commit
>>> access to the monorepo.  At this point the monorepo will become the
>>> 'one source of truth' for the project.  Community members *must* have
>>> updated their workflows by this date and are encouraged to begin
>>> updating workflows ASAP.
>>>
>>> A lot of people asked at the developer meeting about the future
>>> of bugzilla and phabricator and whether or not we will use
>>> github issues and pull requests.  These are important questions,
>>> but are unrelated to the migration of the code.
>>

[lldb-dev] LLVM 7.0.1-rc1 release on Thursday

[Tom Stellard via lldb-dev]

Hi,

I'm planning to do the LLVM 7.0.1-rc1 release on Thursday.  This is really
just a snapshot release of the current release branch, but It's still
important that it gets testing.  You still have until Nov 21 to get
patches into the final release, so you can keep sending me merge
requests.

I would also really like to get the gcc/clang abi mismatch bug[1]
fixed for this release.  If you have any suggestions for how to fix
it, let me know.  We actually need two different fixes, one for trunk
and one for the release_70 branch which is able to maintain the current ABI.

Thanks,
Tom

[1] https://bugs.llvm.org/show_bug.cgi?id=39427
___
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] [RFC] LLVM bug lifecycle BoF - triaging

[Tom Stellard via lldb-dev]

On 10/31/2018 06:27 AM, Kristof Beyls wrote:
> 
> 
>> On 26 Oct 2018, at 17:26, Kristof Beyls > > wrote:
>>
>>
>>
>>> On 26 Oct 2018, at 16:25, Kristof Beyls via llvm-dev 
>>> mailto:llvm-...@lists.llvm.org>> wrote:
>>>
>>>
>>>
 On 26 Oct 2018, at 04:26, Richard Smith >>> > wrote:

 On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
 mailto:cfe-...@lists.llvm.org>> wrote:

> On 5 Oct 2018, at 07:04, Dean Michael Berris  > wrote:
>
> Thank you for starting this conversation! I look forward to the 
> results of the BoF discussion summarised as well.

 Dean, all,

 There was a lively discussion at the BoF; we’ve tried to take notes at 
 https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to 
 capture all the points. The slides used to kick start the discussion can 
 be found at 
 https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

 Both at the BoF and in the mail thread, there have been many 
 suggestions for improvements. So many that if we’d want to introduce all 
 of them at once, we’d probably get stuck and not introduce any. To try and 
 make progress on the ones I myself feel are most useful, I’ve volunteered 
 for 2 actions:

 1. Write up a proposal for documentation on what to do during bug 
 triaging/closing/etc. I’ve just done so and put it up for review at 
 https://reviews.llvm.org/D53691.
 2. Write an email to the mailing lists to ask for volunteers for being 
 on the “default-cc” list for components, implying you’re willing to triage 
 bugs reported against those components. I’ve decided to first try and get 
 consensus on what is expected when triaging a bug (see point above) before 
 actively searching for volunteers for all components. That being said, 
 both at the dev meeting and in the days after, I already received many 
 requests from people to be added to the default-cc list for specific 
 components. Of course, I’m very happy to add people volunteering to 
 default-cc lists, so if you don’t want to wait to get added to a 
 default-cc list, please email bugs-ad...@lists.llvm.org 
  or raise it as a ticket in 
 bugs.llvm.org  under “Bugzilla Admin”/“Products”.

 Furthermore, since the BoF, I’ve seen a quite a few requests to clean 
 up and introduce new components in Bugzilla. We’ve implemented the changes 
 quickly and will aim to continue to have a quick response time in the 
 future. Please file a ticket in bugs.llvm.org  
 under “Bugzilla Admin”/“Products” if you want to request a specific change.

 For most of the other points that were raised: I don’t currently plan 
 on acting on them immediately myself and hope to first see an impact of 
 the above actions.


 In the original post, there was a suggestion to bring back the 
 "UNCONFIRMED" status. I think that'd be a great idea, as it both makes it 
 easy to search for untriaged bugs and to give feedback to a reporter that 
 their bug is real and acknowledged. Is that planned?
>>>
>>> I hadn’t seen too much feedback on the idea for introducing 
>>> (reintroducing?) the “UNCONFIRMED” status, so hadn’t planned on making 
>>> changes to that now.
>>> However, I also think it’s a good idea, so I’ll investigate in more detail 
>>> now if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. 
>>> I believe I’ll have to give all existing users the rights to be able to 
>>> confirm bugs). If the “UNCONFIRMED” status can be introduced relatively 
>>> easily, I now plan to do so, and will adapt the proposed documentation at 
>>> https://reviews.llvm.org/D53691 accordingly.
>>> Thanks for pointing to this!
>>
>> Just a status update on investigations to enable the UNCONFIRMED/CONFIRMED 
>> states: it seems that bugzilla by-default will put bugs in the “CONFIRMED” 
>> state when creating new bugs, if the reporter has “can-confirm” rights. I 
>> believe our de facto policy is for everyone with an account to be able to 
>> confirm bugs. Also, you need an account to be able to report a bug. The 
>> result is that all new bugs by default will go to status “CONFIRMED”, unless 
>> the reporter carefully remembers to change the default and select 
>> “UNCONFIRMED”. (Also see https://bugzilla.mozilla.org/show_bug.cgi?id=915682 
>> which suggests this behaviour is not configurable).
>>
>> Unless that can be solved, I fear that many bugs will be reported with the 
>> default “CONFIRMED” status even though they aren’t triaged yet. I believe 
>> that is worse than the current default “NEW” state.
>>
>> The only work around for this behaviour where we still get

[lldb-dev] 7.0.1-rc2 release has been tagged please begin testing

[Tom Stellard via lldb-dev]

Hi,

The 7.0.1-rc2 release has been tagged and is ready for testing.  I forgot
to bump the version number to 7.0.1 before I tagged -rc1, which is why we
are now on -rc2.

Remember, you can continue to submit merge requests up until Nov, 21,
so keep testing and submitting fixes.

Thanks,
Tom 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] 7.0.1 Release Schedule Update: Merge Request Deadline Nov 30

[Tom Stellard via lldb-dev]

Hi,

The merge request deadline was supposed to be last Wednesday, but there
are still a few outstanding issue, so I'm going to push the deadline
back to this Friday, Nov 30.  If you have any fixes you want to
get in, please file bugs and mark them as blockers for the release-7.0.1
metabug.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 7.0.1-rc3 has been tagged.

[Tom Stellard via lldb-dev]

Hi,

I've just tagged 7.0.1-rc3.  This will hopefully be the last release candidate.
Please test and report results.

Thanks,
Tom
___
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] Updates on SVN to GitHub migration

[Tom Stellard via lldb-dev]

On 12/10/2018 10:38 AM, Nico Weber wrote:
> Here's another question about the current status of this. It's close to two 
> months after the official monorepo was supposed to be published. Can someone 
> give an update? Is this on hold indefinitely? Are there concrete issues that 
> people are working on and this will happen as soon as those are resolved?
> 

There were some issues raised in the thread on llvm-dev:
"Dealing with out of tree changes and the LLVM  git monorepo"  This migration
has been delayed while discussing these issues.  Discussion on that
thread has died down and it seems like the consensus is to move forward with
the original plan, but we are waiting to get some formal closure on that thread.

> At the least, I'm assuming the "SVN will shut down 1 year from now" refers to 
> 1 year from when the monorepo actually gets published, not 1 year relative to 
> when the initial mail got sent?
> 

The deadline for SVN shutdown remains unchanged.  It's still going to be
around the 2019 LLVM Developers meeting.

> Someone mentioned an issue with github's svn bridge, but it wasn't clear if 
> that's blocking, and if it is if there's a plan for it.
> 

It's not a blocking issue and there haven't been any updates lately,
you can follow status on this bug: 
https://bugs.llvm.org/show_bug.cgi?id=39396

-Tom

> Thanks
> Nico
> 
> On Sat, Oct 20, 2018 at 4:10 AM Jonas Hahnfeld via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> (+openmp-dev, they should know about this!)
> 
> Recapping the "Concerns"
> (https://llvm.org/docs/Proposals/GitHubMove.html#id12) there is a
> proposal of "single-subproject Git mirrors" for people who are only
> contributing to standalone subprojects. I think this will be easy in the
> transition period, we can just continue to move the current official git
> mirrors. Will this "service" be continued after GitHub becomes the 'one
> source of truth'? I'd strongly vote for yes, but I'm not sure how that's
> going to work on a technical level.
> 
> Thanks,
> Jonas
> 
> On 2018-10-20 03:14, Tom Stellard via llvm-dev wrote:
> > On 10/19/2018 05:47 PM, Tom Stellard via lldb-dev wrote:
> >> TLDR: Official monorepo repository will be published on
> >> Tuesday, Oct 23, 2018.  After this date, you should modify
> >> your workflows to use the monorepo ASAP.  Current workflows
> >> will be supported for at most 1 more year.
> >>
> >> Hi,
> >>
> >> We had 2 round-tables this week at the Developer Meeting to
> >> discuss the SVN to GitHub migration, and I wanted to update
> >> the rest of the community on what we discussed.
> >>
> >> The most important outcome from that meeting is that we
> >> now have a timeline for completing the transition which looks
> >> like this:
> >>
> >
> > Step 1:
> >> Tues Oct 23, 2018:
> >>
> >> The latest monorepo prototype[1] will be moved over to the LLVM
> >> organization github project[2] and will begin mirroring the current
> >> SVN repository.  Commits will still be made to the SVN repository
> >> just as they are today.
> >>
> >> All community members should begin migrating their workflows that
> >> rely on SVN or the current git mirrors to use the new monorepo.
> >>
> >> For CI jobs or internal mirrors pulling from SVN or
> >> http://llvm.org/git/*.git you should modify them to pull from
> >> the new monorepo and also to deal with the new repository
> >> layout.
> >>
> >> For Developers, you should begin using the new monorepo
> >> for your development and using the provided scripts[3]
> >> to commit your code.  These scripts will allow to commit
> >> to SVN from the monorepo without using git-svn
> >>
> >>
> >
> > Sorry hit send before I was done.  Here is the rest of the mail:
> >
> > Step 2:
> >
> > Around the time of next year's developer meeting (1 year at the most),
> > we will turn off commit access to the SVN server and enable commit
> > access to the monorepo.  At this point the monorepo will become the
> > 'one source of truth' for the project.  Community members *must* have
> > updated their workflows by this date a

[lldb-dev] 7.0.1-final has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged the 7.0.1 final release.  Testers may begin uploading binaries.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote:
> Can the ubuntu tarballs be published to the download site? They're not 
> available yet.
> 

These are up on the download site now.

-Tom

> On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Ubuntu and SLES tarballs uploaded.  I haven't had a chance to make a 
> SLES12 build yet, but I will try in the coming days.
> 
> f7553a0d66092ca0bbe1eab2af405523a18bafba  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> 41db01a3b216df4fc22fae9c44e248889f9a01ed  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> caf149635742622a3a5b220146ff34f9202b8670  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> 5e2b33ac129b8471683dccaeb2818004eb5acea8  
> clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz
> 
> 
> On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> 
> On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> >
> > I've tagged the 7.0.1 final release.  Testers may begin uploading 
> binaries.
> 
> Main test results on amd64-freebsd11 had 1 more Expected Pass 
> compared to 7.0.1 rc3, and no more Passes With Retry:
> 
> Expected Passes: 52445(7.0.1 rc3: 52444)
> Passes With Retry  :   n/a(7.0.1 rc3: 1)
> Expected Failures  :   232(7.0.1 rc3:   232)
> Unsupported Tests  :  3687(7.0.1 rc3:  3687)
> Unexpected Passes  : 1(7.0.1 rc3: 1)
> Unexpected Failures:   491(7.0.1 rc3:   491)
> 
> Test-suite results on amd64-freebsd11 did not change:
> 
> Expected Passes:   903(7.0.1 rc3:   903)
> Unexpected Failures: 3(7.0.1 rc3: 3)
> 
> Test results on i386-freebsd11 had 1 more Expected Pass compared to 
> 7.0.1 rc3, and 3 less Unexpected Failures:
> 
> Expected Passes: 50254(7.0.1 rc3: 50253)
> Passes With Retry  : 2(7.0.1 rc3:   n/a)
> Expected Failures  :   226(7.0.1 rc3:   226)
> Unsupported Tests  :  2502(7.0.1 rc3:  2502)
> Unexpected Failures:   272(7.0.1 rc3:   275)
> 
> The test-suite still doesn't build on i386-freebsd11, but that is a 
> known issue.
> 
> I have uploaded:
> 
> SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = 
> 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407
> SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = 
> 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36
> 
> -Dimitry
> 
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> 
> 
> 
> -- 
> -Brian
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 
> 
> 
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] 7.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/09/2019 05:03 AM, Brian Cain wrote:
> 
> 
> On Tue, Jan 8, 2019 at 11:25 PM Tom Stellard  > wrote:
> 
> On 01/08/2019 11:36 AM, Ian Tessier via Release-testers wrote:
> > Can the ubuntu tarballs be published to the download site? They're not 
> available yet.
> >
> 
> These are up on the download site now.
> 
> 
> Tom, releases.llvm.org  only shows Windows and 
> FreeBSD tarballs for 7.0.1 from what I can see.
> 

I forgot to add the links, they are up now.

> Also, the front page of https://releases.llvm.org/ needs a new entry for 
> 7.0.1 in the table under "Download".
>  

This has been fixed too.

-Tom
> 
> 
> > On Mon, Dec 24, 2018 at 7:38 AM Brian Cain via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Ubuntu and SLES tarballs uploaded.  I haven't had a chance to make 
> a SLES12 build yet, but I will try in the coming days.
> >
> > f7553a0d66092ca0bbe1eab2af405523a18bafba  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> > 41db01a3b216df4fc22fae9c44e248889f9a01ed  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> > caf149635742622a3a5b220146ff34f9202b8670  
> clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> > 5e2b33ac129b8471683dccaeb2818004eb5acea8  
> clang+llvm-7.0.1-x86_64-linux-sles11.3.tar.xz
> >
> >
> > On Thu, Dec 20, 2018 at 12:18 PM Dimitry Andric via Release-testers 
> mailto:release-test...@lists.llvm.org> 
>  >> wrote:
> >
> > On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers 
> mailto:release-test...@lists.llvm.org> 
>  >> wrote:
> > >
> > > I've tagged the 7.0.1 final release.  Testers may begin 
> uploading binaries.
> >
> > Main test results on amd64-freebsd11 had 1 more Expected Pass 
> compared to 7.0.1 rc3, and no more Passes With Retry:
> >
> > Expected Passes: 52445(7.0.1 rc3: 52444)
> > Passes With Retry  :   n/a(7.0.1 rc3: 1)
> > Expected Failures  :   232(7.0.1 rc3:   232)
> > Unsupported Tests  :  3687(7.0.1 rc3:  3687)
> > Unexpected Passes  : 1(7.0.1 rc3: 1)
> > Unexpected Failures:   491(7.0.1 rc3:   491)
> >
> > Test-suite results on amd64-freebsd11 did not change:
> >
> > Expected Passes:   903(7.0.1 rc3:   903)
> > Unexpected Failures: 3(7.0.1 rc3: 3)
> >
> > Test results on i386-freebsd11 had 1 more Expected Pass 
> compared to 7.0.1 rc3, and 3 less Unexpected Failures:
> >
> > Expected Passes: 50254(7.0.1 rc3: 50253)
> > Passes With Retry  : 2(7.0.1 rc3:   n/a)
> > Expected Failures  :   226(7.0.1 rc3:   226)
> > Unsupported Tests  :  2502(7.0.1 rc3:  2502)
> > Unexpected Failures:   272(7.0.1 rc3:   275)
> >
> > The test-suite still doesn't build on i386-freebsd11, but that 
> is a known issue.
> >
> > I have uploaded:
> >
> > SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = 
> 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407
> > SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = 
> 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36
> >
> > -Dimitry
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org 
>  
>  >
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
> >
> >
> > --
> > -Brian
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org  
> >
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > ___
> > Release-testers mailing list
> > release-test...@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> >
> 
> 
> 
> -- 
> -Brian

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Github] RFC: linear history vs merge commits

[Tom Stellard via lldb-dev]

Hi,

As part of the migration of LLVM's source code to github, we need to update
our developer policy with instructions about how to interact with the new git
repository.  There are a lot of different topics we will need to discuss, but
I would like to start by initiating a discussion about our merge commit
policy.  Should we:

1. Disallow merge commits and enforce a linear history by requiring a
   rebase before push.

2. Allow merge commits.

3. Require merge commits and disallow rebase before push.

I'm going to propose that if we cannot reach a consensus that we
adopt policy #1, because this is essentially what we have now
with SVN.

What does everyone think?

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [Github] RFC: linear history vs merge commits

[Tom Stellard via lldb-dev]

On 01/29/2019 02:48 PM, David Greene wrote:
> Tom Stellard via Openmp-dev  writes:
> 
>> As part of the migration of LLVM's source code to github, we need to update
>> our developer policy with instructions about how to interact with the new git
>> repository.  There are a lot of different topics we will need to discuss, but
>> I would like to start by initiating a discussion about our merge commit
>> policy.  Should we:
>>
>> 1. Disallow merge commits and enforce a linear history by requiring a
>>rebase before push.
>>
>> 2. Allow merge commits.
>>
>> 3. Require merge commits and disallow rebase before push.
>>
>> I'm going to propose that if we cannot reach a consensus that we
>> adopt policy #1, because this is essentially what we have now
>> with SVN.
> 
> I agree with proposing #1 in general.  It results in a nice clean
> history and will be familiar to everyone working on the project.
> 
> However, there is a place for merge commits.  If there's a bug in a
> release and we want to make a point release, it might make sense to make
> a commit on the release branch and then merge the release branch to
> master in order to ensure the fix lands there as well.  Another option
> is to commit to master first and then cherry-pick to release.  A third
> option is to use the "hotfix branch" method of git flow [1], which would
> result in a merge commit to the release branch and another merge commit
> to master.
> 

Our current bug-fix fix process is to commit to master first and then
cherry-pick to release branches.

> I've seen projects that commit to release first and then merge release
> to master and also projects that commit to master and cherry-pick to
> release.  I personally haven't seen projects employ the git flow hotfix
> branch method rigorously.
> 
> But GitHub is read-only for almost a year, right?  So we really don't
> have to decide this for a while.  I have not tried using the monorepo
> and committing to SVN with it.  How does that work?  What would it do
> with merge commits?
> 

It will be read-only until October 2019, but I think it's important to decide
on this issue early so we have time to research and implement ways to
automatically enforce our policy to make things as smooth as possible
when we do switch.  I really want us to be able to keep our current migration
schedule.

The GettingStarted patch has been updated with instructions for how to use
the new repo: https://llvm.org/docs/GettingStarted.html#checkout-llvm-from-git

-Tom
>   -David
> 
> [1] https://nvie.com/posts/a-successful-git-branching-model
> 

___
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] [Github] RFC: linear history vs merge commits

[Tom Stellard via lldb-dev]

On 01/30/2019 10:53 PM, Mehdi AMINI via llvm-dev wrote:
> 
> 
> On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev
> mailto:cfe-...@lists.llvm.org>> wrote:
> >
> > Bruce Hoult via llvm-dev  > writes:
> >
> > > How about:
> > >
> > > Require a rebase, followed by git merge --no-ff
> > >
> > > This creates a linear history, but with extra null merge commits
> > > delimiting each related series of patches.
> > >
> > > I believe it is compatible with bisect.
> > >
> > > https://linuxhint.com/git_merge_noff_option/
> >
> > We've done both and I personally prefer the strict linear history by a
> > lot.  It's just much easier to understand a linear history.
> >
> 
> Agreed. Let's go with option #1.
> 
> 
> What is the practical plan to enforce the lack of merges? When we looked into 
> this GitHub would not support this unless also forcing every change to go 
> through a pull request (i.e. no pre-receive hooks on direct push to master 
> were possible). Did this change? Are we hoping to get support from GitHub on 
> this?
> 

No enforcement plan at this point, but I was planning to contact github about 
this to
see what options we had.  Last time you looked into it, did you talk to anyone 
at github
support?

This is also why I think it's important to decide early so we have time to look 
at
what our options are to enforce these policies. If pull requests are our only
option for enforcement, then I think it would be good to know that before we
have a large debate about Phabricator vs Pull Requests.

-Tom


> We may write this rule in the developer guide, but I fear it'll be hard to 
> enforce in practice.
>
 -- 
> Mehdi
> 
> 
> 
> ___
> 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] [cfe-dev] [Github] RFC: linear history vs merge commits

[Tom Stellard via lldb-dev]

On 01/31/2019 09:51 AM, Roman Lebedev via llvm-dev wrote:
> On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
>  wrote:
>>
>> Mehdi AMINI  writes:
>>
>>> What is the practical plan to enforce the lack of merges? When we
>>> looked into this GitHub would not support this unless also forcing
>>> every change to go through a pull request (i.e. no pre-receive hooks
>>> on direct push to master were possible). Did this change? Are we
>>> hoping to get support from GitHub on this?
>>>
>>> We may write this rule in the developer guide, but I fear it'll be
>>> hard to enforce in practice.
>>
>> Again, changes aren't going through git yet, right?  Not until SVN is
>> decommissioned late this year (or early next).  SVN requires a strict
>> linear history so it handles the enforcement for now.
> 
>> My personal opinion is that when SVN is decomissioned we should use pull
>> requests, simply because that's what's familiar to the very large
>> development community outside LLVM.  It will lower the bar to entry for
>> new contributors.  This has all sorts of implications we need to discuss
>> of course, but we have some time to do that.
> My personal opinion is an opposite of that one.
> 
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
> 

This hasn't been decided yet, but this is a whole other discussion
that deserves it own thread (not saying we need to decide this now though).

-Tom

> Low bar for entry is good, but not at the cost of raising the bar
> for the existing development community.
> In particular, i'm saying that github's ui/workflow/feature set
> is inferior to that one of phabricator.
> 
> Is the low entry bar the only benefit?
> While it is good, it should not be the only factor.
> The contributors will already need to know how to build LLVM,
> write tests, make meaningful changes to the code.
> Additionally having to know how to work with phabricator
> isn't that much to ask for, considering the other prerequisites..
> 
>> If we don't use PRs, then we're pretty much on the honor system to
>> disallow merges AFAIK.
>>
>>  -David
> Roman.
> 
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> 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

[lldb-dev] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

Hi,

The release_70 branch is ready for the 7.1.0 release.  I have updated the
version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427,
which is the only bug we will be fixing in this release.

Since this is an ABI breaking changing and also we are introducing a
minor version for the first time, please take some time to test the
branch and make sure everything works as expected.  I'm going
to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
activity around the release calms down a little.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

On 02/05/2019 08:07 AM, Michał Górny wrote:
> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
> wrote:
>> Hi,
>>
>> The release_70 branch is ready for the 7.1.0 release.  I have updated the
>> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427,
>> which is the only bug we will be fixing in this release.
>>
>> Since this is an ABI breaking changing and also we are introducing a
>> minor version for the first time, please take some time to test the
>> branch and make sure everything works as expected.  I'm going
>> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
>> activity around the release calms down a little.
>>
> 
> The SOVERSION is still '7'.  Maybe we should force it to '7.1' here?
> 

It should already be changed.  This is what I get when I build:

[tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
  SONAME   libLLVM-7.1.so


-Tom


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

On 02/05/2019 11:26 AM, Michał Górny wrote:
> On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote:
>> On 02/05/2019 08:07 AM, Michał Górny wrote:
>>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
>>> wrote:
 Hi,

 The release_70 branch is ready for the 7.1.0 release.  I have updated the
 version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427,
 which is the only bug we will be fixing in this release.

 Since this is an ABI breaking changing and also we are introducing a
 minor version for the first time, please take some time to test the
 branch and make sure everything works as expected.  I'm going
 to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
 activity around the release calms down a little.

>>>
>>> The SOVERSION is still '7'.  Maybe we should force it to '7.1' here?
>>>
>>
>> It should already be changed.  This is what I get when I build:
>>
>> [tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
>>   SONAME   libLLVM-7.1.so
>>
> 
> I'm talking about SOVERSION of shared libs from BUILD_SHARED_LIBS=ON. 
> The one defined in llvm_add_library() function:
> 
>   set_target_properties(${name}
> PROPERTIES
> # Since 4.0.0, the ABI version is indicated by the major version
> SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}
> VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX})
> 

Ok, I see.  You are correct, we should change the soname on those.  I can
fix this.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote:
> On 02/05/2019 11:26 AM, Michał Górny wrote:
>> On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote:
>>> On 02/05/2019 08:07 AM, Michał Górny wrote:
 On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
 wrote:
> Hi,
>
> The release_70 branch is ready for the 7.1.0 release.  I have updated the
> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427,
> which is the only bug we will be fixing in this release.
>
> Since this is an ABI breaking changing and also we are introducing a
> minor version for the first time, please take some time to test the
> branch and make sure everything works as expected.  I'm going
> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
> activity around the release calms down a little.
>

 The SOVERSION is still '7'.  Maybe we should force it to '7.1' here?

>>>
>>> It should already be changed.  This is what I get when I build:
>>>
>>> [tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
>>>   SONAME   libLLVM-7.1.so
>>>
>>
>> I'm talking about SOVERSION of shared libs from BUILD_SHARED_LIBS=ON. 
>> The one defined in llvm_add_library() function:
>>
>>   set_target_properties(${name}
>> PROPERTIES
>> # Since 4.0.0, the ABI version is indicated by the major version
>> SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}
>> VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX})
>>
> 
> Ok, I see.  You are correct, we should change the soname on those.  I can
> fix this.
> 

This should be fixed now by r353247, can you re-test?

-Tom

> -Tom
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

On 02/05/2019 10:41 PM, Michał Górny wrote:
> On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote:
>> On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote:
>>> On 02/05/2019 11:26 AM, Michał Górny wrote:
 On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote:
> On 02/05/2019 08:07 AM, Michał Górny wrote:
>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
>> wrote:
>>> Hi,
>>>
>>> The release_70 branch is ready for the 7.1.0 release.  I have updated 
>>> the
>>> version and pushed a fix for 
>>> https://bugs.llvm.org/show_bug.cgi?id=39427,
>>> which is the only bug we will be fixing in this release.
>>>
>>> Since this is an ABI breaking changing and also we are introducing a
>>> minor version for the first time, please take some time to test the
>>> branch and make sure everything works as expected.  I'm going
>>> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
>>> activity around the release calms down a little.
>>>
>>
>> The SOVERSION is still '7'.  Maybe we should force it to '7.1' here?
>>
>
> It should already be changed.  This is what I get when I build:
>
> [tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
>   SONAME   libLLVM-7.1.so
>

 I'm talking about SOVERSION of shared libs from BUILD_SHARED_LIBS=ON. 
 The one defined in llvm_add_library() function:

   set_target_properties(${name}
 PROPERTIES
 # Since 4.0.0, the ABI version is indicated by the major version
 SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}
 VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX})

>>>
>>> Ok, I see.  You are correct, we should change the soname on those.  I can
>>> fix this.
>>>
>>
>> This should be fixed now by r353247, can you re-test?
>>
> 
> Yes, though I don't think returning to '71' is a good idea.  It
> introduces a value that is technically larger than '8', and people
> running ldconfig(1) will get libs relinked to .so.71 all the time. 
> Putting a dot there should be safer.
> 

This is fixed now in r353348.  Can you test again?

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0 release - Please test the branch

[Tom Stellard via lldb-dev]

On 02/06/2019 10:57 PM, Michał Górny wrote:
> On Wed, 2019-02-06 at 14:09 -0800, Tom Stellard wrote:
>> On 02/05/2019 10:41 PM, Michał Górny wrote:
>>> On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote:
 On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote:
> On 02/05/2019 11:26 AM, Michał Górny wrote:
>> On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote:
>>> On 02/05/2019 08:07 AM, Michał Górny wrote:
 On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers
 wrote:
> Hi,
>
> The release_70 branch is ready for the 7.1.0 release.  I have updated 
> the
> version and pushed a fix for 
> https://bugs.llvm.org/show_bug.cgi?id=39427,
> which is the only bug we will be fixing in this release.
>
> Since this is an ABI breaking changing and also we are introducing a
> minor version for the first time, please take some time to test the
> branch and make sure everything works as expected.  I'm going
> to try to do the 7.1.0-rc1 release some time after 8.0.0-rc2, once the
> activity around the release calms down a little.
>

 The SOVERSION is still '7'.  Maybe we should force it to '7.1' here?

>>>
>>> It should already be changed.  This is what I get when I build:
>>>
>>> [tstellar@llvm llvm-build]$ objdump -p lib/libLLVM-7.1.so | grep SONAME
>>>   SONAME   libLLVM-7.1.so
>>>
>>
>> I'm talking about SOVERSION of shared libs from BUILD_SHARED_LIBS=ON. 
>> The one defined in llvm_add_library() function:
>>
>>   set_target_properties(${name}
>> PROPERTIES
>> # Since 4.0.0, the ABI version is indicated by the major version
>> SOVERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX}
>> VERSION ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX})
>>
>
> Ok, I see.  You are correct, we should change the soname on those.  I can
> fix this.
>

 This should be fixed now by r353247, can you re-test?

>>>
>>> Yes, though I don't think returning to '71' is a good idea.  It
>>> introduces a value that is technically larger than '8', and people
>>> running ldconfig(1) will get libs relinked to .so.71 all the time. 
>>> Putting a dot there should be safer.
>>>
>>
>> This is fixed now in r353348.  Can you test again?
>>
> 
> You forgot to update VERSION as well.
> 

This should be fixed now in r353565.  Let me know if there are any other issues.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

Hi,

I would like to follow up on the previous thread[1], where there was a consensus
to disallow merge commits in the llvm github repository, and start a discussion
about how we should enforce this policy.

Unfortunately, GitHub does not provide a convenient way to fully enforce this 
policy.
We can enforce it for pull requests, but not for direct pushes to the master 
branch,
so we will have to come up with our own solution if we want to completely 
prevent
merge commits.  I've spent some time looking into this and here are a few
options that I've come up with (If you are a GitHub expert and have other
suggestions, please let us know):

1. Have either a status check or use the "Rebase and Merge" policy for pull 
requests
to disallow merge commits.  Disable direct pushes to the master branch and 
update the
git-llvm script to create a pull request when a developer does `git llvm push` 
and
then have it automatically merged if there are no merge commits.

2. Enforce no merge commits for pull requests, but sill allow developers to 
push directly
to master without checking for merge requests.  This is essentially a best 
effort
approach where we avoid having to implement our own custom work-flow for 
committing,
while accepting the possibility that someone might accidentally push a merge 
commit.

3. Disable direct pushes to master, don't update the git-llvm script and 
require all
developers to use pull requests, where this policy will be enforced.

Which option do you prefer?

-Tom

[1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/20/2019 10:41 AM, Zachary Turner wrote:
> 
> 
> On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Hi,
> 
> I would like to follow up on the previous thread[1], where there was a 
> consensus
> to disallow merge commits in the llvm github repository, and start a 
> discussion
> about how we should enforce this policy.
> 
> Unfortunately, GitHub does not provide a convenient way to fully enforce 
> this policy.
> 
>  
> Why isn't this enforceable with a server-side pre-receive hook?

GitHub[1] only supports pre-receive hooks in the 'Enterprise Server'
plan, which is for self-hosted github instances.

-Tom

[1] https://github.com/pricing
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/20/2019 11:38 AM, Zachary Turner wrote:
> It sounds like we need to get someone from the Foundation (chandlerc@, 
> lattner@, tanya@, someone else?) to reach out to them offline about this.
> 

Yes, we will try to reach out to GitHub directly about this, but I still
think we need some kind of contingency plan in case pre-receive hooks
or even a new kind of branch protection won't be an option for us.

-Tom

> On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer  <mailto:arthur.j.odw...@gmail.com>> wrote:
> 
> On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> On 03/20/2019 10:41 AM, Zachary Turner wrote:
>     >
>     > On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev 
> mailto:lldb-dev@lists.llvm.org> 
> <mailto:lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>>> wrote:
> >
> > Hi,
> >
> > I would like to follow up on the previous thread[1], where 
> there was a consensus
> > to disallow merge commits in the llvm github repository, and 
> start a discussion
> > about how we should enforce this policy.
> >
> > Unfortunately, GitHub does not provide a convenient way to 
> fully enforce this policy.
> >
> > 
> > Why isn't this enforceable with a server-side pre-receive hook?
> 
> GitHub[1] only supports pre-receive hooks in the 'Enterprise Server'
> plan, which is for self-hosted github instances.
> 
> 
> AIUI, the GitHub team is perfectly willing to help out the LLVM project 
> in whatever way LLVM needs, including but not limited to turning on 
> server-side hooks for us.
> https://twitter.com/natfriedman/status/1086470665832607746
> 
> Server-side hooks are *the *answer to this problem. There is no problem. 
> You just use a server-side hook.
> 
> (Whether or not to use GitHub PRs is an orthogonal question. You can use 
> hooks with PRs, or hooks without PRs; PRs with hooks, or PRs without hooks.)
> 
> –Arthur
> 

___
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] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/21/2019 10:32 AM, Pavel Labath via llvm-dev wrote:
> On 21/03/2019 13:12, David Chisnall via lldb-dev wrote:
>> On 20 Mar 2019, at 18:23, Arthur O'Dwyer via cfe-dev 
>>  wrote:
>>>
>>> Server-side hooks are the answer to this problem. There is no problem. You 
>>> just use a server-side hook.
>>
>> It is quite unlikely that GitHub will allow LLVM (or any other project) to 
>> run arbitrary post-receive hooks. 
> 
> What about a single, simple, specific post-receive hook that has been vetted 
> by the github team, and that cannot by changed from the LLVM side without 
> going through their customer support team (and additional vetting)?

GitHub already has something like this, called branch protections[1].  There
just isn't a 'no merge commit' protection, but this is something I'm going to
request.

-Tom


[1] https://help.github.com/en/articles/configuring-protected-branches

> ___
> 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

[lldb-dev] Release 7.1.0 -rc1 has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've just tagged 7.1.0-rc1.  Testers, please begin testing and reporting
results.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/19/2019 11:59 AM, Tom Stellard via Openmp-dev wrote:
> Hi,
> 
> I would like to follow up on the previous thread[1], where there was a 
> consensus
> to disallow merge commits in the llvm github repository, and start a 
> discussion
> about how we should enforce this policy.
> 
> Unfortunately, GitHub does not provide a convenient way to fully enforce this 
> policy.
> We can enforce it for pull requests, but not for direct pushes to the master 
> branch,
> so we will have to come up with our own solution if we want to completely 
> prevent
> merge commits.  I've spent some time looking into this and here are a few
> options that I've come up with (If you are a GitHub expert and have other
> suggestions, please let us know):
> 
> 1. Have either a status check or use the "Rebase and Merge" policy for pull 
> requests
> to disallow merge commits.  Disable direct pushes to the master branch and 
> update the
> git-llvm script to create a pull request when a developer does `git llvm 
> push` and
> then have it automatically merged if there are no merge commits.
> 
> 2. Enforce no merge commits for pull requests, but sill allow developers to 
> push directly
> to master without checking for merge requests.  This is essentially a best 
> effort
> approach where we avoid having to implement our own custom work-flow for 
> committing,
> while accepting the possibility that someone might accidentally push a merge 
> commit.
> 
> 3. Disable direct pushes to master, don't update the git-llvm script and 
> require all
> developers to use pull requests, where this policy will be enforced.
> 
> Which option do you prefer?
> 

Thanks everyone for responding to this thread.  Based on the responses,
the preferred solution is none of these options and instead having a
server-side check to prevent merge commits.  I have been in contact with someone
at GitHub who is looking into this for us to see if this would be possible.

As a backup plan, I am going to look into implementing option #1, but instead
of having git-llvm create a pull request, it would push first to a staging
branch and then push to master if a 'no-merge commit' status checks pass.  This
is essentially the same flow as using pull requests, but without all the
pull request noise.

The reason to go #1 as a backup is that it preserves the status quo we have now
where developers commit using git-llvm and based on the limited feedback seems
like the preferred option of these 3.

- Tom 

> -Tom
> 
> [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 7.1.0-final has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've just tagged LLVM 7.1.0-final.  Testers, please upload the final binaries.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 8.0.1 Release Schedule

[Tom Stellard via lldb-dev]

Hi,

Here is the proposed release schedule for 8.0.1:

May 16:  -rc1
June 6:  -rc2
June 20: -final release

If there are no objections, I will post this on the website.  If you would
like to propose a fix for the 8.0.1 release, please file a bug and put
release-8.0.1 in the 'Blocks' field.  If you need a patch backported, you
can also use the merge-request.sh helper script in llvm/utils/release.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Last call for bug fixes for the 8.0.1 release

[Tom Stellard via lldb-dev]

Hi,

I'm planning to do 8.0.1-rc2 before the end of the week.  If you have any fixes
you want to get into the release let me know before then.  After -rc2, I won't
be accepting any new fixes unless they are critical.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Last call for bug fixes for the 8.0.1 release

[Tom Stellard via lldb-dev]

On 06/05/2019 11:41 AM, Tom Stellard wrote:
> Hi,
> 
> I'm planning to do 8.0.1-rc2 before the end of the week.  If you have any 
> fixes
> you want to get into the release let me know before then.  After -rc2, I won't
> be accepting any new fixes unless they are critical.
> 

Update: I'm still waiting to hear back from code owners on a few bugs, so
I'm going to delay -rc2 until Monday.

-Tom

> -Tom
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 8.0.1-rc2 has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged the 8.0.1-rc2 release, testers please begin testing and upload your
binaries.

There are still a few more bug fixes that I need to merge, so
I'm planning to do one more release candidate before 8.0.1-final.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 8.0.1-rc3

[Tom Stellard via lldb-dev]

Hi,

I've just tagged LLVM 8.0.1-rc3.  Testers, please begin testing and report
results.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] 8.0.1-rc4 release has been tagged.

[Tom Stellard via lldb-dev]

Hi,

I've tagged the 8.0.1-rc4 release, please begin testing.  This will (hopefully)
be the last release candidate.  If all goes well, I will tag the final release
next Wednesday.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[Tom Stellard via lldb-dev]

Hi,

We are still on track to retire SVN and complete the transition to GitHub
by Oct 21, 2019 (This year's US Dev Meeting).

Even though this 3+ months away, it is very important that you begin to migrate
your workflows to GitHub as soon as possible.  For developers, this means using
the git-llvm script to commit changes and for CI systems or other read-only use
cases can begin fetching code directly from GitHub.

I have created a migration status page, so you can track the progress of the 
migration:
http://llvm.org/GitHubMigrationStatus.html  There is also a link to 
instructions for
how to use the git-llvm script for committing changes.

If you would like to help with any of the TODOs on that page, please comment on 
the
bugzilla associated with the task.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[Tom Stellard via lldb-dev]

On 07/12/2019 10:29 AM, paul.robin...@sony.com wrote:
> Hi Tom,
> 
> Thanks for driving this!  It's a big project and it's great to see
> the progress being made on it. My org's adaptation to the monorepo
> is in progress as we speak.
> 
> I had two hopefully easy questions.
> 1) Can we get a link to the status page from the llvm.org front page?
>That will make it a lot easier to find in the future.

Sure, I just added a link.

> 2) I assume everyone will need to have a GitHub account; is there any
>story needing to be told about correlating a GitHub account with
>our current SVN IDs?  I don't even have a GH account at this point,
>don't know what's involved in signing up.

We are still working on a process for mapping SVN accounts to GitHub accounts.
I will provide an update once we have something finalized.

-Tom

> 
> Thanks,
> --paulr
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] 8.0.1-rc4 release has been tagged.

[Tom Stellard via lldb-dev]

On 07/15/2019 05:40 PM, Brian Cain wrote:
> I noticed tests that didn't terminate on ubuntu-14.04 x86_64.  Is PR40761 
> gating this release?
> 

We weren't able to get a fix for that unfortunately.

-Tom
> On Fri, Jul 12, 2019 at 2:21 PM Dimitry Andric via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> 
> On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers 
> mailto:release-test...@lists.llvm.org>> 
> wrote:
> >
> > I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> > be the last release candidate.  If all goes well, I will tag the final 
> release
> > next Wednesday.
> 
> As with 8.0.1 rc3, I had to disable compiler-rt for this test run, as 
> most of the sanitizers are totally broken. This is tracked in PR40761.
> 
> Main test results on amd64-freebsd11:
> 
> Expected Passes: 53262 (rc3: 53266)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   213 (rc3:   213)
> Unsupported Tests  :  1718 (rc3:  1718)
> Unresolved Tests   : 8 (rc3: 8)
> Unexpected Passes  : 3 (rc3: 3)
> Unexpected Failures:62 (rc3:59)
> 
> Main test results on i386-freebsd11:
> 
> Expected Passes: 53114 (rc3: 53113)
> Passes With Retry  : 1 (rc3: 0)
> Expected Failures  :   229 (rc3:   229)
> Unsupported Tests  :  1540 (rc3:  1540)
> Unresolved Tests   : 8 (rc3: 7)
> Unexpected Passes  : 5 (rc3: 5)
> Unexpected Failures:   175 (rc3:   178)
> 
> Uploaded:
> 
> SHA256 (clang+llvm-8.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
> ffd4546aab6d7944b4063a8fd9f4022be8b4904760becc76ee2ea64d3fa50d7e
> SHA256 (clang+llvm-8.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
> 52ab6fa940a4143c1ac2fc50f2aa0994b92a56fbf7d8b1146b74a7c5de743607
> 
> -Dimitry
> 
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> 
> 
> 
> -- 
> -Brian

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] 8.0.1-final has been tagged

[Tom Stellard via lldb-dev]

Hi,

The 8.0.1 final release has been tagged.  Testers please upload the final
binaries.

-Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Instructions for requesting GitHub commit access

[Tom Stellard via lldb-dev]

Hi,

I've created a text file[1] in the SVN repository that developers can
update in order to request commit access to the GitHub repository. 
All you need to do is add a line in the form of
$SVN_USERNAME:$GITHUB_USERNAME

Please add your information to this file before SVN becomes readonly 
on October 21 to avoid a gap in commit access.  More details can be found in
the phabriactor review[2] that updates the developer policy.

We will be verifying that the svn committer matches the username in the
file, so you can only request access for yourself and not someone else

Thanks,
Tom

[1] 
https://llvm.org/viewvc/llvm-project/meta/trunk/github-usernames.txt?view=markup
[2] https://reviews.llvm.org/D66840
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [llvm-dev] [cfe-dev] Instructions for requesting GitHub commit access

[Tom Stellard via lldb-dev]

On 09/04/2019 07:19 AM, via Openmp-dev wrote:
> 
> 
>> -Original Message-
>> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of David
>> Zarzycki via llvm-dev
>> Sent: Wednesday, September 04, 2019 8:07 AM
>> To: David Greene
>> Cc: llvm-dev; LLDB Dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org)
>> Subject: Re: [llvm-dev] [cfe-dev] [Openmp-dev] Instructions for requesting
>> GitHub commit access
>>
>> One is expected to use `git llvm push`. For more information, please see:
>>
>> https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-
>> changes-from-git
> 
> FTR, that page is written to describe the current situation (with the
> git-to-svn loop behind the scenes), and doesn't say anything about what
> happens after the changeover.
> 
> https://bugs.llvm.org/show_bug.cgi?id=42430 does suggest that we will 
> keep using `git llvm push` after the changeover, and it will just do
> different things (like guaranteeing no merge commits get pushed).
> --paulr
> 

This is correct, we will continue to use `git llvm push` after transitioning
to GitHub.

-Tom

>>
>>
>>> On Sep 3, 2019, at 7:06 PM, David Greene via cfe-dev > d...@lists.llvm.org> wrote:
>>>
>>> What is the expected way to do commits?  Do we push directly to master
>>> after a rebase?  I know there has been talk of using GitHub pull
>>> requests and I would be in favor of that.  What's the status of those
>>> discussions?
>>>
>>>   -David
>>>
>>> Tom Stellard via Openmp-dev  writes:
>>>
 Hi,

 I've created a text file[1] in the SVN repository that developers can
 update in order to request commit access to the GitHub repository.
 All you need to do is add a line in the form of
 $SVN_USERNAME:$GITHUB_USERNAME

 Please add your information to this file before SVN becomes readonly
 on October 21 to avoid a gap in commit access.  More details can be
>> found in
 the phabriactor review[2] that updates the developer policy.

 We will be verifying that the svn committer matches the username in the
 file, so you can only request access for yourself and not someone else

 Thanks,
 Tom

 [1] https://llvm.org/viewvc/llvm-project/meta/trunk/github-
>> usernames.txt?view=markup
 [2] https://reviews.llvm.org/D66840
 ___
 Openmp-dev mailing list
 openmp-...@lists.llvm.org
 https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

Hi,

We're less than 2 weeks away from the developer meeting, so I wanted to
give an update on the GitHub migration and what's (hopefully) going to
happen during the developer meeting.

Everyone who has added their information to the github-usernames.txt
file in SVN before today should have received an invite to become a collaborator
on the llvm-project repository.  If you did not receive an invite and think
you should have, please contact me off-list.  I will continue to monitor the
file for new updates and periodically send out new batches of invites.

There is still some ongoing work to get the buildbots ready and the mailing 
lists
ready, but we are optimistic that the work will be done in time.

The team at GitHub has finished implementing the "Require Linear History"
branch protection that we requested.  The feature is in beta and currently
enabled in the llvm-project repository.  This means that we will have the
option to commit directly via git, in addition to using the git-llvm script.
A patch that updates git-llvm to push to git instead of svn can be found here:
https://reviews.llvm.org/D67772.  You should be able to test it out on your
own fork of the llvm-project repository.

The current plan is to begin the final migration steps on the evening (PDT)
of October 21.  Here is what will happen:

1. Make SVN read-only.
2. Turn-off the SVN->git update process.
3. Commit the new git-llvm script directly to github.
4. Grant all contributors write access to the repository.
5. Email lists announcing that the migration is complete.

Once the migration is complete, if you run into any issues, please file
a bug, and mark it as a blocker for the github metabug PR39393.

If you have any questions or think I am missing something, please
let me know.

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/09/2019 10:16 PM, Tom Stellard via Openmp-dev wrote:
> Hi,
> 
> We're less than 2 weeks away from the developer meeting, so I wanted to
> give an update on the GitHub migration and what's (hopefully) going to
> happen during the developer meeting.
> 
> Everyone who has added their information to the github-usernames.txt
> file in SVN before today should have received an invite to become a 
> collaborator
> on the llvm-project repository.  If you did not receive an invite and think
> you should have, please contact me off-list.  I will continue to monitor the
> file for new updates and periodically send out new batches of invites.
> 

It seems like not everyone received email notifications of the invites
(it may depend on your settings).  You should be able to see your invite
if you go to https://github.com/llvm/llvm-project/invitations.

-Tom

> There is still some ongoing work to get the buildbots ready and the mailing 
> lists
> ready, but we are optimistic that the work will be done in time.
> 
> The team at GitHub has finished implementing the "Require Linear History"
> branch protection that we requested.  The feature is in beta and currently
> enabled in the llvm-project repository.  This means that we will have the
> option to commit directly via git, in addition to using the git-llvm script.
> A patch that updates git-llvm to push to git instead of svn can be found here:
> https://reviews.llvm.org/D67772.  You should be able to test it out on your
> own fork of the llvm-project repository.
> 
> The current plan is to begin the final migration steps on the evening (PDT)
> of October 21.  Here is what will happen:
> 
> 1. Make SVN read-only.
> 2. Turn-off the SVN->git update process.
> 3. Commit the new git-llvm script directly to github.
> 4. Grant all contributors write access to the repository.
> 5. Email lists announcing that the migration is complete.
> 
> Once the migration is complete, if you run into any issues, please file
> a bug, and mark it as a blocker for the github metabug PR39393.
> 
> If you have any questions or think I am missing something, please
> let me know.
> 
> Thanks,
> Tom
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-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] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> 
> 
> On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> We're less than 2 weeks away from the developer meeting, so I wanted to
> give an update on the GitHub migration and what's (hopefully) going to
> happen during the developer meeting.
> 
> Everyone who has added their information to the github-usernames.txt
> file in SVN before today should have received an invite to become a 
> collaborator
> on the llvm-project repository.  If you did not receive an invite and 
> think
> you should have, please contact me off-list.  I will continue to monitor 
> the
> file for new updates and periodically send out new batches of invites.
> 
> There is still some ongoing work to get the buildbots ready and the 
> mailing lists
> ready, but we are optimistic that the work will be done in time.
> 
> The team at GitHub has finished implementing the "Require Linear History"
> branch protection that we requested.  The feature is in beta and currently
> enabled in the llvm-project repository.  This means that we will have the
> option to commit directly via git, in addition to using the git-llvm 
> script.
> A patch that updates git-llvm to push to git instead of svn can be found 
> here:
> https://reviews.llvm.org/D67772.  You should be able to test it out on 
> your
> own fork of the llvm-project repository.
> 
> The current plan is to begin the final migration steps on the evening 
> (PDT)
> of October 21.  Here is what will happen:
> 
> 1. Make SVN read-only.
> 2. Turn-off the SVN->git update process.
> 3. Commit the new git-llvm script directly to github.
> 4. Grant all contributors write access to the repository.
> 
> 
> Is the repo configured to forbid contributors to create new branches? I'm 
> worried about the "jungle" it can become quickly if we leave open the 
> possibility to create branches "at will" in the repo, I rather leave this to 
> maintainers.
> 

I haven't been able to find a way to restrict branch creation for committers,
I'm not sure if this is even possible.

We could try to enforce this rule in the git-llvm script, but this would
mean making use of the script mandatory, which was our original plan, but
that was based on the assumption that the "Require Linear History"
protection would not be ready in time.

Generally, would it be better if we kept use of the script mandatory so that 
we can handle this and other potential restrictions in the future?

- Tom
>  
> 
> 5. Email lists announcing that the migration is complete.
> 
> Once the migration is complete, if you run into any issues, please file
> a bug, and mark it as a blocker for the github metabug PR39393.
> 
> If you have any questions or think I am missing something, please
> let me know.
> 
> 
> This is fantastic! Thank you so much for doing this work Tom :)
> 
> -- 
> Mehdi
> 
>  

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
> 
> 
> On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard  > wrote:
> 
> On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> >
> >
> > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > We're less than 2 weeks away from the developer meeting, so I 
> wanted to
> > give an update on the GitHub migration and what's (hopefully) going 
> to
> > happen during the developer meeting.
> >
> > Everyone who has added their information to the github-usernames.txt
> > file in SVN before today should have received an invite to become a 
> collaborator
> > on the llvm-project repository.  If you did not receive an invite 
> and think
> > you should have, please contact me off-list.  I will continue to 
> monitor the
> > file for new updates and periodically send out new batches of 
> invites.
> >
> > There is still some ongoing work to get the buildbots ready and the 
> mailing lists
> > ready, but we are optimistic that the work will be done in time.
> >
> > The team at GitHub has finished implementing the "Require Linear 
> History"
> > branch protection that we requested.  The feature is in beta and 
> currently
> > enabled in the llvm-project repository.  This means that we will 
> have the
> > option to commit directly via git, in addition to using the 
> git-llvm script.
> > A patch that updates git-llvm to push to git instead of svn can be 
> found here:
> > https://reviews.llvm.org/D67772.  You should be able to test it out 
> on your
> > own fork of the llvm-project repository.
> >
> > The current plan is to begin the final migration steps on the 
> evening (PDT)
> > of October 21.  Here is what will happen:
> >
> > 1. Make SVN read-only.
> > 2. Turn-off the SVN->git update process.
> > 3. Commit the new git-llvm script directly to github.
> > 4. Grant all contributors write access to the repository.
> >
> >
> > Is the repo configured to forbid contributors to create new branches? 
> I'm worried about the "jungle" it can become quickly if we leave open the 
> possibility to create branches "at will" in the repo, I rather leave this to 
> maintainers.
> >
> 
> I haven't been able to find a way to restrict branch creation for 
> committers,
> I'm not sure if this is even possible.
> 
> 
> I think you can just go to the branch settings, add a new branch protection 
> rule, match on everything but master, and check "Restrict who can push to 
> matching branches".
> 

I tried this, and the branch protections only come into effect after a branch
has been creating, so this doesn't prevent new branches.  It's actually worse
than doing nothing, because once the branch is created the branch protection
prevents you from deleting it.

-Tom

>  
> 
> We could try to enforce this rule in the git-llvm script, but this would
> mean making use of the script mandatory, which was our original plan, but
> that was based on the assumption that the "Require Linear History"
> protection would not be ready in time.
> 
> Generally, would it be better if we kept use of the script mandatory so 
> that
> we can handle this and other potential restrictions in the future?
> 
> - Tom
> > 
> >
> > 5. Email lists announcing that the migration is complete.
> >
> > Once the migration is complete, if you run into any issues, please 
> file
> > a bug, and mark it as a blocker for the github metabug PR39393.
> >
> > If you have any questions or think I am missing something, please
> > let me know.
> >
> >
> > This is fantastic! Thank you so much for doing this work Tom :)
> >
> > --
> > Mehdi
> >
> > 
> 

___
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] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/10/2019 03:50 PM, Mehdi AMINI wrote:
> 
> 
> On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht  > wrote:
> 
> 
> 
> On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> 
> On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
> >
> >
> > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard    >> wrote:
> >
> > On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> > >
> > >
> > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> > 
>  
>  > >
> > > Hi,
> > >
> > > We're less than 2 weeks away from the developer meeting, 
> so I wanted to
> > > give an update on the GitHub migration and what's 
> (hopefully) going to
> > > happen during the developer meeting.
> > >
> > > Everyone who has added their information to the 
> github-usernames.txt
> > > file in SVN before today should have received an invite 
> to become a collaborator
> > > on the llvm-project repository.  If you did not receive 
> an invite and think
> > > you should have, please contact me off-list.  I will 
> continue to monitor the
> > > file for new updates and periodically send out new 
> batches of invites.
> > >
> > > There is still some ongoing work to get the buildbots 
> ready and the mailing lists
> > > ready, but we are optimistic that the work will be done 
> in time.
> > >
> > > The team at GitHub has finished implementing the "Require 
> Linear History"
> > > branch protection that we requested.  The feature is in 
> beta and currently
> > > enabled in the llvm-project repository.  This means that 
> we will have the
> > > option to commit directly via git, in addition to using 
> the git-llvm script.
> > > A patch that updates git-llvm to push to git instead of 
> svn can be found here:
> > > https://reviews.llvm.org/D67772.  You should be able to 
> test it out on your
> > > own fork of the llvm-project repository.
> > >
> > > The current plan is to begin the final migration steps on 
> the evening (PDT)
> > > of October 21.  Here is what will happen:
> > >
> > > 1. Make SVN read-only.
> > > 2. Turn-off the SVN->git update process.
> > > 3. Commit the new git-llvm script directly to github.
> > > 4. Grant all contributors write access to the repository.
> > >
> > >
> > > Is the repo configured to forbid contributors to create new 
> branches? I'm worried about the "jungle" it can become quickly if we leave 
> open the possibility to create branches "at will" in the repo, I rather leave 
> this to maintainers.
> > >
> >
> > I haven't been able to find a way to restrict branch creation 
> for committers,
> > I'm not sure if this is even possible.
> >
> >
> > I think you can just go to the branch settings, add a new branch 
> protection rule, match on everything but master, and check "Restrict who can 
> push to matching branches".
> >
> 
> I tried this, and the branch protections only come into effect after 
> a branch
> has been creating, so this doesn't prevent new branches.  It's 
> actually worse
> than doing nothing, because once the branch is created the branch 
> protection
> prevents you from deleting it.
> 
> 
> Ah, interesting :)
> Since for now `git-llvm` is necessary to push to the repo, I guess creating a 
> branch won't even really be possible? So when adding the support for branch 
> creation to `git-llvm` we could print a disclaimer about it or something?
> 

With my latest changes in https://reviews.llvm.org/D67772 it is actually 
possible
to create a new branch with git-llvm, so we could print a disclaimer or block 
this,
however we still can't stop people from creating a new branch using the
normal git command.

-Tom

> 
> 
> -Tom
> 
> 
> FWIW, we're interested in periodically (weekly) tagging 
> well-tested/stable revisions, but via a branch instead of just a tag so we 
> can include which cherrypicks (e.g. reverts or fixes) are needed. We do this 
> with the current svn repo so we'd just be porting existing functionality to 
> gi

[lldb-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

Hi,

I mentioned this in my email last week, but I wanted to start a new
thread to get everyone's input on what to do about the git-llvm script
after the GitHub migration.

The original plan was to require the use of the git-llvm script when
committing to GitHub even after the migration was complete.
The reason we decided to do this was so that we could prevent developers
from accidentally pushing merge commits and making the history non-linear.

Just in the last week, the GitHub team completed the "Require Linear
History" branch protection, which means we can now enforce linear
history server side and do not need the git-llvm script to do this.

With this new development, the question I have is when should the
git-llvm script become optional?  Should we make it optional immediately,
so that developers can push directly using vanilla git from day 1, or should we
wait a few weeks/months until things have stabilized to make it optional?

Thanks,
Tom




 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

On 10/15/2019 12:20 AM, Roman Lebedev wrote:
> On Tue, Oct 15, 2019 at 10:14 AM Tom Stellard via cfe-dev
>  wrote:
>>
>> Hi,
>>
>> I mentioned this in my email last week, but I wanted to start a new
>> thread to get everyone's input on what to do about the git-llvm script
>> after the GitHub migration.
>>
>> The original plan was to require the use of the git-llvm script when
>> committing to GitHub even after the migration was complete.
>> The reason we decided to do this was so that we could prevent developers
>> from accidentally pushing merge commits and making the history non-linear.
>>
>> Just in the last week, the GitHub team completed the "Require Linear
>> History" branch protection, which means we can now enforce linear
>> history server side and do not need the git-llvm script to do this.
> 
> What about prevention of new branch creation?
> From the bugzilla disscussion, i gather that is not possible to do via github?
> 

Correct, but the git-llvm script can only prevent people from creating new
branches if they use the script.  Someone could still create a new branch
using `git push`.   We can use branch protections to prevent pushing to
existing branches but not for preventing new ones.

-Tom



>> With this new development, the question I have is when should the
>> git-llvm script become optional?  Should we make it optional immediately,
>> so that developers can push directly using vanilla git from day 1, or should 
>> we
>> wait a few weeks/months until things have stabilized to make it optional?
>>
>> Thanks,
>> Tom
> Roman
> 
>> ___
>> 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] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

On 10/15/2019 11:51 AM, Lei Huang wrote:
> On 10/15/2019 12:20 AM, Roman Lebedev wrote:
>> On Tue, Oct 15, 2019 at 10:14 AM Tom Stellard via cfe-dev
>>  wrote:
>>>
>>> Hi,
>>>
>>> I mentioned this in my email last week, but I wanted to start a new
>>> thread to get everyone's input on what to do about the git-llvm script
>>> after the GitHub migration.
>>>
>>> The original plan was to require the use of the git-llvm script when
>>> committing to GitHub even after the migration was complete.
>>> The reason we decided to do this was so that we could prevent developers
>>> from accidentally pushing merge commits and making the history non-linear.
>>>
>>> Just in the last week, the GitHub team completed the "Require Linear
>>> History" branch protection, which means we can now enforce linear
>>> history server side and do not need the git-llvm script to do this.
>>
>> What about prevention of new branch creation?
>> From the bugzilla disscussion, i gather that is not possible to do via 
>> github?
>>
> 
> Correct, but the git-llvm script can only prevent people from creating new
> branches if they use the script.  Someone could still create a new branch
> using `git push`.   We can use branch protections to prevent pushing to
> existing branches but not for preventing new ones.
> 
> -Tom
> 
> Maybe I missed something, but the git doc seem to indicate we can setup a 
> server
> side pre-receive hook.  Can we not use this to prevent users from creating a 
> new branch?
> 

GitHub only supports pre-receive hooks in their Enterprise Server edition,
which isn't a good option for us, because we would need to self-host it.

-Tom

 
> - Lei
> 
>>> With this new development, the question I have is when should the
>>> git-llvm script become optional?  Should we make it optional immediately,
>>> so that developers can push directly using vanilla git from day 1, or 
>>> should we
>>> wait a few weeks/months until things have stabilized to make it optional?
>>>
>>> Thanks,
>>> Tom
>> Roman
>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
> 
> ___
> 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

[lldb-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

Hi,

We are going to start to switching from SVN commit emails to GitHub commit
emails this week.  The only real change you should notice is that
the revision number in the subject will be replaced with a git hash and
the diff links in the email will point to GitHub.  Otherwise the
content and format of the email should be the same.

We are going to start by rolling this out for the openmp-commits list
and then once that's working begin migrating the rest of the lists.  If you
notice any issues with the new emails, please file a bug and mark it
as a blocker of the github meta-bug (llvm.org/PR39393).

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> Hi Tom.
> 
> One issue with this is that we don't have a clear "ordering" from linear 
> revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> 

This actually what we are doing, we are listening for github commit events and
then generating our own emails based on the data in the event.  We can format
the emails how ever we want, and we tried to match the current SVN format 
exactly.
Is the some other information you would like to have in the emails to show the
ordering?

-Tom

> Thanks,
> 
> -- 
> Mehdi
> 
> 
> 
> On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> We are going to start to switching from SVN commit emails to GitHub commit
> emails this week.  The only real change you should notice is that
> the revision number in the subject will be replaced with a git hash and
> the diff links in the email will point to GitHub.  Otherwise the
> content and format of the email should be the same.
> 
> We are going to start by rolling this out for the openmp-commits list
> and then once that's working begin migrating the rest of the lists.  If 
> you
> notice any issues with the new emails, please file a bug and mark it
> as a blocker of the github meta-bug (llvm.org/PR39393 
> ).
> 
> Thanks,
> Tom
> ___
> 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] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
> 
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard  > wrote:
> 
> On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> > Hi Tom.
> >
> > One issue with this is that we don't have a clear "ordering" from 
> linear revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> >
> 
> This actually what we are doing, we are listening for github commit 
> events and
> then generating our own emails based on the data in the event.  We can 
> format
> the emails how ever we want, and we tried to match the current SVN format 
> exactly.
> 
> 
> Ah great!
>  
> 
> Is the some other information you would like to have in the emails to 
> show the
> ordering?
> 
> 
> The only thing I was looking to get was to continue to have a monotonic 
> incrementing integer for the revision instead of the git hash alone: I don't 
> know if `git llvm` has this feature yet but this was discussed a while ago (I 
> don't remember if we just mentioned counting the commits in the repo from the 
> beginning or using an invocation of `git describe` or something derived).
> 

We talked about using `git describe` for this, but this would require that we
add tags to the master branch each time the version number was bumped.  We
discussed this[1] last year, but deferred the decision, since we couldn't get
consensus on the tag name.

-Tom

[1] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128484.html

> -- 
> Mehdi
> 
>  
> 
> 
> -Tom
> 
> > Thanks,
> >
> > --
> > Mehdi
> >
> >
> >
> > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > We are going to start to switching from SVN commit emails to GitHub 
> commit
> > emails this week.  The only real change you should notice is that
> > the revision number in the subject will be replaced with a git hash 
> and
> > the diff links in the email will point to GitHub.  Otherwise the
> > content and format of the email should be the same.
> >
> > We are going to start by rolling this out for the openmp-commits 
> list
> > and then once that's working begin migrating the rest of the lists. 
>  If you
> > notice any issues with the new emails, please file a bug and mark it
> > as a blocker of the github meta-bug (llvm.org/PR39393 
>  ).
> >
> > Thanks,
> > Tom
> > ___
> > 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] [llvm-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 07:31 AM, Roman Lebedev wrote:
> +1, please.
> 
> Also, putting a tag on the *first* commit in the repo,
> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
> 

Do we need to add a tag or is `git rev-list --count HEAD`
good enough?

-Tom


> Roman.
> 
> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
>  wrote:
>>
>> +1.  And put it in the email (subject?).  While it’s possible to derive a 
>> count from a hash manually, better to have it in the email in the first 
>> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
>>
>> --paulr
>>
>>
>>
>> From: llvm-dev  On Behalf Of Shoaib Meenai 
>> via llvm-dev
>> Sent: Wednesday, October 16, 2019 1:42 AM
>> To: tstel...@redhat.com; Mehdi AMINI 
>> Cc: llvm-dev ; cfe-dev ; 
>> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
>> 
>> Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
>>
>>
>>
>> I thought we were just going to count commits on a particular branch and use 
>> the (branch name, commit count) tuple as our monotonic incrementing 
>> identifier? 
>> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>>
>>
>>
>>
>>
>> From: cfe-dev  on behalf of cfe-dev 
>> 
>> Organization: Red Hat
>> Reply-To: "tstel...@redhat.com" 
>> Date: Tuesday, October 15, 2019 at 10:13 PM
>> To: Mehdi AMINI 
>> Cc: llvm-dev , cfe-dev , 
>> "openmp-dev (openmp-...@lists.llvm.org)" , LLDB 
>> Dev 
>> Subject: Re: [cfe-dev] Mailing list changes this week
>>
>>
>>
>> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>>
>> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard > > wrote:
>>
>>  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>>
>>  > Hi Tom.
>>
>>  >
>>
>>  > One issue with this is that we don't have a clear "ordering" from 
>> linear revision numbers from these emails. Have we looked into continuing to 
>> generate our own emails per commits instead so that we control the format?
>>
>>  >
>>
>>  This actually what we are doing, we are listening for github commit 
>> events and
>>
>>  then generating our own emails based on the data in the event.  We can 
>> format
>>
>>  the emails how ever we want, and we tried to match the current SVN 
>> format exactly.
>>
>> Ah great!
>>
>>
>>
>>  Is the some other information you would like to have in the emails to 
>> show the
>>
>>  ordering?
>>
>> The only thing I was looking to get was to continue to have a monotonic 
>> incrementing integer for the revision instead of the git hash alone: I don't 
>> know if `git llvm` has this feature yet but this was discussed a while ago 
>> (I don't remember if we just mentioned counting the commits in the repo from 
>> the beginning or using an invocation of `git describe` or something derived).
>>
>>
>>
>> We talked about using `git describe` for this, but this would require that we
>>
>> add tags to the master branch each time the version number was bumped.  We
>>
>> discussed this[1] last year, but deferred the decision, since we couldn't get
>>
>> consensus on the tag name.
>>
>>
>>
>> -Tom
>>
>>
>>
>> [1] 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
>>
>>
>>
>> --
>>
>> Mehdi
>>
>>
>>
>>  -Tom
>>
>>  > Thanks,
>>
>>  >
>>
>>  > --
>>
>>  > Mehdi
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
>> mailto:cfe-...@lists.llvm.org> 
>> >> wrote:
>>
>>  >
>>
>>  > Hi,
>>
>>  >
>>
>>  > We are going to start to switching from SVN commit emails to 
>> GitHub commit
>>
>>  > emails this week.  The only real change you should notice is that
>>
>>  > the revision number in the subject will be replaced with a git 
>> hash and
>>
>>  > the diff links in the email will point to GitHub.  Otherwise the
>>
>>  > content and format of the email should be the same.
>>
>>  >
>>
>>  > We are going to start by rolling this out for the openmp-commits 
>> list
>>
>>  > and then once that's working begin migrating the rest of the 
>> lists.  If you
>>
>>  > notice any issues with the new emails, please file a bug and mark 
>> it
>>
>>  > as a blocker of the github meta-bug (llvm.org/PR39393 
>> >  > 
>> 

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 12:02 PM, Roman Lebedev wrote:
> On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard  wrote:
>>
>> On 10/16/2019 07:31 AM, Roman Lebedev wrote:
>>> +1, please.
>>>
>>> Also, putting a tag on the *first* commit in the repo,
>>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
>>>
>>
>> Do we need to add a tag or is `git rev-list --count HEAD`
>> good enough?
> Ah, interesting, that works too, better than nothing.
> But to be noted that number is different from the `llvm-svn: <>` for
> the current commit.
> 

This is expected.  There were a few commits that were filtered
out in the SVN to git conversion:

https://github.com/jyknight/llvm-git-migration/blob/master/llvm-svn2git-monorepo.rules

-Tom

>> -Tom
> Roman
> 
>>> Roman.
>>>
>>> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
>>>  wrote:

 +1.  And put it in the email (subject?).  While it’s possible to derive a 
 count from a hash manually, better to have it in the email in the first 
 place.  You can’t rely on order-of-email-delivery to reflect 
 order-of-commit.

 --paulr



 From: llvm-dev  On Behalf Of Shoaib 
 Meenai via llvm-dev
 Sent: Wednesday, October 16, 2019 1:42 AM
 To: tstel...@redhat.com; Mehdi AMINI 
 Cc: llvm-dev ; cfe-dev ; 
 openmp-dev (openmp-...@lists.llvm.org) ; LLDB 
 Dev 
 Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week



 I thought we were just going to count commits on a particular branch and 
 use the (branch name, commit count) tuple as our monotonic incrementing 
 identifier? 
 https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git





 From: cfe-dev  on behalf of cfe-dev 
 
 Organization: Red Hat
 Reply-To: "tstel...@redhat.com" 
 Date: Tuesday, October 15, 2019 at 10:13 PM
 To: Mehdi AMINI 
 Cc: llvm-dev , cfe-dev , 
 "openmp-dev (openmp-...@lists.llvm.org)" , LLDB 
 Dev 
 Subject: Re: [cfe-dev] Mailing list changes this week



 On 10/15/2019 09:44 PM, Mehdi AMINI wrote:

 On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard >>> > wrote:

  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:

  > Hi Tom.

  >

  > One issue with this is that we don't have a clear "ordering" from 
 linear revision numbers from these emails. Have we looked into continuing 
 to generate our own emails per commits instead so that we control the 
 format?

  >

  This actually what we are doing, we are listening for github commit 
 events and

  then generating our own emails based on the data in the event.  We 
 can format

  the emails how ever we want, and we tried to match the current SVN 
 format exactly.

 Ah great!



  Is the some other information you would like to have in the emails to 
 show the

  ordering?

 The only thing I was looking to get was to continue to have a monotonic 
 incrementing integer for the revision instead of the git hash alone: I 
 don't know if `git llvm` has this feature yet but this was discussed a 
 while ago (I don't remember if we just mentioned counting the commits in 
 the repo from the beginning or using an invocation of `git describe` or 
 something derived).



 We talked about using `git describe` for this, but this would require that 
 we

 add tags to the master branch each time the version number was bumped.  We

 discussed this[1] last year, but deferred the decision, since we couldn't 
 get

 consensus on the tag name.



 -Tom



 [1] 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=



 --

 Mehdi



  -Tom

  > Thanks,

  >

  > --

  > Mehdi

  >

  >

  >

  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
 mailto:cfe-...@lists.llvm.org> 
 >> wrote:

  >

  > Hi,

  >

  > We are going to start to switching from SVN commit emails to 
 GitHub commit

  > emails this week.  The only real change you should notice is 
 that

  > the revision number in the subject will be replaced with a git 
 hash and

  > the diff links in the email will point to GitHub.  Otherwise the

  > conte

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> +1.  And put it in the email (subject?).  While it’s possible to derive a 
> count from a hash manually, better to have it in the email in the first 
> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
> 

I spent some time today looking into what it would take to add the commit
number into the email.  Implementing this will add some extra complexity to the
emailer script and add another point of failure for us.  We also
can't guarantee to always have it since at some point we may want to start using
github's standard commit emails.

I think we should just wait and see how things go without having 
a commit number in the email.  It's easy to generate the number
locally from a git hash if needed.  If it becomes a major inconvenience
to not have it in the email, we can always look at adding it in later.

-Tom

> --paulr
> 
>  
> 
> *From:* llvm-dev  *On Behalf Of *Shoaib 
> Meenai via llvm-dev
> *Sent:* Wednesday, October 16, 2019 1:42 AM
> *To:* tstel...@redhat.com; Mehdi AMINI 
> *Cc:* llvm-dev ; cfe-dev ; 
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
> 
> *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
>  
> 
> I thought we were just going to count commits on a particular branch and use 
> the (branch name, commit count) tuple as our monotonic incrementing 
> identifier? 
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
> 
>  
> 
>  
> 
> *From: *cfe-dev  > on behalf of cfe-dev 
> mailto:cfe-...@lists.llvm.org>>
> *Organization: *Red Hat
> *Reply-To: *"tstel...@redhat.com " 
> mailto:tstel...@redhat.com>>
> *Date: *Tuesday, October 15, 2019 at 10:13 PM
> *To: *Mehdi AMINI mailto:joker@gmail.com>>
> *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org>>, 
> cfe-dev mailto:cfe-...@lists.llvm.org>>, "openmp-dev 
> (openmp-...@lists.llvm.org )" 
> mailto:openmp-...@lists.llvm.org>>, LLDB Dev 
> mailto:lldb-dev@lists.llvm.org>>
> *Subject: *Re: [cfe-dev] Mailing list changes this week
> 
>  
> 
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard    
> > wrote:
> 
>  On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> 
>  > Hi Tom.
> 
>  >
> 
>  > One issue with this is that we don't have a clear "ordering" from 
> linear revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> 
>  >
> 
>  This actually what we are doing, we are listening for github commit 
> events and
> 
>  then generating our own emails based on the data in the event.  We 
> can format
> 
>  the emails how ever we want, and we tried to match the current SVN 
> format exactly.
> 
> Ah great!
> 
>   
> 
>  Is the some other information you would like to have in the emails 
> to show the
> 
>  ordering?
> 
> The only thing I was looking to get was to continue to have a monotonic 
> incrementing integer for the revision instead of the git hash alone: I don't 
> know if `git llvm` has this feature yet but this was discussed a while ago (I 
> don't remember if we just mentioned counting the commits in the repo from the 
> beginning or using an invocation of `git describe` or something derived).
> 
>  
> 
> We talked about using `git describe` for this, but this would require that we
> 
> add tags to the master branch each time the version number was bumped.  We
> 
> discussed this[1] last year, but deferred the decision, since we couldn't get
> 
> consensus on the tag name.
> 
>  
> 
> -Tom
> 
>  
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ&s=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg&e=
> 
>  
> 
> -- 
> 
> Mehdi
> 
>   
> 
>  -Tom
> 
>  > Thanks,
> 
>  >
> 
>  > --
> 
>  > Mehdi
> 
>  >
> 
>  >
> 
>  >
> 
>  > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
>   > > wrote:
> 
>  >
> 
>  > Hi,
> 
>  >
> 
>  > We are going to start to switching from SVN commit emails to 
> GitHub commit
> 
>  > emails this week.  The only real change you should notice is 
> that
> 
>  > the revision number in the subject will be replaced with a git 
> hash and
> 
>  > the diff links in the email will poin

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/16/2019 05:51 PM, Mehdi AMINI wrote:
> 
> 
> On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard  > wrote:
> 
> On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> > +1.  And put it in the email (subject?).  While it’s possible to derive 
> a count from a hash manually, better to have it in the email in the first 
> place.  You can’t rely on order-of-email-delivery to reflect order-of-commit.
> >
> 
> I spent some time today looking into what it would take to add the commit
> number into the email.  Implementing this will add some extra complexity 
> to the
> emailer script and add another point of failure for us.  We also
> can't guarantee to always have it since at some point we may want to 
> start using
> github's standard commit emails.
> 
> I think we should just wait and see how things go without having
> a commit number in the email.  It's easy to generate the number
> locally from a git hash if needed.  If it becomes a major inconvenience
> to not have it in the email, we can always look at adding it in later.
> 
> 
> Having to get an up-to-date local clone and run commands to be able to reason 
> about the logical relationship between commits (does this build failure email 
> from a slow bot comes from before or after I landed my revert?) seems to me 
> like a non-trivial workflow regression. I would personally be OK to increase 
> the tooling complexity to preserve this.
> 

There are other ways to solve this, though, for example we could have
the bots pass/fail the status checks for commits, so you could answer
the question just by clicking the link in the email and looking at
which checks have passed or failed.  And I think overall this would
be better than what we have now.

I think there may be other cases like this were problems solved using
the commit numbers may be able to be solved in different and better ways.
Part of the reason to move to GitHub is to be able to take advantage
of features like this, and I think continuing to use the commit numbers
may hold us back a little from trying new things.

> The best way to prove or disprove this is likely do what you suggest though, 
> and live through this for some time :)
> 

Right, and I'm not sure we would even be able to get the changes done in
time for the switch over anyway.

-Tom

> -- 
> Mehdi
> 
> 
> 
>  
> 
> 
> -Tom
> 
> > --paulr
> >
> > 
> >
> > *From:* llvm-dev  > *On Behalf Of *Shoaib Meenai via 
> llvm-dev
> > *Sent:* Wednesday, October 16, 2019 1:42 AM
> > *To:* tstel...@redhat.com ; Mehdi AMINI 
> mailto:joker@gmail.com>>
> > *Cc:* llvm-dev  >; cfe-dev  >; openmp-dev (openmp-...@lists.llvm.org 
> )  >; LLDB Dev  >
> > *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> >
> > 
> >
> > I thought we were just going to count commits on a particular branch 
> and use the (branch name, commit count) tuple as our monotonic incrementing 
> identifier? 
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
> >
> > 
> >
> > 
> >
> > *From: *cfe-dev   
>  >> on behalf of cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >>
> > *Organization: *Red Hat
> > *Reply-To: *"tstel...@redhat.com  
> >" 
> mailto:tstel...@redhat.com>  >>
> > *Date: *Tuesday, October 15, 2019 at 10:13 PM
> > *To: *Mehdi AMINI mailto:joker@gmail.com> 
> >>
> > *Cc: *llvm-dev    >>, cfe-dev    >>, "openmp-dev (openmp-...@lists.llvm.org 
>   >)"    >>, LLDB Dev    >>
> > *Subject: *Re: [cfe-dev] Mailing list changes this week
> >
> > 
> >
> > On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> >
> > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard    > 

[lldb-dev] GitHub Migration Update

[Tom Stellard via lldb-dev]

Hi,

We are going to postpone the migration to Tuesday night PDT. I'll send out
another email tomorrow when we start the process.

Thanks,
Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GitHub Migration Starting Now

[Tom Stellard via lldb-dev]

Hi,

We're getting ready to start migrating to GitHub.  SVN will be moved to 
read-only now and we'll
begin the process of turning on GitHub commit access.  I'll send an email when 
we're done.

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] GitHub Migration Starting Now

[Tom Stellard via lldb-dev]

On 10/22/2019 09:08 AM, Tom Stellard via Openmp-dev wrote:
> Hi,
> 
> We're getting ready to start migrating to GitHub.  SVN will be moved to 
> read-only now and we'll
> begin the process of turning on GitHub commit access.  I'll send an email 
> when we're done.
> 

The migration is complete now.  If you have been added as a collaborator to the 
llvm-project
repo, you should be able to commit directly to git now.  The git-svn script is 
optional and should
continue to work, but you will need to supply a github user token in order to 
commit.

I still need to update the github collaborates from the list in SVN, so if
you have added your name in the last few days, you may not have commit access 
for a few more hours.

If you run into any issues, please file a bug and mark it as a blocker for the 
github meta-bug.

Thanks,
Tom


> -Tom
> 
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-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] [Openmp-dev] GitHub Migration Starting Now

[Tom Stellard via lldb-dev]

On 10/23/2019 01:57 AM, Mikael Holmén wrote:
> On Tue, 2019-10-22 at 09:57 -0700, Tom Stellard via cfe-dev wrote:
>> On 10/22/2019 09:08 AM, Tom Stellard via Openmp-dev wrote:
>>> Hi,
>>>
>>> We're getting ready to start migrating to GitHub.  SVN will be
>>> moved to read-only now and we'll
>>> begin the process of turning on GitHub commit access.  I'll send an
>>> email when we're done.
>>>
>>
>> The migration is complete now.
> 
> Did everyone stop commiting or is there something strange going on? The
> last commit I see is d052a578de from 8 hours ago.
> 
> Another question:
> 
> The build bot console
> 
>  http://lab.llvm.org:8011/console
> 
> is now sorted on git commit id which makes it a bit hard to use atm. Is
> there an issue for doing something about that?
> 

Can you file a bug for this?

-Tom

> Thanks,
> Mikael
> 
>>   If you have been added as a collaborator to the llvm-project
>> repo, you should be able to commit directly to git now.  The git-svn
>> script is optional and should
>> continue to work, but you will need to supply a github user token in
>> order to commit.
>>
>> I still need to update the github collaborates from the list in SVN,
>> so if
>> you have added your name in the last few days, you may not have
>> commit access for a few more hours.
>>
>> If you run into any issues, please file a bug and mark it as a
>> blocker for the github meta-bug.
>>
>> Thanks,
>> Tom
>>
>>
>>> -Tom
>>>
>>> ___
>>> Openmp-dev mailing list
>>> openmp-...@lists.llvm.org
>>>
> https://protect2.fireeye.com/v1/url?k=50544e46-0c8045f8-50540edd-86742d02e7e2-96dccc982e4dd0fc&q=1&e=1c901fd6-5221-4af3-a0ab-4a124a098487&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenmp-dev
>>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>>
> https://protect2.fireeye.com/v1/url?k=a2f27696-fe267d28-a2f2360d-86742d02e7e2-ee8f0271cf8b963f&q=1&e=1c901fd6-5221-4af3-a0ab-4a124a098487&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GitHub committers moving from Collaborators to Team Members

[Tom Stellard via lldb-dev]

Hi,

I just sent out invites to all current LLVM 'Collaborators' on GitHub
inviting them to be 'Team Members'.  As 'Team Members', it will be much
easier for us to manage permissions across the entire group of committers.
Unfortunately, we can't just directly move people, so you will have to accept
the invitation in order to become a 'Team Member.

If you did not get a new invite, it might mean that you are already a 'Team 
Member',
you can check here: https://github.com/orgs/llvm/people to see if you've already
been added.

Also, if you were an SVN committer and you still need commit access, please
email me off list with your svn and github IDs, and I'll get you added.

Thanks,
Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Tom Stellard via lldb-dev]

+ lldb-dev

On 10/28/2019 07:06 AM, Tom Stellard wrote:
> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
>> Hi everyone,
>>
>> I have lldb crashing since I've updated to lldb9. Seems like there is a 
>> issue with python3.5. Everything seems to work fine with python3.7.
>> Am I missing something? Or is it a known issue?
>>
> 
> We have seen this too with python 3.6, but we haven't found the root cause 
> yet.
> For now, we've worked around this by disabling the readline module with the
> attached patch.
> 
> -Tom
> 
>> $ lldb
>> (lldb) script
>>  #0 0x7f3d324c9c2a llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bfc2a)
>>  #1 0x7f3d324c7af5 llvm::sys::RunSignalHandlers() 
>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdaf5)
>>  #2 0x7f3d324c7c0c SignalHandler(int) 
>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdc0c)
>>  #3 0x7f3d31bfe0e0 __restore_rt 
>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0)
>>  #4 0x7f3d2d18f81b PyModule_GetState 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x6881b)
>>  #5 0x7f3d230e1621 _init 
>> (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so 
>> +0x3621)
>>  #6 0x7f3d2e3dece1 rl_initialize 
>> (/usr/lib/x86_64-linux-gnu/libedit.so.2+0x1dce1)
>>  #7 0x7f3d230e1f3e _init 
>> (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so 
>> +0x3f3e)
>>  #8 0x7f3d2d32d710 _PyImport_LoadDynamicModuleWithSpec 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x206710)
>>  #9 0x7f3d2d330fe7 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x209fe7)
>> #10 0x7f3d2d198259 PyCFunction_Call 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259)
>> #11 0x7f3d2d2c8ff2 PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2)
>> #12 0x7f3d2d38b074 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>> #13 0x7f3d2d2c7adf PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf)
>> #14 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #15 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #16 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #17 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #18 0x7f3d2d38b074 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>> #19 0x7f3d2d38b153 PyEval_EvalCodeEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153)
>> #20 0x7f3d2d21e558 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0xf7558)
>> #21 0x7f3d2d2faa37 PyObject_Call 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37)
>> #22 0x7f3d2d2fce1b _PyObject_CallMethodIdObjArgs 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d5e1b)
>> #23 0x7f3d2d32effa PyImport_ImportModuleLevelObject 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x207ffa)
>> #24 0x7f3d2d2cd248 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a6248)
>> #25 0x7f3d2d198279 PyCFunction_Call 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71279)
>> #26 0x7f3d2d2faa37 PyObject_Call 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37)
>> #27 0x7f3d2d389b77 PyEval_CallObjectWithKeywords 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x262b77)
>> #28 0x7f3d2d2c57cb PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x19e7cb)
>> #29 0x7f3d2d38b074 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>> #30 0x7f3d2d38b153 PyEval_EvalCodeEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153)
>> #31 0x7f3d2d2c145b PyEval_EvalCode 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x19a45b)
>> #32 0x7f3d2d2ce2cd 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a72cd)
>> #33 0x7f3d2d198259 PyCFunction_Call 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259)
>> #34 0x7f3d2d2c8ff2 PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2)
>> #35 0x7f3d2d38b074 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>> #36 0x7f3d2d2c7adf PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf)
>> #37 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #38 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>> #39 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>> (/usr/lib/x86_64-linux

Re: [lldb-dev] issue with lldb9 and python3.5

[Tom Stellard via lldb-dev]

On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> and Python 3.7. I'm sorry if we forgot that in the release notes.
> 

Is there a specific reason why 3.5 is not supported?  Is it
because of this issue?

-Tom

> On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
>  wrote:
>>
>> + lldb-dev
>>
>> On 10/28/2019 07:06 AM, Tom Stellard wrote:
>>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
>>>> Hi everyone,
>>>>
>>>> I have lldb crashing since I've updated to lldb9. Seems like there is a 
>>>> issue with python3.5. Everything seems to work fine with python3.7.
>>>> Am I missing something? Or is it a known issue?
>>>>
>>>
>>> We have seen this too with python 3.6, but we haven't found the root cause 
>>> yet.
>>> For now, we've worked around this by disabling the readline module with the
>>> attached patch.
>>>
>>> -Tom
>>>
>>>> $ lldb
>>>> (lldb) script
>>>>  #0 0x7f3d324c9c2a llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
>>>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bfc2a)
>>>>  #1 0x7f3d324c7af5 llvm::sys::RunSignalHandlers() 
>>>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdaf5)
>>>>  #2 0x7f3d324c7c0c SignalHandler(int) 
>>>> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdc0c)
>>>>  #3 0x7f3d31bfe0e0 __restore_rt 
>>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0)
>>>>  #4 0x7f3d2d18f81b PyModule_GetState 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x6881b)
>>>>  #5 0x7f3d230e1621 _init 
>>>> (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so 
>>>> <http://readline.cpython-35m-x86_64-linux-gnu.so>+0x3621)
>>>>  #6 0x7f3d2e3dece1 rl_initialize 
>>>> (/usr/lib/x86_64-linux-gnu/libedit.so.2+0x1dce1)
>>>>  #7 0x7f3d230e1f3e _init 
>>>> (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so 
>>>> <http://readline.cpython-35m-x86_64-linux-gnu.so>+0x3f3e)
>>>>  #8 0x7f3d2d32d710 _PyImport_LoadDynamicModuleWithSpec 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x206710)
>>>>  #9 0x7f3d2d330fe7 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x209fe7)
>>>> #10 0x7f3d2d198259 PyCFunction_Call 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259)
>>>> #11 0x7f3d2d2c8ff2 PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2)
>>>> #12 0x7f3d2d38b074 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>>>> #13 0x7f3d2d2c7adf PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf)
>>>> #14 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>>>> #15 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>>>> #16 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>>>> #17 0x7f3d2d2c96ad PyEval_EvalFrameEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
>>>> #18 0x7f3d2d38b074 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
>>>> #19 0x7f3d2d38b153 PyEval_EvalCodeEx 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153)
>>>> #20 0x7f3d2d21e558 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0xf7558)
>>>> #21 0x7f3d2d2faa37 PyObject_Call 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37)
>>>> #22 0x7f3d2d2fce1b _PyObject_CallMethodIdObjArgs 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d5e1b)
>>>> #23 0x7f3d2d32effa PyImport_ImportModuleLevelObject 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x207ffa)
>>>> #24 0x7f3d2d2cd248 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a6248)
>>>> #25 0x7f3d2d198279 PyCFunction_Call 
>>>> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71279)
>>>> #26 0x7f3d2d2faa37 

[lldb-dev] RFC: Using GitHub Actions for CI testing on the release/* branches

[Tom Stellard via lldb-dev]

Hi,

I would like to start using GitHub Actions[1] for CI testing on the release/*
branches.  As far as I know we don't have any buildbots listening to the
release branches, and I think GitHub Actions are a good way for us to quickly
bring-up some CI jobs there.

My proposal is to start by adding two post-commit CI jobs to the release/9.x 
branch.
One for building and testing (ninja checka-all) llvm/clang/lld on Linux,
Windows, and Mac, and another for detecting ABI changes since the 9.0.0 release.

I have already implemented these two CI jobs in my llvm-project fork on 
GitHub[2][3],
but in order to get these running in the main repository, I would need to:

1. Create a new repository in the LLVM organization called 'actions' for 
storing some custom
builds steps for our CI jobs (see [4]).
2. Commit yaml CI definitions to the .github/workflows directory in the 
release/9.x
branch.

In the future, I would also like to add buil and tests jobs for other 
sub-projects
once I am able to get those working.

In addition to being used for post-commit testing, having these CI definitions 
in the
main tree will make it easier for me (or anyone) to do pre-commit testing for 
the
release branch in a personal fork.  It will also allow me to experiment with 
some new
workflows to help make managing the releases much easier.

I think this will be a good way to test Actions in a low traffic environment to
see if they are something we would want to use for CI on the master branch.

Given that we are close to the end of the 9.0.1 cycle, unless there are any
strong objections, I would like to get this enabled by Mon Nov 18, to maximize 
its
usefulness.  Let me know what you think.

Thanks,
Tom

[1] https://github.com/features/actions
[2] 
https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621
[3] 
https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176
[4] https://github.com/tstellar/actions

___
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: Using GitHub Actions for CI testing on the release/* branches

[Tom Stellard via lldb-dev]

On 11/12/2019 10:03 AM, Jonas Devlieghere wrote:
> Hey Tom,
> 
> That sounds really useful. Would it be possible to include LLDB as
> well? We have a subset of tests (unit & lit) that can be run without
> Python/SWIG by passing LLDB_DISABLE_PYTHON=ON to CMake.
> 

I can try to add an lldb builder.  Would you be able to provide me
with the cmake arguments plus a check target where all tests are expected
to pass?

Thanks,
Tom

> Thanks,
> Jonas
> 
> On Tue, Nov 12, 2019 at 2:35 AM Hans Wennborg via cfe-dev
>  wrote:
>>
>> On Tue, Nov 12, 2019 at 1:32 AM Tom Stellard via lldb-dev
>>  wrote:
>>>
>>> Hi,
>>>
>>> I would like to start using GitHub Actions[1] for CI testing on the 
>>> release/*
>>> branches.  As far as I know we don't have any buildbots listening to the
>>> release branches, and I think GitHub Actions are a good way for us to 
>>> quickly
>>> bring-up some CI jobs there.
>>>
>>> My proposal is to start by adding two post-commit CI jobs to the 
>>> release/9.x branch.
>>> One for building and testing (ninja checka-all) llvm/clang/lld on Linux,
>>> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 
>>> release.
>>>
>>> I have already implemented these two CI jobs in my llvm-project fork on 
>>> GitHub[2][3],
>>> but in order to get these running in the main repository, I would need to:
>>>
>>> 1. Create a new repository in the LLVM organization called 'actions' for 
>>> storing some custom
>>> builds steps for our CI jobs (see [4]).
>>> 2. Commit yaml CI definitions to the .github/workflows directory in the 
>>> release/9.x
>>> branch.
>>>
>>> In the future, I would also like to add buil and tests jobs for other 
>>> sub-projects
>>> once I am able to get those working.
>>>
>>> In addition to being used for post-commit testing, having these CI 
>>> definitions in the
>>> main tree will make it easier for me (or anyone) to do pre-commit testing 
>>> for the
>>> release branch in a personal fork.  It will also allow me to experiment 
>>> with some new
>>> workflows to help make managing the releases much easier.
>>>
>>> I think this will be a good way to test Actions in a low traffic 
>>> environment to
>>> see if they are something we would want to use for CI on the master branch.
>>>
>>> Given that we are close to the end of the 9.0.1 cycle, unless there are any
>>> strong objections, I would like to get this enabled by Mon Nov 18, to 
>>> maximize its
>>> usefulness.  Let me know what you think.
>>>
>>> Thanks,
>>> Tom
>>>
>>> [1] https://github.com/features/actions
>>> [2] 
>>> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621
>>> [3] 
>>> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176
>>> [4] https://github.com/tstellar/actions
>>
>> Sounds great to me!
>> ___
>> 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

[lldb-dev] 9.0.1 Release Schedule

[Tom Stellard via lldb-dev]

Hi,

Here is the planned schedule for the 9.0.1 Release:

Nov 22: -rc1
Dec 2:  -rc2/Deadline to request backports
Dec 9:  9.0.1-final

If you want to make sure a fix makes it into the 9.0.1 release, please file
a bug at bugs.llvm.org and mark it as a blocker for the release-9.0.1 meta-bug.

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Using GitHub Actions for CI testing on the release/* branches

[Tom Stellard via lldb-dev]

On 11/11/2019 04:32 PM, Tom Stellard wrote:
> Hi,
> 
> I would like to start using GitHub Actions[1] for CI testing on the release/*
> branches.  As far as I know we don't have any buildbots listening to the
> release branches, and I think GitHub Actions are a good way for us to quickly
> bring-up some CI jobs there.
> 
> My proposal is to start by adding two post-commit CI jobs to the release/9.x 
> branch.
> One for building and testing (ninja checka-all) llvm/clang/lld on Linux,
> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 
> release.
> 
> I have already implemented these two CI jobs in my llvm-project fork on 
> GitHub[2][3],
> but in order to get these running in the main repository, I would need to:
> 
> 1. Create a new repository in the LLVM organization called 'actions' for 
> storing some custom
> builds steps for our CI jobs (see [4]).
> 2. Commit yaml CI definitions to the .github/workflows directory in the 
> release/9.x
> branch.
> 
> In the future, I would also like to add buil and tests jobs for other 
> sub-projects
> once I am able to get those working.
> 
> In addition to being used for post-commit testing, having these CI 
> definitions in the
> main tree will make it easier for me (or anyone) to do pre-commit testing for 
> the
> release branch in a personal fork.  It will also allow me to experiment with 
> some new
> workflows to help make managing the releases much easier.
> 
> I think this will be a good way to test Actions in a low traffic environment 
> to
> see if they are something we would want to use for CI on the master branch.
> 
> Given that we are close to the end of the 9.0.1 cycle, unless there are any
> strong objections, I would like to get this enabled by Mon Nov 18, to 
> maximize its
> usefulness.  Let me know what you think.
> 

The CI tests are running now on the stable branch.  Here is the
first run [1].  Passing commits[2] now have a green check mark in
the web UI that you can click on to view the results.

These tests have already caught 1 bug that did not appear in my local
builds, so they are proving to be very useful.

Now that this is in place, I'm going to start looking into some more automation
around backporting fixes to the stable branch.  I think we could do something 
like
filing backport requests as a GitHub issues and then have that issue 
automatically
trigger a pull request and do some pre-commit testing.  I'm still trying to 
learn
what is technically possible with GitHub and if anyone has any ideas or 
suggestions,
let me know.  I'm hoping to have something in place for the 10.0.1 release 
cycle.

Thanks,
Tom

[1] 
https://github.com/llvm/llvm-project/commit/6c86aa62d502ac2df58e207d4792544cc96d79bd/checks?check_suite_id=316648311
[2] 
https://github.com/llvm/llvm-project/commit/6c86aa62d502ac2df58e207d4792544cc96d79bd

> Thanks,
> Tom
> 
> [1] https://github.com/features/actions
> [2] 
> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621
> [3] 
> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176
> [4] https://github.com/tstellar/actions
> 

___
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: Using GitHub Actions for CI testing on the release/* branches

[Tom Stellard via lldb-dev]

> Hi Tom,
>
> This sounds very interesting! +1 from me.
> What does this imply for the release testers?
> Would it be possible / desirable for us to add self-hosted runners for
> other architectures? I'm assuming GitHub only provides x86, right? I
> totally missed any details about that in their docs, but it seems to
> be implied here [1]. I'm not saying we should go all-possible-arches
> from the start, we can definitely try it out only for x86 this time
> around if you think that would be the best approach.
>

Nothing changes for release testers at this point.  The main goal here is
to get some post-commit testing so we can catch issues in the branch early.

Longer term I think have self-hosted runners would be great, because it would
allow us to fully automate the testing and uploading we do when a release gets
tagged.

You are correct that GitHub only provides x86 machines, however, they don't
have enough disk space (14GB) to be able to run the test-release.sh script, so
adding x86 self-hosted builders with more disk space would still be very useful.

-Tom
 
>
> [1] 
> https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/
>
> Thanks,
> Diana

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 9.0.1-rc1 Release has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged the LLVM 9.0.1-rc1 release.  Testers can begin testing and upload
binaries.  I've also updated the test-release.sh script to pull from GitHub
instead of SVN, if you run into any issues with the new script, let me know.

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc1 Release has been tagged

[Tom Stellard via lldb-dev]

On 11/25/2019 11:35 PM, Tobias Hieta wrote:
> Hello,
> 
> I built for macOS - I can't upload via SFTP since I never got that
> access. But the build can be downloaded here:
> https://drive.google.com/file/d/1qULDWqHK5s1dHiCyS32BE2ZgxaTjlSSu/view?usp=sharing
> 
> the SHA256 is: 
> 646b0acae090d09d74c7fd4f0cb19409190d4e2ce3ddb9db4ac236f72a213c1a
> 
> I see that some people post test output - but I can't see that from
> running the test-release.sh (btw it worked fine with Git now) - is
> there something else I need to do?
> 

There should be a log file with build and test output.

-Tom

> Thanks,
> Tobias
> 
> On Sat, Nov 23, 2019 at 7:20 AM Tom Stellard via Release-testers
>  wrote:
>>
>> Hi,
>>
>> I've tagged the LLVM 9.0.1-rc1 release.  Testers can begin testing and upload
>> binaries.  I've also updated the test-release.sh script to pull from GitHub
>> instead of SVN, if you run into any issues with the new script, let me know.
>>
>> -Tom
>>
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 9.0.1-rc2 has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged LLVM 9.0.1-rc2.  Testers can begin testing and uploading binaries.
If all goes well, this will be the last -rc.

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 9.0.1-rc3 has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've just tagged LLVM 9.0.1-rc3.  Testers can begin testing and uploading
binaries.  This will be the last release candidate unless there is a
major problem.  I'm planning to tag the final release on Dec 19.

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc3 has been tagged

[Tom Stellard via lldb-dev]

On 12/16/2019 10:30 AM, Dimitry Andric wrote:
> On 14 Dec 2019, at 07:34, Tom Stellard via Release-testers 
>  wrote:
>>
>> I've just tagged LLVM 9.0.1-rc3.  Testers can begin testing and uploading
>> binaries.  This will be the last release candidate unless there is a
>> major problem.  I'm planning to tag the final release on Dec 19.
> 
> For this rc, I used two patches, from:
> 
> * https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
> Sanitizer-i386-Test faills to link on FreeBSD
> * https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
> flag for dynamic ASan tests
> 
> Uploaded:
> 
> SHA256 (clang+llvm-9.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
> 534f119f9100469899cd4d1e02c6a65f724d560e38d3d27aa99797b16379e25a
> SHA256 (clang+llvm-9.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
> 874b707b87d07e9f73021e192d935fb8b82d81d10b06af9d591204ebc865c02b
> 

Do these binaries include those patches?

-Tom

> Main test results on amd64-freebsd11:
> 
>   
>   Testing Time: 5223.66s
>   
>   Unexpected Passing Tests (6):
>   AddressSanitizer-i386-freebsd-dynamic :: 
> TestCases/interception_failure_test.cc
>   AddressSanitizer-x86_64-freebsd-dynamic :: 
> TestCases/interception_failure_test.cc
>   lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
>   lldb-Suite :: 
> functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
>   lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
>   lldb-Suite :: python_api/thread/TestThreadAPI.py
> 
>   
>   Failing Tests (476):
>   AddressSanitizer-Unit :: 
> ./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
>   AddressSanitizer-Unit :: 
> ./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
>   AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
>   AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
>   Builtins-i386-freebsd :: floatundixf_test.c
>   LLDB :: ExecControl/StopHook/stop-hook-threads.test
>   LLDB :: ExecControl/StopHook/stop-hook.test
>   LLDB :: SymbolFile/DWARF/dwarf5-partial-index.cpp
>   LLDB :: SymbolFile/DWARF/find-basic-function.cpp
>   LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
>   LLDB :: SymbolFile/DWARF/find-basic-type.cpp
>   LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
>   LLDB :: SymbolFile/DWARF/find-method.cpp
>   LLDB :: SymbolFile/DWARF/find-variable-file.cpp
>   LLDB :: tools/lldb-mi/exec/exec-step.test
>   LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
>   LLVM :: tools/yaml2obj/elf-override-shsize.yaml
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
>   MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
>   MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
>   MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
>   MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
>   MemorySanitizer-Unit :: 
> ./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
>   MemorySanitizer-X86_64 :: dtls_test.c
>   MemorySanitizer-lld-X86_64 :: dtls_test.c
>   SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
>   SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
>   SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
>   SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
>   SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
>   SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
>   SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
>   SanitizerCommon-tsan-x86_64-FreeB

[lldb-dev] LLVM 9.0.1-final has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've just tagged the 9.0.1-final release.  Testers can begin uploading binaries.

-Tom

___
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 9.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/08/2020 09:24 AM, Brian Cain wrote:
> Tom, the 9.0.1 final binaries didn't (yet?) make it to the github release 
> page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1 
> 

The binaries have been posted now.

> I also checked https://releases.llvm.org/ because I recall some debate or 
> back-and-forth about where the releases should go and/or redirects or links 
> from one to the other.  But they're not there either.
> 

I'm working on fixing the releases.llvm.org page.

-Tom

> On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> I've just tagged the 9.0.1-final release.  Testers can begin uploading 
> binaries.
> 
> -Tom
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 
> 
> 
> -- 
> -Brian

___
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 9.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/09/2020 09:11 AM, Brian Cain wrote:
> 
> 
> On Thu, Jan 9, 2020 at 12:29 AM Tom Stellard  > wrote:
> 
> On 01/08/2020 09:24 AM, Brian Cain wrote:
> > Tom, the 9.0.1 final binaries didn't (yet?) make it to the github 
> release page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1
> >
> 
> The binaries have been posted now.
> 
> 
> I don't see the ubuntu 16 one that I uploaded there - 
> clang+llvm-9.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> 

These are up now.

-Tom

>  
> 
> > I also checked https://releases.llvm.org/ because I recall some debate 
> or back-and-forth about where the releases should go and/or redirects or 
> links from one to the other.  But they're not there either.
> >
> 
> I'm working on fixing the releases.llvm.org  
> page.
> 
> -Tom
> 
> > On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > I've just tagged the 9.0.1-final release.  Testers can begin 
> uploading binaries.
> >
> > -Tom
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org  
> >
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > --
> > -Brian
> 
> 
> 
> -- 
> -Brian

___
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 9.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/14/2020 08:59 AM, Russell Gallop wrote:
> Hi Tom, Hans,
> 
> I can't see LLVM-9.0.1-win*.exe from Hans on the GitHub release page 
> (https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1). Is this 
> still in progress?
> 

Hans did you upload these?  I don't see them on the server.

-Tom

> Thanks
> Russ
> 
> On Thu, 9 Jan 2020 at 20:05, Tom Stellard via cfe-dev  > wrote:
> 
> On 01/09/2020 09:11 AM, Brian Cain wrote:
> >
> >
> > On Thu, Jan 9, 2020 at 12:29 AM Tom Stellard    >> wrote:
> >
> > On 01/08/2020 09:24 AM, Brian Cain wrote:
> > > Tom, the 9.0.1 final binaries didn't (yet?) make it to the github 
> release page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1
> > >
> >
> > The binaries have been posted now.
> >
> >
> > I don't see the ubuntu 16 one that I uploaded there - 
> clang+llvm-9.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> >
> 
> These are up now.
> 
> -Tom
> 
> > 
> >
> > > I also checked https://releases.llvm.org/ because I recall some 
> debate or back-and-forth about where the releases should go and/or redirects 
> or links from one to the other.  But they're not there either.
> > >
> >
> > I'm working on fixing the releases.llvm.org 
>   page.
> >
> > -Tom
> >
> > > On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> > 
>  
>  > >
> > > Hi,
> > >
> > > I've just tagged the 9.0.1-final release.  Testers can begin 
> uploading binaries.
> > >
> > > -Tom
> > >
> > > ___
> > > cfe-dev mailing list
> > > cfe-...@lists.llvm.org  
> > 
>  
> >>
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > >
> > >
> > >
> > > --
> > > -Brian
> >
> >
> >
> > --
> > -Brian
> 
> ___
> 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] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

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?

-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 and better procedures around bug triage and 
> prioritization.
> 
> What we have been doing up until now has not been great in any case. 
> Switching bug-trackers is a great opportunity to try to do something better. 
> E.g., like what the rust project has done 
> (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

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 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 fr

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> Hi,
> 
> 
> 
> 
> On Thu, Jan 30, 2020 at 10:21 AM 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.
> 
> 
> Do we have a way for individuals to get individually automatically subscribed 
> on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
> 

When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.

From what I can tell, there are a couple different ways to auto-subscribe
people using github actions.  I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.

I was planning to experiment more with this over the next few days.

-Tom





> -- 
> Mehdi
> 
> 
> 
>  
> 
> 
> What does everyone think about this?
> 
> -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.
> >
> >

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 01/31/2020 01:21 AM, James Henderson wrote:
> My only concern is the ability to get auto-subscribed onto issues for 
> specific tools (i.e. the setup I currently have). If that can be resolved in 
> a satisfactory manner, then I'm all for this (although less than two weeks 
> seems like a rather ambitious time to switch over...). If it can't, then I'd 
> be opposed to switching at all.
> 

Would you be able to help me test some potential solutions for this?

-Tom

> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> 
> On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> > Hi,
> >
> >
> >
> >
> > On Thu, Jan 30, 2020 at 10:21 AM 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.
> >
> >
> > Do we have a way for individuals to get individually automatically 
> subscribed on all the bugs created for a given tag?
> > Mailing-lists seem fairly rigid in terms of granularity with respect to 
> tags.
> >
> 
> When I said cc lists, I really meant auto-subscribe lists, I didn't mean
> that we would start sending issue emails to mailing lists.
> 
> From what I can tell, there are a couple different ways to auto-subscribe
> people using github actions.  I think the most simple would be to use
> the assignee field, but I think it's also possible by @ mentioning people
> directly in a comment or @ mentioning teams.
> 
> I was planning to experiment more with this over the next few days.
> 
> -Tom
> 
> 
> 
> 
> 
> > --
> > Mehdi
> >
> >
> >
> > 
> >
> >
> > What does everyone think about this?
> >
> > -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 bu

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

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.

-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 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

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

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?

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 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

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 08:00 AM, James Henderson wrote:
> 
> 
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> 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. 
> 
> 
> Don't forget to update the URL used in crash messages to point at the right 
> location.
>  
> 
> 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.
> 
> 
> Making bugzilla read-only seems like a bad idea until all existing issues 
> have been migrated. What if people need to update an existing bug once the 
> migration to using Github issues has happened before importing has also 
> happened?
>  

This was a mistake on my part.  The plan is to disable creation of new bugs in 
bugzilla and not
to make it read-only.  If you look at the original RFC, it says GitHub issues
would be used for new issues, and existing issues will continue to be updated 
in bugzilla,
and this is what I'm proposing.

> 
> 
> 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'd like this list to be fleshed out before migration is agreed. I'm 
> concerned different people will have wildly different ideas of what "commonly 
> used" might mean, which could in turn have an impact on the viability of this 
> tag list.
>  

Most commonly used here means categories with the most bugs.  So, this would be
based on raw bug counts and not just someone's opinion.

-Tom

> 
> 
> 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?
> 
> 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?
> >> >
>  

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 10:13 AM, Florian Hahn wrote:
> Hi,
> 
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>>
>> 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.
> 
> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
> does? I am not sure how many people use llvm-bugs, but at least for me it is 
> how I keep up with new bug reports.
> 

Sending email to llvm-bugs was not planned.  Can you use GitHub notifications 
instead?

-Tom

> Cheers,
> Florian

___
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] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
>  wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
 On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
 mailto:llvm-...@lists.llvm.org>> wrote:

 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.
>>>
>>> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
>>> does? I am not sure how many people use llvm-bugs, but at least for me it 
>>> is how I keep up with new bug reports.
>>>
>>
>> Sending email to llvm-bugs was not planned.  Can you use GitHub 
>> notifications instead?
> How do i subscribe to only get notified about new issues, but not
> about every new change
> in every issue unless i have explicitly subscribed to the issue?

Is there a way to do this with bugzilla?

-Tom

> 
>> -Tom
> Roman
> 
>>> Cheers,
>>> Florian
>>
>> ___
>> 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] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/17/2020 06:39 AM, Roman Lebedev wrote:
> On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard  wrote:
>>
>> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
>>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
>>>  wrote:

 On 03/16/2020 10:13 AM, Florian Hahn wrote:
> Hi,
>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>>
>> 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.
>
> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
> does? I am not sure how many people use llvm-bugs, but at least for me it 
> is how I keep up with new bug reports.
>

 Sending email to llvm-bugs was not planned.  Can you use GitHub 
 notifications instead?
>>> How do i subscribe to only get notified about new issues, but not
>>> about every new change
>>> in every issue unless i have explicitly subscribed to the issue?
>>
>> Is there a way to do this with bugzilla?
> That is the current behavior of llvm-bugs@ + manually subscribing to
> the bugs of interest.
> 

As I just mentioned in the other mail, looking at the llvm-bugs archive
it looks like there are more than just new bugs e.g.
http://lists.llvm.org/pipermail/llvm-bugs/2020-March/082017.html

-Tom

>> -Tom
> Roman
> 
 -Tom
>>> Roman
>>>
> Cheers,
> Florian

 ___
 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] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 10:18 AM, Roman Lebedev wrote:
> On Mon, Mar 16, 2020 at 8:13 PM Florian Hahn via cfe-dev
>  wrote:
>>
>> Hi,
>>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
>>  wrote:
>>
>> 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.
>>
>>
>> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
>> does? I am not sure how many people use llvm-bugs, but at least for me it is 
>> how I keep up with new bug reports.
> +1
> 

I have been looking into this over the last week and was able to get something
working that will email llvm-bugs when an issue is opened, closed, or reopened.
Here is an example email, let me know if there is anything else I should add:


FROM: llvmlist...@llvm.org
Reply-To: llvm-b...@lists.llvm.org
Subject: [Issue 11] Another emailer test



https://github.com/llvm/temp-issue-tester/issues/11

Title: Another emailer test
Reporter: tstellar
State: open


Test description.


-Tom

> 
>> Cheers,
>> Florian
> Roman
> 
>> ___
>> 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] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 07:53 AM, Aaron Ballman wrote:
> 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.

Is there anything we could do to make having active issues in both
trackers easier to deal with?  

-Tom

> 
> ~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

[lldb-dev] Is ppc64 big-endian supported on Linux

[Tom Stellard via lldb-dev]

Hi,

I've been looking at lldb on ppc64 big-endian, and I noticed that
big-endian binary detection was broken about 2.5 years ago by this
commit: 
https://github.com/llvm/llvm-project/commit/37b1d7b36fa144b0733dfc1659defe80cf384b15

Even with that fixed, breakpoints on ppc64 big-endian seem to be ignored.
Was ppc64 big-endian ever working on Linux?  Is this something that someone 
wants
to try to support or should we drop the ppc64 big-endian code from the tree 
entirely?

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Tom Stellard via lldb-dev]

Hi,

I wanted to continue discussing the plan to migrate from Bugzilla to Github.
It was suggested that I start a new thread and give a summary of the proposal
and what has changed since it was originally proposed in October.

== Here is the original proposal:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html

== What has changed:

* You will be able to subscribe to notifications for a specific issue
  labels.  We have a proof of concept notification system using github actions
  that will be used for this.

* Emails will be sent to llvm-bugs when issues are opened or closed.

* We have the initial list of labels: 
https://github.com/llvm/llvm-project/labels

== Remaining issue:

* There is one remaining issue that I don't feel we have consensus on,
and that is what to do with bugs in the existing bugzilla.  Here are some 
options
that we have discussed:

1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that are
still active will be updated there until they are closed.  This means that over
time the number of active bugs in bugzilla will slowly decrease as bugs are 
closed
out.  Then at some point in the future, all of the bugs from bugzilla will be 
archived
into their own GitHub repository that is separate from the llvm-project repo.

2. Same as 1, but also create a migration script that would allow anyone to
manually migrate an active bug from bugzilla to a GitHub issue in the 
llvm-project
repo.  The intention with this script is that it would be used to migrate 
high-traffic
or important bugs from bugzilla to GitHub to help increase the visibility of 
the bug.
This would not be used for mass migration of all the bugs.

3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues at 
the same time.
Closed or inactive bugs would be archived into their own GitHub repository, and 
active bugs
would be migrated to the llvm-project repo.


The key difference between proposal 1,2 and 3, is when bugs will be archived 
from bugzilla
to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that we 
can migrate
to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs 
during the
transition (proposal 3) will delay the transition for a while (likely several 
months)
while we evaluate the various solutions for moving bugs from bugzilla to GitHub.


The original proposal was to do 1 or 2, however there were some concerns raised 
on the list
that having 2 different places to search for bugs for some period of time would
be very inconvenient.  So, I would like to restart this discussion and 
hopefully we can
come to some kind of conclusion about the best way forward.

Thanks,
Tom

___
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: Switching from Bugzilla to Github Issues [UPDATED]

[Tom Stellard via lldb-dev]

On 04/20/2020 12:49 PM, Richard Smith wrote:
> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> I wanted to continue discussing the plan to migrate from Bugzilla to 
> Github.
> It was suggested that I start a new thread and give a summary of the 
> proposal
> and what has changed since it was originally proposed in October.
> 
> == Here is the original proposal:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> 
> == What has changed:
> 
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github 
> actions
>   that will be used for this.
> 
> * Emails will be sent to llvm-bugs when issues are opened or closed.
> 
> * We have the initial list of labels: 
> https://github.com/llvm/llvm-project/labels
> 
> == Remaining issue:
> 
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some 
> options
> that we have discussed:
> 
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla 
> that are
> still active will be updated there until they are closed.  This means 
> that over
> time the number of active bugs in bugzilla will slowly decrease as bugs 
> are closed
> out.  Then at some point in the future, all of the bugs from bugzilla 
> will be archived
> into their own GitHub repository that is separate from the llvm-project 
> repo.
> 
> 2. Same as 1, but also create a migration script that would allow anyone 
> to
> manually migrate an active bug from bugzilla to a GitHub issue in the 
> llvm-project
> repo.  The intention with this script is that it would be used to migrate 
> high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility 
> of the bug.
> This would not be used for mass migration of all the bugs.
> 
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub 
> issues at the same time.
> Closed or inactive bugs would be archived into their own GitHub 
> repository, and active bugs
> would be migrated to the llvm-project repo.
> 
> 
> Can we preserve the existing bug numbers if we migrate this way? There are 
> lots of references to "PRx" in checked in LLVM artifacts and elsewhere in 
> the world, as well as links to llvm.org/PRx , 
> and if we can preserve all the issue numbers this would ease the transition 
> pain substantially.
>  

For all 3 proposals we want to be able to preserver the llvm.org/PR links 
so that
they continue to provide useful information.  Eventually once bugzilla is shut 
down,
those links would point to an issue somewhere in GitHub.

We don't have a solution for this today and this is one of the reasons why 
proposal
3 will take so long to implement, because we need to solve this problem before 
we start any
kind of transition.

This is also the reason why proposals 1 and 2 were originally favored, because 
they allow us
to transition to GitHub issues for new bugs sooner, while still maintaining the 
PR
links in bugzilla.  This gives us time to work out a good long-term solution to 
maintaining
the links without further delaying the transition to GitHub issues.

-Tom



> 
> The key difference between proposal 1,2 and 3, is when bugs will be 
> archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that 
> we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive 
> bugs during the
> transition (proposal 3) will delay the transition for a while (likely 
> several months)
> while we evaluate the various solutions for moving bugs from bugzilla to 
> GitHub.
> 
> 
> The original proposal was to do 1 or 2, however there were some concerns 
> raised on the list
> that having 2 different places to search for bugs for some period of time 
> would
> be very inconvenient.  So, I would like to restart this discussion and 
> hopefully we can
> come to some kind of conclusion about the best way forward.
> 
> Thanks,
> 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