From patchwork Mon Jul 11 17:14:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Rini X-Patchwork-Id: 1655034 X-Patchwork-Delegate: xypron.glpk@gmx.de Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.a=rsa-sha256 header.s=google header.b=g+7/CrFY; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4LhVsY0xfRz9s07 for ; Tue, 12 Jul 2022 03:16:17 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 78A3C84072; Mon, 11 Jul 2022 19:15:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="g+7/CrFY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 737CC84053; Mon, 11 Jul 2022 19:14:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_FILL_THIS_FORM_SHORT,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.2 Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4FCB284052 for ; Mon, 11 Jul 2022 19:14:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72a.google.com with SMTP id f14so4361587qkm.0 for ; Mon, 11 Jul 2022 10:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sl3A096uYCfbsPnxRLEEZ6zVkYL4575n4bGMrRKwDqw=; b=g+7/CrFYot3hwltF4FzQZvO9++GYELP7JQ/z6cEj99mv4IxTy+KVzRc4X625f0JEAL 9/goJPaqB5bkifkDZUa7+704GAJJwnZBR8Y2tjp8chpsuHcK98P0TmJ0iYOiW3dSRSUf pP8k24UfjuC11Tuf28+6F6NXn9M5qtVlls5dg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sl3A096uYCfbsPnxRLEEZ6zVkYL4575n4bGMrRKwDqw=; b=q678lG/nvSzbrStFZ7g8rvqD1Moc9RcrnBF2Xq+rU7G1S2jH+124MoAopH2pYAgUdY kN8AakgAckqLKfzfT4gcakuNSgR+lh5Fm9rQKsmGabbVQ9jTrMw1jeiY2c3xdPKic3c4 976Ue+UFAtNkeh2m/TCP0j7Uf/NSRVvxHe7gzTsOtfMdvg+3k9p56LQoY1aj+MjGFAFd 9JwBLZbtvOfQBQuARsnTFVOCeAtpgJlqLyaOBEyW/fixpmVe3pRzPSgMe4gDM0TIWrRm ECOK+WtX3xi/03jLLQ6hvQeUFARe0/aLmmVM/FHqByQeF9K6F0/8gCUwI2SemNNAC8PN Gutg== X-Gm-Message-State: AJIora+lB3UjVRBIJa8ncUnAU2Mnqylma29JC4a5Cu7TffpzaKOAQWIs FW3B1a7W31H6oGiLzjR+sX77H+cyOx4TpA== X-Google-Smtp-Source: AGRyM1tS0M/kQDkkswV48FsehLynXBpPtqak+VpHGGoK1MtWEnd4owk+jlsJPCTvJgZ319XeJCHymA== X-Received: by 2002:a05:620a:47a9:b0:6b5:5df7:fffc with SMTP id dt41-20020a05620a47a900b006b55df7fffcmr11905133qkb.536.1657559687636; Mon, 11 Jul 2022 10:14:47 -0700 (PDT) Received: from bill-the-cat.lan (cpe-65-184-195-139.ec.res.rr.com. [65.184.195.139]) by smtp.gmail.com with ESMTPSA id bp20-20020a05622a1b9400b0031ea95094dcsm5519536qtb.72.2022.07.11.10.14.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 10:14:47 -0700 (PDT) From: Tom Rini To: u-boot@lists.denx.de Cc: Claudius Heine , Martin Bonner , Heinrich Schuchardt Subject: [PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section Date: Mon, 11 Jul 2022 13:14:39 -0400 Message-Id: <20220711171439.1657280-7-trini@konsulko.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220711171439.1657280-1-trini@konsulko.com> References: <20220711171439.1657280-1-trini@konsulko.com> MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean The "Workflow of a Custodian" section on the wiki had not been changed in quite some time to reflect how the process has been functioning for some time. First, update some links to point to modern and current sources of information. Second, and more overarching, reword much of the section. This expands on the expectations of both custodians and developers when it comes to rebasing patches. Rework the final points to be clearer that Custodians are expected to do their best to test the changes and ask for help when needed, as well as that pull requests are expected in a timely manner. Cc: Claudius Heine Cc: Martin Bonner Cc: Heinrich Schuchardt Signed-off-by: Tom Rini --- Changes in v2: - New patch --- doc/develop/process.rst | 88 ++++++++++++++++++++--------------------- 1 file changed, 42 insertions(+), 46 deletions(-) diff --git a/doc/develop/process.rst b/doc/develop/process.rst index d0c46b58f3e9..56c9d274be71 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -132,16 +132,20 @@ 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. +#. A developer submits a patch via e-mail to the u-boot mailing list. In + U-Boot, we make use of the `Developer Certificate of Origin + `_ that is common in other projects such + as the Linux kernel. Following this and adding a ``Signed-off-by:`` line + that contains the developer's name and email address is required. -#. Everybody who can is invited to review and test the changes. Reviews should - reply on the mailing list with ``Acked-by`` lines. +#. Everybody who can is invited to review and test the changes. Typically, we + follow the same guidelines as the Linux kernel for `Acked-by + `_ + as well as `Reviewed-by + `_ + and similar additional tags. -#. The responsible custodian - - #. inspects this patch, especially for: +#. The responsible custodian inspects this patch, especially for: #. :doc:`codingstyle` @@ -152,50 +156,42 @@ like this: * The patch does not introduce new problems, especially it does not break other boards or architectures - #. U-Boot Philosophy + #. U-Boot Philosophy, as documented in :doc:`designprinciples`. - #. Applies cleanly to the source tree + #. Applies cleanly to the source tree. The custodian is expected to put in + a "best effort" if a patch does not apply cleanly, but can be made to apply + still. It is up to the custodian to decide how recent of a commit the + patch must be against. It is acceptable to request patches against the + last officially released version of U-Boot or newer. Of course a + custodian can also accept patches against older code. It can be + difficult to find the correct balance between putting too much work on + the custodian or too much work on an individual submitting a patch when + something does not apply cleanly. #. Passes :doc:`ci_testing` as this checks for new warnings and other issues. -#. Notes: - - #. In some cases more than one custodian may be affected or feel responsible. - To avoid duplicated efforts, the custodian who starts processing the - patch should send a short ACK to the mailing list. - - #. We should create some tool to automatically do this. - - #. This is well documented in :doc:`designprinciples`. - - #. The custodian decides themselves how recent the code must be. It is - acceptable to request patches against the last officially released - version of U-Boot or newer. Of course a custodian can also accept - patches against older code. - - #. Commits should show original author in the ``author`` field and include all - sign off/ack lines. - -#. The custodian decides to accept or to reject the patch. - -#. If accepted, the custodian adds the patch to their public git repository and - notifies the mailing list. This note should include: +#. Note that in some cases more than one custodian may feel responsible for a + particular change. To avoid duplicated efforts, the custodian who starts + processing the patch should follow up to the email saying they intend to + pick it up. - * a short description of the changes +#. Commits must show original author in the ``author`` field and include all of + the ``Signed-off-by``, ``Reviewed-by``, etc, tags that have been submitted. - * the list of the affected boards / architectures etc. +#. The final decision to accept or reject a patch comes down to the custodian + in question. - * suggested tests +#. If accepted, the custodian adds the patch to their public git repository. + Ideally, they will also follow up on the mailing list with some notification + that it has been applied. This is not always easy given different custodian + workflows and environments however. - Although the custodian is supposed to perform their own tests - it is a well-known and accepted fact that they needs help from - other developers who - for example - have access to the required - hardware or tool chains. - The custodian request help for tests and feedback from - specific maintainers and U-Boot users. +#. Although a custodian is supposed to perform their own tests it is a + well-known and accepted fact that they needs help from other developers who + - for example - have access to the required hardware or other relevant + environments. Custodians are expected to ask for assistance with testing + when required. -#. Once tests are passed, some agreed time limit expires, the custodian - requests that the changes in their public git repository be merged into the - main tree. If necessary, the custodian may have to adapt their changes to - allow for a clean merge. - Todo: define a reasonable time limit. 3 weeks? +#. Custodians are expected to submit a timely pull request of their git + repository to the main repository. It is strongly encouraged that a CI run + have been complete prior to submission, but not required.