Re: [lldb-dev] [cfe-dev] [6.0.0 Release] Scheduling the release
On 6 Dec 2017, at 18:28, Hans Wennborg via cfe-dev wrote: > > 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. I have a few remarks. 1) We are still busy with the 5.0.1 release, and this next (major) branching is pretty soon afterwards. Please make sure not to burn out your testers. :) 2) I would really like some sort of stabilization to take place *before* major branching occurs. (In FreeBSD land, we call this the "slush" period.) By now, it should be well-known when such major branching happens, e.g. somewhere at the start of the year, and somewhere in the middle. So people should start stabilizing, say, one or two months in advance of that. Which means to postpone huge restructuring efforts, or adding big new untested features, but concentrate on fixing bugs, ensuring test cases succeed on all platforms, and generally getting the tree in "good shape". It would be nice if the release manager(s) sent a reminder about this well in advance of the actual branch date, explicitly mentioning the desire to stabilize. Maybe mails like this could be used for such reminders. Having said all that, for me branching earlier is not a problem. For corporate contributors it would maybe be a bit soon after the holiday season... :) -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Scheduling the release
On 6 December 2017 at 17:28, Hans Wennborg via llvm-dev wrote: > 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. Hi Hans, I see this as a positive move. As most people prepare to go into end-of-year mode, they take less risks and commit less experimental code. After the year begins again, people start taking more risks. The closer we branch to the beginning of the year, they less experimental half-backed stuff we'll carry on to the new branch and the less reverts we'll have to do. Well, that's the theory. I don't have strong arguments to back that up, it's just a feeling, but being 3rd as random as 17th, it makes no big difference. > 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. Predictability is important when it happens for a reason. Just because it was the same last year is a weak argument to begin with. If we have a better one (helps stabilisation), then I can't see why we should stick to whatever random date we had before. > 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? As Dimitry said, this can work nicely as a feature-freeze period, like BSD and GCC. We don't have to change anything on our side, as we'll continue to propose patches to backport, but having a longer start means we can backport more fixes before RC1 is marked and have higher chances that it will be stable. Our internal process is easy enough (Jenkins based, little manual work) that it doesn't matter much when we do. What consumes most of the work is the bugs that we find and have to backport a fix, so if we do anything to improve that, and a longer stabilisation period helps, then I support this change. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Scheduling the release
On 6 December 2017 at 21:06, Robinson, Paul via llvm-dev wrote: > I'm very sympathetic to syncing upstream stabilization with internal > processes; that said, branching so soon after New Year's Day (which > I'd guess is celebrated essentially everywhere) seems like not such a > great idea. This is not a strong objection, more of an observation. Hi Paul, I'm curious as to what problems you're expecting... My reasoning (more of a feeling) is that most people will refrain from controversial changes just before the turn of the year, though I have no data points to corroborate that. :) cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stopping "stop reason = exec"
That works, thanks Jim! Agreed that it is ugly though :-) -Chris > On Dec 4, 2017, at 6:18 PM, Jim Ingham wrote: > > Yup, apparently debugserver tells us the stop is for exec directly so we > don't treat it as a breakpoint hit. That sorta makes sense, you don't want > to trigger a breakpoint hit every time you find a thread at the pc of a > breakpoint (might be a thread that hit a breakpoint, then didn't get to run > till the next stop.) But it defeats the obvious method. > > Anyway, it is a program stop, so you can use a stop hook: > > (lldb) target stop-hook add -n _dyld_start -o continue > > That one does work, though the stop-hook output is a little ugly. It would > also be nice to specify stop-hooks by stop reason too. But this method does > work... > > Jim > > >> On Dec 4, 2017, at 4:36 PM, Chris Lattner wrote: >> >>> On Dec 4, 2017, at 4:25 PM, Chris Lattner wrote: For macOS, you can also just do: (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c (lldb) b com add -o continue either in your .lldbinit or in your debug session. >>> >>> This doesn’t appear to work, I tried both lldb and in a debug session. I’m >>> starting lldb with “lldb -- swiftc … “ if that matters. >>> >>> (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld >>> Breakpoint 1: where = dyld`_dyld_start, address = 0x1000 >>> (lldb) b com add -o continue >>> Breakpoint 2: no locations (pending). >>> WARNING: Unable to resolve breakpoint to any actual locations. >> >> I realize that this is probably because you’re not using the standard ‘b’ >> alias. When I use ‘br’, the command succeeds, but I still stop on launch: >> >> (lldb) br com add -o continue >> (lldb) r >> There is a running process, kill it and restart?: [Y/n] y >> Process 24049 exited with status = 9 (0x0009) >> Process 24054 launched: >> '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swiftc' >> (x86_64) >> Process 24054 stopped >> * thread #2, stop reason = exec >>frame #0: 0x000109852000 dyld`_dyld_start >> dyld`_dyld_start: >> -> 0x109852000 <+0>: popq %rdi >>0x109852001 <+1>: pushq $0x0 >>0x109852003 <+3>: movq %rsp, %rbp >>0x109852006 <+6>: andq $-0x10, %rsp >> Target 0: (swiftc) stopped. >> >> >> Thank you for the help, I appreciate it! >> >> -Chris >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Scheduling the release
> -Original Message- > From: Renato Golin [mailto:renato.go...@linaro.org] > Sent: Thursday, December 07, 2017 11:52 AM > To: Robinson, Paul > Cc: Hans Wennborg; Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp- > d...@lists.llvm.org); LLDB Dev (lldb-dev@lists.llvm.org) > Subject: Re: [llvm-dev] [lldb-dev] [6.0.0 Release] Scheduling the release > > On 6 December 2017 at 21:06, Robinson, Paul via llvm-dev > wrote: > > I'm very sympathetic to syncing upstream stabilization with internal > > processes; that said, branching so soon after New Year's Day (which > > I'd guess is celebrated essentially everywhere) seems like not such a > > great idea. This is not a strong objection, more of an observation. > > Hi Paul, > > I'm curious as to what problems you're expecting... My reasoning (more > of a feeling) is that most people will refrain from controversial > changes just before the turn of the year, though I have no data points > to corroborate that. :) I agree with you about lower levels of project activity at that point; my own selfish concern is about internal staffing levels for handling the new branch, on what for us is the first day back from the holidays. But as I said it's not a strong objection, we can make sure to capture the branch at the correct revision even if we don't do it exactly in the moment, and you make a reasonable argument for going with the earlier date. I don't want to stand in the way here. Thanks, --paulr > > cheers, > --renato ___ 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
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
