Re: [PATCH 4/4] doc: Migrate Process wiki page to sphinx

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]

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
> > +<https://www.denx.de/wiki/U-Boot/ReleaseCycle>`_.  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 <https://groups.google.com/g/fa.linux.kernel/c/TLJIJVA-I6o?pli=1>`_, 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]