Re: gtk3 and master double patches should better be applied to master and then merged

[Friedrich Beckmann]

Hi John,

Am 18.05.2015 um 09:23 schrieb John Darrington <address@hidden>:

> In the past, we've tried to avoid merging too often.  
> 
> Many of the bugs you've reported recently are in fact bugs present in both 
> branches, but for whatever reason only manifest themselves in gtk3
> In this case, where it seemed to be appropriate I applied the patch to both
> branches.
> 
> Like you say, this does mean that when the merge does occur, two entries for
> the same commit will be seen in the merged result.

It is a plan.

> I don't mind if we want to change our policy and apply such changes to master,
> then immediately merge to gtk3.

General policies… I think it depends. Today master and gtk3 are not far away. 
After many commits to master merging to gtk3 will result in more problems. I 
just wanted to highlight the impact of the double commit. Both policies work 
and have pros and cons. As always: The best policy is that John decides case by 
case after considering all implications in a state of peace and happiness. 

> On the other hand, maybe we're not too far away from the point where we can 
> completely migrate to the gtk3 branch?

After the more cosmetic questions the interesting one... There are still of 
number of deprecated warnings. On debian 8 I cannot see the selected cells when 
the default Adwaita scheme is active. What would be the criteria for a merge? 
No deprecation warnings? Some testing on debian 7, debian 8, mac? Does the gtk3 
branch build on all platforms today?

Friedrich

signature.asc
Description: Message signed with OpenPGP using GPGMail