> -----Original Message----- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans > Wennborg via lldb-dev > Sent: Friday, December 15, 2017 10:07 AM > To: Chandler Carruth > Cc: llvm-dev; Release-testers; cfe-dev; openmp-dev (openmp- > d...@lists.llvm.org); LLDB Dev > Subject: Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the > release > > On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth <chandl...@gmail.com> > wrote: > > FWIW, I don't have really strong objections, but I'm honestly not a fan. > The > > reason is mostly that I think it is very late to make the change and > likely > > to mean most people are on holiday when the branch occurs. I somewhat > > anticipate significantly more cherrypicks as a consequence. I'd love for > > Apple's releases to by sync'd with the open source ones, but I don't > > understand why one week earlier is so critical. That said, I generally > defer > > to those who are working more heavily on the open source releases. > > Thanks for your input. I'm not too worried given that the idea is to > start slowly and ramp up testing with RC1 which will happen around the > time it normally would. Let's see how it goes. > > > > The one thing I have a stronger opinion about is the idea of a "feature > > freeze", stabilization period, or other change. I'm pretty strongly > opposed > > to this. One of the things that I most appreciate about the LLVM > community > > and process is that the top-of-tree is always open, always active, and > > always kept green. > > I agree. Releases should happen on a branch and not obstruct > development on trunk (besides the common courtesy of not landing > majorly disruptive changes righ before the branch as you mentioned > below). I'm not suggesting any changes here.
FTR it's majorly disruptive changes right *after* the branch that cause the most headaches for cherry-picking fixes. --paulr > > > > On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev > > <openmp-...@lists.llvm.org> wrote: > >> > >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <h...@chromium.org> > 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. > >> > >> Since there wasn't really any opposition to the 3 January "slow start" > >> suggestion, let's go with that. I propose the following schedule: > >> > >> 3 January 2018 - Branch point. Those who want can start testing and > >> nominating merges. > >> 17 January 2018 - Release Candidate 1 tag, testing of that starts. > >> 7 February 2018 - Release Candidate 2, things should ideally look > >> pretty good now > >> 21 February 2018 - Final tag. (Typically this slips a bit; just try > >> not to slip into March.) > >> > >> Unless there are any objections, I'll post this on the web page soon. > >> > >> Cheers, > >> Hans > >> _______________________________________________ > >> Openmp-dev mailing list > >> openmp-...@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev > _______________________________________________ > 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
