Re: [U-Boot-Users] Changes to U-Boot Development Process
Am I on the right lines here?
U-Boot development process ========================== Gatekeepers have responsibility for some area of U-Boot.
A developer submits a patch via email or requests git pull [Gatekeepers possibly contend for patch] Chosen gatekeeper inspects patch for Coding style Basic logic U-Boot ethos (e.g lowest possible size) **1 MAKEALL **2 until satisfied [If not rejected] Gatekeeper pushes new branch for the patch to the "area git", and notifies the user list. As well as a short summary the description may include Affected board or area Suggested tests If unable to test sufficiently themselves **2, the gatekeeper request tests from specific maintainers and U-Boot users. Tests by the original developer are not sufficient. Once tests are passed, or some agreed time limit expires **3, the gatekeeper requests that the area branch be merged into the main tree. [If necessary, patch is reworked to allow merge] **1:: Ethos - whereas this used to be in Wolfgang's head we may need to document some of it. **2:: Gatekeepers may not have access to all necessary tools and/or boards **3:: I think patches should be accepted if no-one (other than the original developer) has tested them within a certain time, but they meet all other criteria.
Regards
Peter Pearse
On 2/1/07, Peter.Pearse peter.pearse@arm.com wrote:
Am I on the right lines here?
U-Boot development process
Gatekeepers have responsibility for some area of U-Boot.
A developer submits a patch via email or requests git pull
I pretty much agree with your flow here, but I would add one thing.
I think *All* patches should go to the mailing list; even gatekeeper authored ones. It's not the gatekkeepers responsibility to review every patch, but rather to make sure all patches are reviewed. For example, if a patch is not contentious and has been Ack'd by someone he/she trusts, then the gatekeeper can probably merge it without personally reviewing it.
[Gatekeepers possibly contend for patch] Chosen gatekeeper inspects patch for Coding style Basic logic U-Boot ethos (e.g lowest possible size) **1 MAKEALL **2 until satisfied [If not rejected] Gatekeeper pushes new branch for the patch to the "area git", and notifies the user list. As well as a short summary the description may include Affected board or area Suggested tests If unable to test sufficiently themselves **2, the gatekeeper request tests from specific maintainers and U-Boot users. Tests by the original developer are not sufficient. Once tests are passed, or some agreed time limit expires **3, the gatekeeper requests that the area branch be merged into the main tree. [If necessary, patch is reworked to allow merge]
Having a merge window has worked extremely well for the Linux kernel. Does anyone think the same process is appropriate here?
Cheers, g.
participants (2)
-
Grant Likely -
Peter.Pearse