[waffle] [PULL] WGL support

[Emil Velikov]

On 10/11/14 06:17, Chad Versace wrote:
> On Sun 09 Nov 2014, Emil Velikov wrote:
> 
>> As mentioned earlier here is a rebase of all the wgl work so far on top
>> of origin/master.
> 
> Merged to next! So... what does that mean??? That means I'll merge your
> branch to 'master' after it cooks for a little while and I'm certain
> Piglit doesn't complain.
> 
> 
> To answer your branching query from Saturday... Here's a *very tiny*
> summary of the workflow I'm following in man:gitworkflow(7).
> 
>    - The 'master' branch should always be stable. At any time, it   
> should be safe to cut a release off of master.
> 
>    - The 'next' branch is an integration branch. That's where the   
> interesting action happens.
> 
>    - Topic branches are usually first merged to 'next', unless they are
>    obvious fixes. After baking on 'next' for enough time to reveal any
>    lurking bugs, the same topic branch is then merged to 'master'.
> 
>    - As explained in man:gitworkflow(7), merges between branches always
>    flow "upwards" and never "downwards". That is,
> 
>        maint -> master -> next
> 
>    and never
> 
>        master <- next
> 
>    - Merges are preferred over cherry-picks. As explained in   
> man:gitworkflow(7):
> 
> 
>        Merges have many advantages, so we try to solve as many problems as
>        possible with merges alone. Cherry-picking is still occasionally
>        useful.
> 
>        Most importantly, merging works at the branch level, while
>        cherry-picking works at the commit level. [...] Merges are also
>        easier to understand because merge commit is a "promise" that all
>        changes from all its parents are now included.
> 
>        There is a tradeoff of course: merges require a more careful branch
>        management. [...]
> 
>        Always commit your fixes to the oldest supported branch that require
>        them. Then (periodically) merge the integration branches upwards
> into        each other.
> 
>        [A "merging upwards" strategy"] gives a very controlled flow of
>        fixes.  If you notice that you have applied a fix to
>        e.g. master that is also required in maint, you will need to
>        cherry-pick it (using git-cherry-pick(1)) downwards. This will
>        happen a few times and is nothing to worry about unless you do it
>        very frequently.
>
Fwiw although it somewhat makes sense to merge maint into master, I'm
personally "commit to master and cherry-pick to stable/maint" kind of
person. Either way, as long as you're ok dealing with conflicts etc.
I'll deal with it :P

Friendly request - please don't cherry-pick from next onto master. Afaiu
one can(is allowed to) rebase next which will cause a bit of ...

Cheers,
Emil