From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 83C071B154 for ; Fri, 5 Oct 2018 17:17:18 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C55693082E0F; Fri, 5 Oct 2018 15:17:17 +0000 (UTC) Received: from ktraynor.remote.csb (unknown [10.36.118.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5689C6246B; Fri, 5 Oct 2018 15:17:16 +0000 (UTC) From: Kevin Traynor To: stable@dpdk.org, bluca@debian.org Cc: yskoh@mellanox.com, christian.ehrhardt@canonical.com, Kevin Traynor Date: Fri, 5 Oct 2018 16:17:11 +0100 Message-Id: <20181005151711.21130-1-ktraynor@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 05 Oct 2018 15:17:17 +0000 (UTC) Subject: [dpdk-stable] [PATCH stable-scripts] README: General updates X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 15:17:18 -0000 - re-order 1-import into a more natural flow of sub-steps - add additional details about various steps - remove that typos should not be backported - few spelling/grammar fixes Signed-off-by: Kevin Traynor --- README | 61 ++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 38 insertions(+), 23 deletions(-) diff --git a/README b/README index 2d4cc59..fc1bc5d 100644 --- a/README +++ b/README @@ -11,34 +11,33 @@ both remotes fully fetched. 0-set-stable-release --------------------- +==================== Set the current stable release you want to work on. With that, you -don't need to provide the stable release info for following scripts. +don't need to provide the stable release info for following scripts. e.g. -It will also create a local directory that will be used as tmp dir for -the patches and mails. + $ 0-set-stable-release 18.08.1 + +It will also create a local directory with the release name that will be used +as tmp dir for the patches and mails. 1-import --------- +======== -Import stable/LTS release candidates from the upstream. The usage is: - - $ 1-import commit-list - -Where, the commit list should be provided from the "git-log-fixes.sh" -script from DPDK. Assuming v17.11-rc1 is out and I then could prepare -patches for v17.08.1 stable release, I normally do: +1.A +--- +A list of commits to backport should be generated. This can be generated +from "git-log-fixes.sh" script from DPDK. Assuming v17.11-rc1 is out +you can prepare a commit list for v17.08.1 stable release with: $ ./devtools/git-log-fixes.sh v17.08..v17.11-rc1 > /tmp/list -I then will check the generated list and edit it manually if necessary, +You can then check the generated list and edit it manually if necessary, say removing some false commits. Notably, they are: -- typo fixes - some fixes for PMD base code (the base code is more about firmware, more attention should be payed to carry them to a stable/LTS release, with the mind it won't break the old DPDK with old firmware). - some commits changed ABI/API but somehow still got a "CC stable" tag -- commits that fix a issue introduced at a later version. For example, +- commits that fix an issue introduced at a later version. For example, for v16.11 LTS release, we definitely should not backport a commit from v17.11 (which meant to fix an bug introduced from v17.08). @@ -46,17 +45,31 @@ say removing some false commits. Notably, they are: that automatically. -Note: if this is the first time a particular release gets a stable branch -XX.YY.1 then you'll need to check out a branch for it based on the release tag. -For example for 18.05 you'd do like: +1.B +--- +If this is the first time a particular release gets a stable release +(i.e. XX.YY.1) then you'll need to check out a branch for it based on +the release tag. For example for 18.05 you'd do like: $ git checkout v18.05 # check this really is what you want to base on $ git checkout -b 18.05 +1.C +--- +Import stable/LTS release candidates from the upstream that was generated +from "git-log-fixes.sh". The usage is: + + $ 1-import commit-list + +This will apply the commits in commit-list onto the correct stable branch. +It will also create succeeded-list and failed-list files in the +stable-scripts/ directory with the list of patches that have or +have not been applied. + 2-send-notice -------------- +============= Send a notice to the original author that your commits have been queued for a stable/LTS release. This is also for asking confirmation, something -if you thin it's a bad idea to have them in a stable/LTS release, please +if you think it's a bad idea to have them in a stable/LTS release, please let me know. @@ -65,7 +78,9 @@ The usage is: $ 2-send-notice stable_commit_range +This will create .patch files located in stable-scripts//mail which can +then be sent with git send-email to the authors and stable@dpdk.org. 3-request-backport ------------------- +================== Send a notice to the original authors when a backport is needed: the code @@ -80,5 +95,5 @@ Where, the failed-list is generated from "1-import". 4-final-review --------------- +============== To send a final notice to stable and DPDK ML (note that 2-send-notice @@ -102,5 +117,5 @@ when necessary (say, leaving more time for review) and send it out. 5-make-release-commit ---------------------- +===================== When all are ready, it's time to make the release commit, which basically -- 2.9.5