From e663d2ea5fd4b5e930b195fa3e69ab6e90188102 Mon Sep 17 00:00:00 2001 From: Anna Petrasova Date: Wed, 8 Feb 2023 22:42:19 -0500 Subject: [PATCH 1/4] RFC: Errata --- doc/development/rfc/errata.md | 50 +++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 doc/development/rfc/errata.md diff --git a/doc/development/rfc/errata.md b/doc/development/rfc/errata.md new file mode 100644 index 00000000000..cbd85aa7899 --- /dev/null +++ b/doc/development/rfc/errata.md @@ -0,0 +1,50 @@ +# RFC 5: GRASS GIS Errata + +Author of the first draft: Māris Nartišs + +Status: Early draft (19 Mar 2016) + +## Introduction + +GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code. + +## Overall process + +1. Any bug reporter or developer can nominate a bug for escalating to GRASS GIS erratum issue. Nomination is done by adding a notice to bug at bug tracker or discussing directly at developer mailing list. Any nomination is discussed in developer mailing list to gather necessary information on it's scope, impact, causes and solutions. + +2. GRASS PSC evaluates nomination based on information provided by bug report, discussion in developer mailing list and/or other sources. PSC makes a final decision if nominated bug matches criteria of issuing a GRASS GIS erratum. + +3. A draft of erratum text is made in a designated area of developer wiki (issue tracker) holding texts of all published GRASS GIS errata. + +4. After a review of at least one more person, the erratum is marked as final one and spread via communication channels. + +### Evaluation criteria + + * Bug must be present in an official GRASS GIS release. + * Bug must cause generation of incorrect analysis results that are not so easy to notice. +Module crashes or bugs causing easy to identify incorrect results should not be given an erratum. Examples of possible erratum worth bugs are single cell shift of raster result, not enough randomness of expected random module output, loss of output precision due to incorrect floating point handling etc. + +### Content and life cycle of an Erratum + +GRASS GIS Erratum message should contain following elements: + * it's number; + * date of issue; + * name(s) of affected module(s); + * information about affected release(s); + * a short description of problem; + * steps resulting in incorrect output (i.e. specific input parameter combination); + * current state of problem (in progress, fixed for release x.y.z); + * references to bug report (Trac bug number), developer mailing list thread; + * any other information relevant to erratum. + +GRASS GIS errata might receive updates, if it's found to be necessary +(i.e. notice of fixing issue, issue scope update etc.). + +### Spreading the word + +All GRASS GIS errata texts should be available at two places - developer wiki (Trac) and ERRATA file of any upcoming release. +Errata should be listed in time descending order (latest on the top). + +If the erratum was based on a bug report in issue tracker, a notice to the issue report should be added. + +Announcement of the erratum should be sent out to XXXX mailing list. From 461441c3a7f307603a1f7fcdd5ae73f5f876a717 Mon Sep 17 00:00:00 2001 From: Anna Petrasova Date: Thu, 9 Feb 2023 09:43:01 -0500 Subject: [PATCH 2/4] linting --- doc/development/rfc/errata.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/doc/development/rfc/errata.md b/doc/development/rfc/errata.md index cbd85aa7899..40da2dff6ff 100644 --- a/doc/development/rfc/errata.md +++ b/doc/development/rfc/errata.md @@ -6,7 +6,8 @@ Status: Early draft (19 Mar 2016) ## Introduction -GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code. +GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. +This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code. ## Overall process @@ -20,22 +21,23 @@ GRASS GIS is widely used in scientific, private and government sector. Scientifi ### Evaluation criteria - * Bug must be present in an official GRASS GIS release. - * Bug must cause generation of incorrect analysis results that are not so easy to notice. +* Bug must be present in an official GRASS GIS release. +* Bug must cause generation of incorrect analysis results that are not so easy to notice. Module crashes or bugs causing easy to identify incorrect results should not be given an erratum. Examples of possible erratum worth bugs are single cell shift of raster result, not enough randomness of expected random module output, loss of output precision due to incorrect floating point handling etc. ### Content and life cycle of an Erratum GRASS GIS Erratum message should contain following elements: - * it's number; - * date of issue; - * name(s) of affected module(s); - * information about affected release(s); - * a short description of problem; - * steps resulting in incorrect output (i.e. specific input parameter combination); - * current state of problem (in progress, fixed for release x.y.z); - * references to bug report (Trac bug number), developer mailing list thread; - * any other information relevant to erratum. + +* it's number; +* date of issue; +* name(s) of affected module(s); +* information about affected release(s); +* a short description of problem; +* steps resulting in incorrect output (i.e. specific input parameter combination); +* current state of problem (in progress, fixed for release x.y.z); +* references to bug report (Trac bug number), developer mailing list thread; +* any other information relevant to erratum. GRASS GIS errata might receive updates, if it's found to be necessary (i.e. notice of fixing issue, issue scope update etc.). From b3fcd7444b7fffc5361408323e8405dd3c8ba842 Mon Sep 17 00:00:00 2001 From: Anna Petrasova Date: Thu, 9 Feb 2023 10:09:52 -0500 Subject: [PATCH 3/4] linting --- doc/development/rfc/errata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/development/rfc/errata.md b/doc/development/rfc/errata.md index 40da2dff6ff..a7075f46fb3 100644 --- a/doc/development/rfc/errata.md +++ b/doc/development/rfc/errata.md @@ -6,7 +6,7 @@ Status: Early draft (19 Mar 2016) ## Introduction -GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. +GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code. ## Overall process From 00ff550839fb46fc8abc1af5092aa5c40501729c Mon Sep 17 00:00:00 2001 From: Nicklas Larsson Date: Tue, 28 Feb 2023 20:40:47 +0100 Subject: [PATCH 4/4] limit line width to 80 cols --- doc/development/rfc/errata.md | 40 +++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/doc/development/rfc/errata.md b/doc/development/rfc/errata.md index a7075f46fb3..45d53f6ec37 100644 --- a/doc/development/rfc/errata.md +++ b/doc/development/rfc/errata.md @@ -6,24 +6,40 @@ Status: Early draft (19 Mar 2016) ## Introduction -GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. -This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code. +GRASS GIS is widely used in scientific, private and government sector. +Scientific theories, environmental decisions and actions depend on the outcome +of spatial analysis performed with GRASS GIS. Any errors in analytical modules +might lead to erroneous conclusions and actions based on them. This RFC +provides a framework of documenting and spreading information on analysis +inaccuracies caused by errors in GRASS GIS code. ## Overall process -1. Any bug reporter or developer can nominate a bug for escalating to GRASS GIS erratum issue. Nomination is done by adding a notice to bug at bug tracker or discussing directly at developer mailing list. Any nomination is discussed in developer mailing list to gather necessary information on it's scope, impact, causes and solutions. +1. Any bug reporter or developer can nominate a bug for escalating to GRASS GIS + erratum issue. Nomination is done by adding a notice to bug at bug tracker + or discussing directly at developer mailing list. Any nomination is + discussed in developer mailing list to gather necessary information on it's + scope, impact, causes and solutions. -2. GRASS PSC evaluates nomination based on information provided by bug report, discussion in developer mailing list and/or other sources. PSC makes a final decision if nominated bug matches criteria of issuing a GRASS GIS erratum. +2. GRASS PSC evaluates nomination based on information provided by bug report, + discussion in developer mailing list and/or other sources. PSC makes a final + decision if nominated bug matches criteria of issuing a GRASS GIS erratum. -3. A draft of erratum text is made in a designated area of developer wiki (issue tracker) holding texts of all published GRASS GIS errata. +3. A draft of erratum text is made in a designated area of developer wiki + (issue tracker) holding texts of all published GRASS GIS errata. -4. After a review of at least one more person, the erratum is marked as final one and spread via communication channels. +4. After a review of at least one more person, the erratum is marked as final + one and spread via communication channels. ### Evaluation criteria * Bug must be present in an official GRASS GIS release. -* Bug must cause generation of incorrect analysis results that are not so easy to notice. -Module crashes or bugs causing easy to identify incorrect results should not be given an erratum. Examples of possible erratum worth bugs are single cell shift of raster result, not enough randomness of expected random module output, loss of output precision due to incorrect floating point handling etc. +* Bug must cause generation of incorrect analysis results that are not so easy + to notice. Module crashes or bugs causing easy to identify incorrect results + should not be given an erratum. Examples of possible erratum worth bugs are + single cell shift of raster result, not enough randomness of expected random + module output, loss of output precision due to incorrect floating point + handling etc. ### Content and life cycle of an Erratum @@ -44,9 +60,11 @@ GRASS GIS errata might receive updates, if it's found to be necessary ### Spreading the word -All GRASS GIS errata texts should be available at two places - developer wiki (Trac) and ERRATA file of any upcoming release. -Errata should be listed in time descending order (latest on the top). +All GRASS GIS errata texts should be available at two places - developer wiki +(Trac) and ERRATA file of any upcoming release. Errata should be listed in time +descending order (latest on the top). -If the erratum was based on a bug report in issue tracker, a notice to the issue report should be added. +If the erratum was based on a bug report in issue tracker, a notice to the +issue report should be added. Announcement of the erratum should be sent out to XXXX mailing list.