[Development] [Releasing] Qt 5.0 alpha released

[marius.storm-olsen at nokia.com]

On 04/05/2012 09:38 AM, ext Oswald Buddenhagen wrote:
> On Thu, Apr 05, 2012 at 10:54:56AM -0300, ext Thiago Macieira wrote:
>> On quinta-feira, 5 de abril de 2012 13.49.40, marius.storm-olsen at nokia.com
>> wrote:
>>> Those were local in Simo's machine due to some cherry-picking of not yet
>>> landed changed. I wanted to tag with reviewed an landed changes though
>>
>> Please upload the exact SHA-1 from Simo's machine because those are in the
>> released package now.
>>
>> I recommend the procedure:
>>
>> per-module:
>> 1) git tag -a the *exact* SHA-1 that are found on Simo's machine
>>     if the module does not follow Qt's versioning, tag it as "qt-v5.0.0-alpha1"
>>     retroactively setting the date too with GIT_COMMITTER_DATE
>> 2) wait for the fixes to land
>> 3) git merge -s ours v5.0.0-alpha1
>> 4) push the merge, approve it, stage it
>>
> or just admit the screwup, and silently upload a tar-ball with the
> corrected sha1s, for the sake of not uglifying the git history.
> and just for good measure, let simo repeat "i will not bypass CI again"
> about a thousand times.

In the end it was Lars and my call, and Simo did as we said. We had to 
get the alpha out, and landing the patches in time was proving too 
difficult, even though the patches in question had been tested 
successfully on the T1 platforms.

So I think the discussion should be more angled towards, releasing alpha 
from master branch proved too hard, and should we thus use a branch for 
the beta release? Or is this an inherit property of an alpha release, 
and beta will prove more stable?

IMO, we should use a temporary CI tested branch for the release. CI 
failures do to unrelated stagings eat up valuable cycles.

Lars and I also discussed putting a temporary hold on staging rights for 
anyone except maintainers during the release cycle. Opinions on that 
approach?

-- 
.marius