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

[Robinson, Paul via lldb-dev]

> -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
> <llvm-...@lists.llvm.org> 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] [llvm-dev] [6.0.0 Release] Scheduling the release

[Renato Golin via lldb-dev]

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] [llvm-dev] [6.0.0 Release] Scheduling the release

[Renato Golin via lldb-dev]

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