Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job. In the release notes, 4 info from BZ are used: - bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc. A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug. In order to improve the readability and usefulness of release notes, couldn't we: - Try to normalize and improve the bug summary field when the patch is pushed to master - Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary.
Le 02/12/2015 18:00, Frédéric Demians a écrit :
- Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary. l like this idea a lot !!! (even if it will require more work, it will improve readability of the Release Notes)
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
On Wed, Dec 2, 2015 at 12:09 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 02/12/2015 18:00, Frédéric Demians a écrit :
- Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary.
l like this idea a lot !!! (even if it will require more work, it will improve readability of the Release Notes)
+1 Kind regards, Chris
+1 2015-12-02 14:00 GMT-03:00 Frédéric Demians <frederic@tamil.fr>:
Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job.
In the release notes, 4 info from BZ are used:
- bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc.
A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug.
In order to improve the readability and usefulness of release notes, couldn't we:
- Try to normalize and improve the bug summary field when the patch is pushed to master
- Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
+1 On Wed, Dec 2, 2015 at 11:31 AM Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
+1
2015-12-02 14:00 GMT-03:00 Frédéric Demians <frederic@tamil.fr>:
Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job.
In the release notes, 4 info from BZ are used:
- bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc.
A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug.
In order to improve the readability and usefulness of release notes, couldn't we:
- Try to normalize and improve the bug summary field when the patch is pushed to master
- Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Heather Braum NExpress Coordinator Resource Sharing Librarian Northeast Kansas Library System hbraum@nekls.org "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn." ~Alvin Toffler, *Rethinking the Future*
+1 (for the BZ custom field for release notes) Regards Marc Véron Mitglied Koha Support Schweiz www.koha-support.ch --- marc veron ag informatik information internet Baslerstrasse 50 CH - 4123 Allschwil +41 61 483 84 61 www.veron.ch Am 02.12.2015 um 18:00 schrieb Frédéric Demians:
Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job.
In the release notes, 4 info from BZ are used:
- bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc.
A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug.
In order to improve the readability and usefulness of release notes, couldn't we:
- Try to normalize and improve the bug summary field when the patch is pushed to master
- Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I've already refactored the script used by RM/RMaint to generate release notes in order to use Bugzilla web services. This way retrieving a Bugzilla new field couldn't be easier. So if Chris (or another BZ admins) would want to add a "release notes" field to BZ, I could test it quickly. Kind regards,
participants (6)
-
Christopher Nighswonger -
Frédéric Demians -
Heather Braum (NEKLS) -
Marc Véron -
Paul Poulain -
Tomas Cohen Arazi