Re: integration and master divergence

On Jul 18, 2012, at 9:21 AM, Maik Musall wrote:

> 
> Am 18.07.2012 um 14:25 schrieb Kieran Kelleher:
> 
>> On Jul 18, 2012, at 6:21 AM, Maik Musall wrote:
>> 
>>> Am 18.07.2012 um 12:12 schrieb Pascal Robert:
>>> 
>>>> Le 2012-07-18 à 05:45, Maik Musall a écrit :
>>>>> Am 17.07.2012 um 19:22 schrieb Kieran Kelleher:
>>>>>> The original plan with integration was that commits that survived for at least a month in integration without
>>>>>> breakage or bugs would be deemed worthy of merging to master.
>>>>> 
>>>>>> If all goes well, this merge will be shifted to master and then we can from then on ONLY merge integration commits that are a month old PERIODICALLY (1-4 weeks intervals).
>>>>> 
>>>>> As I see it, master should be a stable thing that production apps can rely on. That requires two premises:
>>>>> 
>>>>> 1. An integration test of the periodic merge to make sure everything works fine with everything else after merging stuff that nobody was running in exactly that combination before.
>>>> 
>>>> Right now, the test is that most of us are using integration branch. Most Wonder committers use integration as their primary branch, and I know that other people use it to.
>>> 
>>> That also means that nobody has used exactly that one month old integration commit for longer than until the next commit came in, right? Is that a sufficient basis for stability?
>> 
>> It is about one month better than we had in the old days of svn trunk.
>> 
>> If a few people want to have master lag integration by two months, or some other time period, instead of one month, that's fine by me too.
>> 
>> So the premise right now is (1) active testing is done by the original feature/change contributor/committer, followed by (2) passive small-crowd testing happens in integration branch, and followed by (3) passive large-crowd testing in master branch users. When bugs are found by someone, they are quickly fixed. Any user has the opportunity to be completely conservative and stick to specific master release tags, running *their own* extensive functional and/or unit tests of their applications when they upgrade and sending an email saying, "hey, something is broken in release x.y.x" if something is indeed broken. Such is the dynamic nature of the crowd-built wonder :-)
>> 
>> Ideally we would have an extensive set of unit tests and a high measured percentage of test coverage, but we don't. It is what it is. Anyone who wants to spend their time building and maintaining such extensive unit tests and measuring test coverage is welcome to work on it if they have the time to dedicate to it.... I am sure they will earn a few beers at the next WOWODC :-) 
>> 
>> As long as stuff keeps coming into integration, we need to keep master moving along in some organized way. The main purpose of this merge is to "catch up" one time on all the integration commits since Feb 29 that have *not* been cherry-picked, and give us a more recent "merge-base common ancestor" ready for fast-forward merge catchup's in the future since I think our recent experience has shown that cherry-picking a lot of commits over time leads to divergence that is difficult to reconcile with confidence. 'master' needs to follow 'integration', not diverge from it.
>> 
>> Maik, if you have a better suggestion that fits the expedient nature of keeping wonder master moving, now is the time to propose it.
> 
> 
> My concern is: The periodic merge into master results in a version of Wonder that might not have been used by anybody at all in that specific combination. As a result, for example some inter-framework dependency might be broken without showing up as compile error. As it is, this can only be discovered by field tests, meaning that Wonder master candidate has to be used by as many developers as possible *before* it becomes the new master, aiming for master to be actually as production-ready as possible.

The concern is somewhat valid, however if we are fast-forwarding from integration and most (many?) are using integration in their everyday project work, then integration is being field tested to some extent.



> 
> A way to prevent that would be to make that merge not directly into master, but into a stage or release-candidate branch. As many as possible of us should then use and test that for a week or two, apply fixes there, and when it's ready, that one is merged to master.

That is not an unreasonable request, and is kind of what I did anyway with the 'temp/MergeOneMonthIntegrationToMaster' branch.

OK, so ...... if it is OK, we can loosely (since we tend to be that way anyway ;-) ) follow this process:

periodically merge one-month-old+ commits from integration and current master into a new temporary "Release Candidate" branch, example 'rc-wonder-5.7.0'. Then issue pull request on the release candidate branch to merge to master. Allow 2 weeks of no bug-fixes to pass. then merge it to master.

Also, pull request now re-submitted as a release candidate pull request (https://github.com/projectwonder/wonder/pull/243) and a 2-week no-bug-fix window before it can be merged.


> 
> Using that strategy I don't even see the need to start that branch with an integration version that's already a month old. Could be even newer then.
> 
> Maik


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/