Hi all,
while working on v3.5.13.x was a rule that the patches have always been first pushed to the master branch and then cherry-picked to v3.5.13-sru branch (with necessary modifications). Directly to v3.5.13-sru patches were pushed very rarely - if they were specific to v3.5.13.x. As an example, the current patch for setting the target release in tdelibs.
I suppose for r14.0.x branch I will not be alone, who will incorporate patches into this maintenance branch, so I would like to determine, whether we will work also on r14.0.x branch under these rules?
Michele, what is your opinion?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hi all,
while working on v3.5.13.x was a rule that the patches have always been first pushed to the master branch and then cherry-picked to v3.5.13-sru branch (with necessary modifications). Directly to v3.5.13-sru patches were pushed very rarely - if they were specific to v3.5.13.x. As an example, the current patch for setting the target release in tdelibs.
I suppose for r14.0.x branch I will not be alone, who will incorporate patches into this maintenance branch, so I would like to determine, whether we will work also on r14.0.x branch under these rules?
I see no reason to change these rules; they ensure that the patches are incorporated into mainline and tested before application to the backport branches.
Tim
On Wednesday 17 of December 2014 02:22:40 Timothy Pearson wrote:
Hi all,
while working on v3.5.13.x was a rule that the patches have always been first pushed to the master branch and then cherry-picked to v3.5.13-sru branch (with necessary modifications). Directly to v3.5.13-sru patches were pushed very rarely - if they were specific to v3.5.13.x. As an example, the current patch for setting the target release in tdelibs.
I suppose for r14.0.x branch I will not be alone, who will incorporate patches into this maintenance branch, so I would like to determine, whether we will work also on r14.0.x branch under these rules?
I see no reason to change these rules; they ensure that the patches are incorporated into mainline and tested before application to the backport branches.
Tim
Yes, I see it the same way. I just wanted to confirm that, Michele will proceed patches in the same way :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014/12/17 10:38 AM, Slávek Banko wrote:
On Wednesday 17 of December 2014 02:22:40 Timothy Pearson wrote:
Hi all,
while working on v3.5.13.x was a rule that the patches have always been first pushed to the master branch and then cherry-picked to v3.5.13-sru branch (with necessary modifications). Directly to v3.5.13-sru patches were pushed very rarely - if they were specific to v3.5.13.x. As an example, the current patch for setting the target release in tdelibs.
I suppose for r14.0.x branch I will not be alone, who will incorporate patches into this maintenance branch, so I would like to determine, whether we will work also on r14.0.x branch under these rules?
I see no reason to change these rules; they ensure that the patches are incorporated into mainline and tested before application to the backport branches.
Tim
Yes, I see it the same way. I just wanted to confirm that, Michele will proceed patches in the same way :)
Sounds good to me too and don't see any reason to change that. One question I have is: after a bug fix has been pushed to the main trunk, do we have to wait for a given amount of time before pushing to the r14.0.x branch, to allow for testing? Or can we cherry-pick and push to r14.0.x immediately?
Cheers Michele
On Wednesday 17 of December 2014 04:41:28 Michele Calgaro wrote:
Sounds good to me too and don't see any reason to change that. One question I have is: after a bug fix has been pushed to the main trunk, do we have to wait for a given amount of time before pushing to the r14.0.x branch, to allow for testing? Or can we cherry-pick and push to r14.0.x immediately?
Cheers Michele
I would say that for simple patches that clearly fix bugs may be patches cherry picked and pushed immediately. For more complex patches we can use validation and approval by a second pair of eyes. Similarly, as it did after the soft-freeze for R14.0.0.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/19/2014 04:55 AM, Slávek Banko wrote:
For more complex patches we can use validation and approval by a second pair of eyes. Similarly, as it did after the soft-freeze for R14.0.0.
Good idea. If a bug fix is somehow complex, we push it to the main trunk, then we can send an email to the TDE dev list or within developers asking for double checking the changes. Then the original commit can be cherry-picked in the R14.0.x branch.
Cheers Michele
-
Michele Calgaro -
Slávek Banko -
Timothy Pearson