On Sat, Jul 09, 2022 at 08:55:48AM +0200, Heinrich Schuchardt wrote: > On 6/27/22 19:17, Tom Rini wrote: [snip] > > +Phases of the Development Process > > +--------------------------------- > > + > > +U-Boot development takes place in `Release Cycles > > +`_. A Release Cycle lasts > > +normally for three months. > > + > > +The first two weeks of each Release Cycle are called *Merge Window*. > > + > > +It is followed by a *Stabilization Period*. > > + > > +The end of a Release Cycle is marked by the release of a new U-Boot version. > > Don't repeat yourself. I'm not seeing repetition really here. [snip] > > +Work flow of a Custodian > > +------------------------ > > + > > +The normal flow of work in the U-Boot development process will look > > +like this: > > + > > +#. A developer submits a patch via e-mail to the u-boot-users mailing list. > > + U-Boot has adopted the `Linux kernel signoff policy `_, so the submitter must > > + include a ``Signed-off-by:`` line. > > Keep lines at 80 characters. > > > +#. Everybody who can is invited to review and test the changes. Reviews should > > + reply on the mailing list with ``Acked-by`` lines. > > %s/Acked-by/Reviewed-by/ ? > > Please, refer to > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html > for the usage of Reviewed-by and Acked-by. Yes, it would be good to reword this to reference the current kernel.org documentation, I'll try something. > > +#. The responsible custodian > > + > > + #. inspects this patch, especially for: > > This should not be a bullet but go into the line above. That would read better, yes. [snip] > > +#. Once tests are passed, some agreed time limit expires, the custodian > > No clue what agreed time limit you are referring to. > > The custodian will create a merge request when the merge window matching > the type of the patch (feature or bug) is open. This has long been more informal rather than following a defined process, yes. I'll try and reword things a bit. > > > + requests that the changes in his public git repository be merged into the > > + main tree. If necessary, the custodian may have to adapt his changes to > > + allow for a clean merge. > > + Todo: define a reasonable time limit. 3 weeks? > > This todo-line is not helpful. If the patch contains a new feature, the > custodian has to wait for the next merge window before issuing a pull > request for it. -- Tom