Transitioning to the new Release Process

[mist]

On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau wrote:
> Am Fri, 11 Jan 2013 18:54:12 +0100
> schrieb "mist" <none at none.none>:
>
>> Short comment about cherry pick - it is only bad in sense that 
>> it
>> creates separate untrackable commit with same content, which 
>> may
>> easily result in merging issues. If there is only one-way
>> direction for commit transitioning ( stuff goes from master to
>> staging and LTS and never goes back ) there is nothing 
>> inherently
>> bad about cherry pick.
>
> Having multiple commit ids for the same commit is also 
> annoying. For
> example if someone bisected a regression and you want to revert 
> a commit
> you have to figure out the commit id of the cherry picked 
> commits.
>

AFAIK reverts are content-based, so knowing any one commit id is 
enough. It is annoying mostly when comparison happens between two 
branches with those commits.

>> Much more important point is that
>> it complicates development process for newcomers without any
>> reasonable benefit. And if we still gonna push for success as 
>> an
>> open-source project, being easy understandable by an outsider 
>> is
>> as important as a clear release process.
> The rule is quite simple and easy to understand though:
> regression fix -> version branch
> bug fix -> staging
> enhancement -> master

Ye, it is easy.. except you need to actually check out wiki page 
to be aware about it. At the very least we need relevant excerpts 
for outer devs separated to one small wiki page and set links to 
this page in github marked with big "NB:".

I don't have a reason to argue about the rest.