llvm dev - Dec 2017 - [Openmp-dev] [6.0.0 Release] Scheduling the release

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 <
openmp-dev at lists.llvm.org> wrote:
> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <hans at 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-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171215/20b85502/attachment.html>

On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth <chandlerc at
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.

> 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> 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-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

> -----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
> release
> 
> On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth <chandlerc at
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-dev at lists.llvm.org> wrote:
> >>
> >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg <hans at
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-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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev