On 6 December 2017 at 17:28, Hans Wennborg via llvm-dev <llvm-...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
