Next focus: PROCESS

[H. S. Teoh]

On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote:
> On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips wrote:
> >On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
> >
> >>master : used as a base for development. New feature are merged
> >>here.
> >>staging : used to provide a view of what the next version will
> >>look like. Regular snapshot of that branch are made so public
> >>can use the last features.
> >>version : used to contain a version that will have a support for
> >>an extended period of time.
[...]
> >From the sound of it this request is pulled into master. We
> >continue to pull many of these changes in. How do we decide they
> >should be placed into staging, when we pull them into master?. If
> >we wait for some 'magic time' how do we pull it into staging, does
> >that mean we now cherry pick commits of master?

In my mind, after a release, the contents of staging are updated to be
exactly the same as master. This can be done either via a merge, or
simply deleting the current staging and making a new one by branching
from master.


> >Another issue is it sounds like master becomes a "phantom" branch.
> >At no point in time would master resemble what is released. I see
> >this as a problem because it is the branch people are developing off
> >of, it means nothing to test in master as staging has the actual
> >state that will be released.
> 
> That is very true. With the given modification master and stagging
> become redundant with one another. Why not get rid of stagging ?

No, staging does not receive new features except immediately after
release. But it will get bugfixes that do not introduce new things.

Example timeline:
- time=0: we just made a release, so staging := master.

- time=1: a crash bug is discovered in master. Walter checks in a fix.
  Fix is propagated to staging because it doesn't introduce new things,
  only fixes existing problems.

- time=2: Walter decides to merge UDA implementation into master (for
  example). Staging does NOT get UDA merged in, because UDA is new.

- time=3: more bugs are found in master. Fixes are checked in. Fixes get
  propagated to staging.

- time=4: a UDA bug is fixed. Fix is NOT propagated to staging, because
  staging doesn't have UDA (yet).

- time=5: we decide that it's time to release. So:
   - we tag a release on current staging
   - we merge master into staging, so now staging gets UDA

- time=6: Walter adds HalfFloat to master. HalfFloat is NOT propagated
  to staging, because it's new.

- time=7: users running staging find a nasty design flaw in UDA. Walter
  makes a (breaking) fix in master, and the fix is propagated to
  staging, because UDA is already in staging.

- time=8: Walter finds bugs in HalfFloat. Fixes are checked into master,
  but NOT staging.

- time=9: Walter adds more new features to master. These are NOT
  propagated to staging, because they're new.

- time=10: it is decided that UDA design is stable now, and we're ready
  for release. So:
   - we tag a new release on current staging
   - we merge master into staging, now staging gets HalfFloat.

- etc.

Hopefully this makes it clearer what we're trying to achieve.


T

-- 
 Arise, you prisoners of Windows 
 Arise, you slaves of Redmond, Wash, 
 The day and hour soon are coming 
 When all the IT folks say "Gosh!" 
 It isn't from a clever lawsuit 
 That Windowsland will finally fall, 
 But thousands writing open source code 
 Like mice who nibble through a wall.
-- The Linux-nationale by Greg Baker