There is no regular merging release branch to master. This work is maintainer 
responsibility with help of committer.

If a commit is related with release, it should be launched on release branch 
first and merge back to master branch with maintainer responsibility.



BR, Uze Choi

From: Kevin Kane [mailto:[email protected]] 
Sent: Wednesday, April 12, 2017 2:49 AM
To: uzchoi at samsung.com; Mats Wichmann; iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Two more things:



1.      Do we have a resource available to make sure there are regular merges 
from 1.3-rel to master? This also means there should never be a cherry-pick 
from 1.3-rel to master.
2.      For changes already up for master to be later cherry-picked: There was 
confusion during 1.2 about who was responsible for doing the cherry-picks. I 
suggest this time around, if an author has submitted a change to master and 
believes it should be on 1.3-rel, the author is responsible for doing the 
cherry-pick and getting the appropriate people on the review, to shepherd the 
change into 1.3-rel. There should be no expectation that anyone else will 
cherry-pick the change to 1.3-rel.



From: ??? [mailto:[email protected]] 
Sent: Monday, April 10, 2017 3:50 PM
To: Kevin Kane <kkane at microsoft.com>; Mats Wichmann <mats at wichmann.us>; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Definitely.

Please mergeback into master after work on 1.3-rel if not release branch 
specific.

BR Uze Choi



--------- Original Message ---------
Sender : Kevin Kane <kkane at microsoft.com>
Date : 2017-04-11 07:31 (GMT+9)
Title : RE: RE: [dev] 1.3-rel Branch out/QA start request.

For changes that are already pending, that sounds fine, especially since the 
branches haven?t yet diverged at all. But from this point forward, for any new 
changes, let?s submit directly to 1.3-rel and then have a regular merge cadence.



From: ??? [mailto:[email protected]] 
Sent: Monday, April 10, 2017 3:24 PM
To: Kevin Kane <kkane at microsoft.com>; Mats Wichmann <mats at wichmann.us>; 
iotivity-dev at lists.iotivity.org
Subject: RE: RE: [dev] 1.3-rel Branch out/QA start request.



Hi Kevin,

Thank you for your suggestion.

It will be good to strictly follow the release branch merging policy.

However for the better efficiency, let's accept currently pending commits 
merged into master branch first and cherrypick in to 1.3-rel as a next step.

BR Uze Choi



--------- Original Message ---------
Sender : Kevin Kane <kkane at microsoft.com>
Date : 2017-04-11 06:14 (GMT+9)
Title : RE: [dev] 1.3-rel Branch out/QA start request.

It'd be better for any 1.3 changes/bug fixes to be committed directly to 
1.3-rel, and then 1.3-rel should be merged regularly into master to pick those 
changes up for the future. I'd suggest any pending changes on master that 
should be in 1.3 be abandoned and resubmitted to 1.3-rel. All the 
cherry-picking that happened between 1.2-rel and master did not work well at 
all.

-----Original Message-----
From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:[email protected]] On Behalf Of Mats Wichmann
Sent: Monday, April 10, 2017 1:50 PM
To: ??? (Uze Choi) <uzchoi at samsung.com>; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] 1.3-rel Branch out/QA start request.

On 04/10/2017 04:57 AM, ??? (Uze Choi) wrote:
> Hi All,
> 
>  
> 
> 1.3-rel branch has been created. 1.3.0 Release period just started.
> 
> There are approximately 70 change sets waiting merge on the master 
> branches
> 
> Except this patches, All code merge should have the release management Lead 
> review +1 on the release branch.


So for owners of waiting changesets... how do we proceed?  The small number I 
have in the queue (five public) I would not consider release-critical, but also 
letting master and 1.3-rel diverge is not wonderful, makes lots of work later 
for someone - I'm remembering what Phil and others had to do to get master back 
in sync with 1.2-rel.

Advice please?



_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev
 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Ckkane%40microsoft.com%7C3a7057b259e34a700d8608d4805326b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274542026472282&sdata=kaW7CiPhNlVkyehkZTEnFkQMMNTJXNXUHlkjKaXuMWQ%3D&reserved=0>
 
&data=02%7C01%7Ckkane%40microsoft.com%7C3a7057b259e34a700d8608d4805326b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274542026472282&sdata=kaW7CiPhNlVkyehkZTEnFkQMMNTJXNXUHlkjKaXuMWQ%3D&reserved=0











  
<http://ext.samsung.net/mail/ext/v1/external/status/update?userid=uzchoi&do=bWFpbElEPTIwMTcwNDEwMjI1MDAxZXBjbXMxcDc0NWFkNzAyODE2MThlOTBlMjU3YjJkOTJjYTIyYWRkYyZyZWNpcGllbnRBZGRyZXNzPWtrYW5lQG1pY3Jvc29mdC5jb20_>
 

-------------- next part --------------
HTML ?????? ??????????????...
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170412/5e5f7fa8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13402 bytes
Desc: ?????? ?? ????????.
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170412/5e5f7fa8/attachment.gif>

Reply via email to