[Release-testers] [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the release
Robinson, Paul via Release-testers
release-testers at lists.llvm.org
Fri Dec 15 11:43:14 PST 2017
> -----Original Message-----
> From: lldb-dev [mailto:lldb-dev-bounces at 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-
> dev at lists.llvm.org); LLDB Dev
> Subject: Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the
> On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth <chandlerc at gmail.com>
> > FWIW, I don't have really strong objections, but I'm honestly not a fan.
> > reason is mostly that I think it is very late to make the change and
> > 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
> > 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
> > to this. One of the things that I most appreciate about the LLVM
> > 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.
> > On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev
> > <openmp-dev at lists.llvm.org> wrote:
> >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <hans at chromium.org>
> >> > 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
> >> > 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
> >> > 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-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the Release-testers