[TODO] release considerations

[David Lang]

On Fri, 3 Jun 2016, Hannu Nyman wrote:

> On 3.6.2016 19:02, Ted Hess wrote:
>> On Fri, 2016-06-03 at 10:34 +0200, John Crispin wrote:
>
>>> * set a ETA
>>>   - do we want to fork or call for a feature freeze and stabilize in trunk 
>>> ?
>>> 
>> Branch and release is the best strategy. It keeps the trunk alive for 
>> future
>> work and easy to merge forward after release. Also, you have a place for 
>> maint
>> work after release which continues the linear history.
>
> Earlier Openwrt release have had the problem of a rather long time period 
> between branching and the final release. When the time period grows to 4-6 
> months, trunk goes too much forward compared to the forthcoming release. 
> Release starts to look stale. And developers' focus has tended to remain on 
> trunk development (instead of the boring branch stabilising/finalising work). 
> Creating new features is much more fun... And backporting those nice new 
> features to the release branch still before the release would be great...
>
> Branching might work if the period between branching and final release can 
> been kept short, weeks instead of months.
> Same goes also for a feature freeze: it should be kept short.
>
> A combination might also work: 2-3 weeks' feature freeze before the rc 
> version, and then branching for the rc build. And the final release rather 
> quickly after that.

What sort of release cadence is LEDE attempting to have? It seems that more and 
more projects are moving from "when it's ready/when feature X is working" to 
time based releases where they have a merge window followed by stabilization and 
a release.

Depending on the project, it can be like the kernel with a 2 week merge window 
followed by a 5-6 week stabilization period, or like rsyslog with a 5 week merge 
window and a 1 week stabilization period. It seems to depend on how many outside 
contributers there are, the more people feeding fixes in, the shorter the merge 
window compared to the overall release schedule.

As someone said, any drive-by patches that are submitted during the 
stabilization time can sit in a pending branch (or someone can volunteer to be 
the point person for such misc patches and accumulate them)

The key is to make it so that people don't start freaking out about missing a 
release and rush to get their code in if it's not fully ready. It needs to be no 
big deal to boot a patch out of a release and have it fall into the next release 
to let it improve a bit.

David Lang