[6.0.0 Release] Scheduling the release

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
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.

Cheers,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Robinson, Paul via cfe-dev
> -----Original Message-----
> From: lldb-dev [mailto:[hidden email]] On Behalf Of Hans
> Wennborg via lldb-dev
> Sent: Wednesday, December 06, 2017 9:29 AM
> To: Release-testers; llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-
> [hidden email])
> Subject: [lldb-dev] [6.0.0 Release] Scheduling the release
>
> 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.

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.
Can I make a counter-offer of Monday, 8 January?  If that's a real
problem, then we can live with 3 January.
--paulr

>
> 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.
>
> Cheers,
> Hans
> _______________________________________________
> lldb-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-dev
On 6 Dec 2017, at 18:28, Hans Wennborg via cfe-dev <[hidden email]> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-dev
On 6 December 2017 at 17:28, Hans Wennborg via llvm-dev
<[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-dev
On 6 December 2017 at 21:06, Robinson, Paul via llvm-dev
<[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Robinson, Paul via cfe-dev


> -----Original Message-----
> From: Renato Golin [mailto:[hidden email]]
> Sent: Thursday, December 07, 2017 11:52 AM
> To: Robinson, Paul
> Cc: Hans Wennborg; Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp-
> [hidden email]); LLDB Dev ([hidden email])
> 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
> <[hidden email]> 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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-dev
On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
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.

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. Things that seem very likely to follow from trying to change this process:

- People won't follow the guidelines because it would be a pretty huge shift from prior workflows.
- We'll need some enforcement policy which will end up driving people to use more branches and generally develop things less incrementally and with less review.
- There will be the feeling that outside of these windows it is some how less critical to keep top-of-tree "stable"

It also isn't clear what problem this idea is trying to solve. If the release testers need the tree to start off closer to "ready", we should add continuous testing of these areas and hold patches to that *always*, not just right before a branch.

Anyways, my two cents....
-Chandler

PS: None of the above means we shouldn't minimize *disruption* right before a branch to make things easier. Making things hard to cherry pick, or having APIs in a half-way state isn't a great idea. But folks already do a good job (in my experience) timing disruptive changes to land in ways that are friendly to the release branching schedule.

On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev <[hidden email]> wrote:
On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] [6.0.0 Release] Scheduling the release

Robinson, Paul via cfe-dev
On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth <[hidden email]> 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.


> On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev
> <[hidden email]> wrote:
>>
>> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Robinson, Paul via cfe-dev


> -----Original Message-----
> From: lldb-dev [mailto:[hidden email]] 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-
> [hidden email]); 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 <[hidden email]>
> 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
> > <[hidden email]> wrote:
> >>
> >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <[hidden email]>
> 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
> >> [hidden email]
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> _______________________________________________
> lldb-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev