cloud-init team mailing list archive

[Dermot Bradley <dermot_bradley@xxxxxxxxx>]

Hello folks
I've recently signed the CLA and am preparing to to shortly submit patches to add Alpine Linux support to cloud-init. I took over maintainership for Alpine's existing old, unmaintained, and somewhat limited cloud-init packages, updated them from 18.5 to 20.2, added Alpine support to more cloud-init modules, wrote a new module to manage the Alpine repositories file, and in the past week the new packages were pushed to Alpine's repositories ("Alpine Linux packages").


| 
| 
|  | 
Alpine Linux packages


 |

 |

 |


I have been using these changes myself for many months now on Arm (32 & 64bit) and x86_64 and they work well.
I will have to tweak my changes for Master as I see there has been some "restructuring" going on since 20.2 was released.


I have a few questions:
What is the best way to submit these changes to cloud-init? Is there any preference as to which of the following 2 approaches I should follow?

(a) raise a single PR for all the Alpine-related changes

or
(b) raise one PR for the "core" Alpine changes include modules with minor changes, and then raise separate PRs for each of the modules that have more substantial code additions/changes for (to allow for the situation that one of these additional PRs might get bogged down in review).


What is the likely close off date for PRs to make it into the next cloud-init release? Based on the timescales of the past releases I assume the intention is for the next release to come out late July/early August.


Finally one of the files I will be submitted has copyright from another person (the original creator of the Alpine cloud-init package in 2016). I talked to him recently and he is happy to sign the CLA. I just wondered about the "mechanics" of handling this - would he need to sign the CLA prior to me submitting the PR containing this file? Or can he just sign the CLA before the merge (i.e. during the review period)?

Thanks in advance
Dermot