[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
<llvm-dev at lists.llvm.org> 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