Message ID | 20230920095318.340582-1-pvorel@suse.cz |
---|---|
Headers | show |
Series | Release scripts and docs | expand |
Hi Petr, All, Thanks for writing down the release procedure, very useful. But I doubt that we really need the scripts to do release work automatically since we _only_ do the release every four months. It seems to bring additional maintenance work unnecessarily. I personally think the manual step is detailed enough for us. But anyway, now you have done the automation, I don't have an objection to your patch set, just feel that we automate for the sake of automation :). I'd like to hear more opinions, but if most of us think the script is necessary, I'm happy to accept them as well. On Wed, Sep 20, 2023 at 5:53 PM Petr Vorel <pvorel@suse.cz> wrote: > Hi, > > copy pasting release is error prone, thus I wrote release scripts. > Any change you would have look on it before release? > > 2 commits were already posted before, Li had some notes about the > procedure, thus I updated it. > > Kind regards, > Petr > > Petr Vorel (5): > tools: Add a script for tagging the release > tools: Add script for creating tarballs and metadata > doc: Rename files to names from ltp.wiki.git > doc: Add Release procedure > doc: Update release procedure > > .github/workflows/wiki-mirror.yml | 16 +-- > ...ild-system-guide.txt => Build-System.rest} | 0 > doc/{c-test-api.txt => C-Test-API.asciidoc} | 0 > ...mple.txt => C-Test-Case-Tutorial.asciidoc} | 0 > ...-c-api.txt => C-Test-Network-API.asciidoc} | 0 > ...kvm-test-api.txt => KVM-Test-API.asciidoc} | 0 > ...P-Library-API-Writing-Guidelines.asciidoc} | 0 > doc/LTP-Release-Procedure.asciidoc | 116 ++++++++++++++++++ > ...aintainer-Patch-Review-Checklist.asciidoc} | 0 > ...l-test-api.txt => Shell-Test-API.asciidoc} | 0 > ...kernel,-libc,-toolchain-versions.asciidoc} | 0 > ...s.txt => Test-Writing-Guidelines.asciidoc} | 0 > ...ser-guide.txt => User-Guidelines.asciidoc} | 0 > tools/create-tarballs-metadata.sh | 52 ++++++++ > tools/lib.sh | 31 +++++ > tools/tag-release.sh | 80 ++++++++++++ > 16 files changed, 282 insertions(+), 13 deletions(-) > rename doc/{build-system-guide.txt => Build-System.rest} (100%) > rename doc/{c-test-api.txt => C-Test-API.asciidoc} (100%) > rename doc/{c-test-tutorial-simple.txt => C-Test-Case-Tutorial.asciidoc} > (100%) > rename doc/{network-c-api.txt => C-Test-Network-API.asciidoc} (100%) > rename doc/{kvm-test-api.txt => KVM-Test-API.asciidoc} (100%) > rename doc/{library-api-writing-guidelines.txt => > LTP-Library-API-Writing-Guidelines.asciidoc} (100%) > create mode 100644 doc/LTP-Release-Procedure.asciidoc > rename doc/{maintainer-patch-review-checklist.txt => > Maintainer-Patch-Review-Checklist.asciidoc} (100%) > rename doc/{shell-test-api.txt => Shell-Test-API.asciidoc} (100%) > rename doc/{supported-kernel-libc-versions.txt => > Supported-kernel,-libc,-toolchain-versions.asciidoc} (100%) > rename doc/{test-writing-guidelines.txt => > Test-Writing-Guidelines.asciidoc} (100%) > rename doc/{user-guide.txt => User-Guidelines.asciidoc} (100%) > create mode 100755 tools/create-tarballs-metadata.sh > create mode 100755 tools/lib.sh > create mode 100755 tools/tag-release.sh > > -- > 2.40.1 > >
On Thu, Sep 21, 2023 at 10:18 AM Li Wang <liwang@redhat.com> wrote: > > Hi Petr, All, > > Thanks for writing down the release procedure, very useful. +1 for having documented steps > > But I doubt that we really need the scripts to do release work > automatically since we _only_ do the release every four months. > It seems to bring additional maintenance work unnecessarily. > > I personally think the manual step is detailed enough for us. > But anyway, now you have done the automation, I don't have > an objection to your patch set, just feel that we automate for the > sake of automation :). > > I'd like to hear more opinions, but if most of us think the script is > necessary, I'm happy to accept them as well. As someone who hasn't done release before, I'd probably do it manually first-time to double-check each step. It's probably not necessary, but people who did releases many times may find it useful - I'm assuming the release procedure isn't changing that frequently. > > > On Wed, Sep 20, 2023 at 5:53 PM Petr Vorel <pvorel@suse.cz> wrote: >> >> Hi, >> >> copy pasting release is error prone, thus I wrote release scripts. >> Any change you would have look on it before release? >> >> 2 commits were already posted before, Li had some notes about the >> procedure, thus I updated it. >> >> Kind regards, >> Petr >> >> Petr Vorel (5): >> tools: Add a script for tagging the release >> tools: Add script for creating tarballs and metadata >> doc: Rename files to names from ltp.wiki.git >> doc: Add Release procedure >> doc: Update release procedure >> >> .github/workflows/wiki-mirror.yml | 16 +-- >> ...ild-system-guide.txt => Build-System.rest} | 0 >> doc/{c-test-api.txt => C-Test-API.asciidoc} | 0 >> ...mple.txt => C-Test-Case-Tutorial.asciidoc} | 0 >> ...-c-api.txt => C-Test-Network-API.asciidoc} | 0 >> ...kvm-test-api.txt => KVM-Test-API.asciidoc} | 0 >> ...P-Library-API-Writing-Guidelines.asciidoc} | 0 >> doc/LTP-Release-Procedure.asciidoc | 116 ++++++++++++++++++ >> ...aintainer-Patch-Review-Checklist.asciidoc} | 0 >> ...l-test-api.txt => Shell-Test-API.asciidoc} | 0 >> ...kernel,-libc,-toolchain-versions.asciidoc} | 0 >> ...s.txt => Test-Writing-Guidelines.asciidoc} | 0 >> ...ser-guide.txt => User-Guidelines.asciidoc} | 0 >> tools/create-tarballs-metadata.sh | 52 ++++++++ >> tools/lib.sh | 31 +++++ >> tools/tag-release.sh | 80 ++++++++++++ >> 16 files changed, 282 insertions(+), 13 deletions(-) >> rename doc/{build-system-guide.txt => Build-System.rest} (100%) >> rename doc/{c-test-api.txt => C-Test-API.asciidoc} (100%) >> rename doc/{c-test-tutorial-simple.txt => C-Test-Case-Tutorial.asciidoc} (100%) >> rename doc/{network-c-api.txt => C-Test-Network-API.asciidoc} (100%) >> rename doc/{kvm-test-api.txt => KVM-Test-API.asciidoc} (100%) >> rename doc/{library-api-writing-guidelines.txt => LTP-Library-API-Writing-Guidelines.asciidoc} (100%) >> create mode 100644 doc/LTP-Release-Procedure.asciidoc >> rename doc/{maintainer-patch-review-checklist.txt => Maintainer-Patch-Review-Checklist.asciidoc} (100%) >> rename doc/{shell-test-api.txt => Shell-Test-API.asciidoc} (100%) >> rename doc/{supported-kernel-libc-versions.txt => Supported-kernel,-libc,-toolchain-versions.asciidoc} (100%) >> rename doc/{test-writing-guidelines.txt => Test-Writing-Guidelines.asciidoc} (100%) >> rename doc/{user-guide.txt => User-Guidelines.asciidoc} (100%) >> create mode 100755 tools/create-tarballs-metadata.sh >> create mode 100755 tools/lib.sh >> create mode 100755 tools/tag-release.sh >> >> -- >> 2.40.1 >> > > > -- > Regards, > Li Wang
Hi Jan, Li, > On Thu, Sep 21, 2023 at 10:18 AM Li Wang <liwang@redhat.com> wrote: > > Hi Petr, All, > > Thanks for writing down the release procedure, very useful. > +1 for having documented steps > > But I doubt that we really need the scripts to do release work > > automatically since we _only_ do the release every four months. > > It seems to bring additional maintenance work unnecessarily. > > I personally think the manual step is detailed enough for us. > > But anyway, now you have done the automation, I don't have > > an objection to your patch set, just feel that we automate for the > > sake of automation :). > > I'd like to hear more opinions, but if most of us think the script is > > necessary, I'm happy to accept them as well. > As someone who hasn't done release before, I'd probably do it > manually first-time to double-check each step. > It's probably not necessary, but people who did releases many times may > find it useful - I'm assuming the release procedure isn't changing > that frequently. Thanks both for your input. Yes. Manual process is error prone. Because I did tagging and tarball generating for last few releases I wanted to avoid re-reading the documentation during each release and speedup the whole process. Because there is a lot of "manual" clicking even without it. BTW the changelog skeleton should be separated to be useful (Cyril does it). Kind regards, Petr > > On Wed, Sep 20, 2023 at 5:53 PM Petr Vorel <pvorel@suse.cz> wrote: > >> Hi, > >> copy pasting release is error prone, thus I wrote release scripts. > >> Any change you would have look on it before release? > >> 2 commits were already posted before, Li had some notes about the > >> procedure, thus I updated it. > >> Kind regards, > >> Petr > >> Petr Vorel (5): > >> tools: Add a script for tagging the release > >> tools: Add script for creating tarballs and metadata > >> doc: Rename files to names from ltp.wiki.git > >> doc: Add Release procedure > >> doc: Update release procedure > >> .github/workflows/wiki-mirror.yml | 16 +-- > >> ...ild-system-guide.txt => Build-System.rest} | 0 > >> doc/{c-test-api.txt => C-Test-API.asciidoc} | 0 > >> ...mple.txt => C-Test-Case-Tutorial.asciidoc} | 0 > >> ...-c-api.txt => C-Test-Network-API.asciidoc} | 0 > >> ...kvm-test-api.txt => KVM-Test-API.asciidoc} | 0 > >> ...P-Library-API-Writing-Guidelines.asciidoc} | 0 > >> doc/LTP-Release-Procedure.asciidoc | 116 ++++++++++++++++++ > >> ...aintainer-Patch-Review-Checklist.asciidoc} | 0 > >> ...l-test-api.txt => Shell-Test-API.asciidoc} | 0 > >> ...kernel,-libc,-toolchain-versions.asciidoc} | 0 > >> ...s.txt => Test-Writing-Guidelines.asciidoc} | 0 > >> ...ser-guide.txt => User-Guidelines.asciidoc} | 0 > >> tools/create-tarballs-metadata.sh | 52 ++++++++ > >> tools/lib.sh | 31 +++++ > >> tools/tag-release.sh | 80 ++++++++++++ > >> 16 files changed, 282 insertions(+), 13 deletions(-) > >> rename doc/{build-system-guide.txt => Build-System.rest} (100%) > >> rename doc/{c-test-api.txt => C-Test-API.asciidoc} (100%) > >> rename doc/{c-test-tutorial-simple.txt => C-Test-Case-Tutorial.asciidoc} (100%) > >> rename doc/{network-c-api.txt => C-Test-Network-API.asciidoc} (100%) > >> rename doc/{kvm-test-api.txt => KVM-Test-API.asciidoc} (100%) > >> rename doc/{library-api-writing-guidelines.txt => LTP-Library-API-Writing-Guidelines.asciidoc} (100%) > >> create mode 100644 doc/LTP-Release-Procedure.asciidoc > >> rename doc/{maintainer-patch-review-checklist.txt => Maintainer-Patch-Review-Checklist.asciidoc} (100%) > >> rename doc/{shell-test-api.txt => Shell-Test-API.asciidoc} (100%) > >> rename doc/{supported-kernel-libc-versions.txt => Supported-kernel,-libc,-toolchain-versions.asciidoc} (100%) > >> rename doc/{test-writing-guidelines.txt => Test-Writing-Guidelines.asciidoc} (100%) > >> rename doc/{user-guide.txt => User-Guidelines.asciidoc} (100%) > >> create mode 100755 tools/create-tarballs-metadata.sh > >> create mode 100755 tools/lib.sh > >> create mode 100755 tools/tag-release.sh > >> -- > >> 2.40.1 > > -- > > Regards, > > Li Wang
Hi! > > But I doubt that we really need the scripts to do release work > > automatically since we _only_ do the release every four months. > > It seems to bring additional maintenance work unnecessarily. > > > > I personally think the manual step is detailed enough for us. > > But anyway, now you have done the automation, I don't have > > an objection to your patch set, just feel that we automate for the > > sake of automation :). > > > > I'd like to hear more opinions, but if most of us think the script is > > necessary, I'm happy to accept them as well. > > As someone who hasn't done release before, I'd probably do it > manually first-time to double-check each step. > > It's probably not necessary, but people who did releases many times may > find it useful - I'm assuming the release procedure isn't changing > that frequently. I do have a similar script to tag git and release tarballs, doing that manually every time is really error prone, so it's good idea to include these in the repository.
Hi!
> BTW the changelog skeleton should be separated to be useful (Cyril does it).
I do not think that we can ever automate the changelog creation, it's
manual process that requires reading patch description for all the
patches, understanding what is there and writing down something based on
that. Even the credits section usually needs some hand fixes, since
there are typos, different emails and so on in the git tags.
> Hi! > > > But I doubt that we really need the scripts to do release work > > > automatically since we _only_ do the release every four months. > > > It seems to bring additional maintenance work unnecessarily. > > > I personally think the manual step is detailed enough for us. > > > But anyway, now you have done the automation, I don't have > > > an objection to your patch set, just feel that we automate for the > > > sake of automation :). > > > I'd like to hear more opinions, but if most of us think the script is > > > necessary, I'm happy to accept them as well. > > As someone who hasn't done release before, I'd probably do it > > manually first-time to double-check each step. > > It's probably not necessary, but people who did releases many times may > > find it useful - I'm assuming the release procedure isn't changing > > that frequently. > I do have a similar script to tag git and release tarballs, doing that > manually every time is really error prone, so it's good idea to include > these in the repository. Thanks for your feedback. Of course, I'm open to any concerns about the actual implementation. Kind regards, Petr
> Hi! > > BTW the changelog skeleton should be separated to be useful (Cyril does it). > I do not think that we can ever automate the changelog creation, it's > manual process that requires reading patch description for all the > patches, understanding what is there and writing down something based on > that. Even the credits section usually needs some hand fixes, since > there are typos, different emails and so on in the git tags. OK, I remove skeleton creation and add it to docs in v2. Fixing emails is needed because people have wrong setup. Feel free to ping these people to fix their setup. Kind regards, Petr
Hi! > OK, I remove skeleton creation and add it to docs in v2. > > Fixing emails is needed because people have wrong setup. Feel free to ping these > people to fix their setup. It's mostly typos in the Signed-off-by: and Reviewed-by: tags that are not caught during the review...