Changes between Version 8 and Version 9 of OSGeoIncubationChecklist

Timestamp:

Feb 7, 2013, 9:32:24 AM (11 years ago)

Author:

abeccati

Comment:

updates on release, testing and governance

OSGeoIncubationChecklist

@@ -41 +41 @@
 == Open ==
 [[Image(http://upload.wikimedia.org/wikipedia/commons/1/1d/Icons-mini-icon_user.gif)]] (A. Beccati - a.beccati .at jacobs-university .dot de ) Project Steering Committee; Consider definition of a PSC to define project direction and overall desired (and undesired) features to better direct development efforts by volunteer contributors.
- * TODO
-  * Requirements collection (ongoing)
-  * open discussion and set up wiki page / tools / process for the PSC
- * REF
-  * example of PSC policy at http://geomoose.org/trunk/rfc/rfc-1.html?highlight=rfc
- * DUE BY undecided
-
+ * STATUS
+  * we have actively been soliciting technical discussion directly through the dev list, puling dev'ers from bilateral communication to the list. Based on these improvements it seems we can keep with the overall regime for now.
+  * we double checked the registration policy to the project trac and mailing lists and verified that these are open for registration although the lists are currently hosted on google groups hence their registration procedure has to be followed
 
  1. Open: projects are expected to function in an open and public manner and include:
@@ -55 +51 @@
    i. rasdaman-user list: https://groups.google.com/forum/?fromgroups#!forum/rasdaman-usersras
    i. issue tracker (trac): http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/report/1
-  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/5/5a/Icons-mini-action_stop.gif)]] Open decision making process: TBD 
+  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] Open decision making process: Feature table is maintained on wiki, new features can be openly discussed on the mailing lists.
  1. Active and healthy community:
   a. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] The project should have a community of developers and users who actively collaborate and support each other in a healthy way.
@@ -90 +86 @@
   a. Trac is used for that purpose and is constantly updated as issues are addressed. Ticket list is at http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/report/1
  1. [[Image(http://upload.wikimedia.org/wikipedia/commons/1/11/Hourglass.png)]] The project has documented its management processes. NOTE: This is typically done within a Developers Guide or Project Management Plan.
-  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/5/5a/Icons-mini-action_stop.gif)]] (looks like duplicate of "Open" item 1.c) The project has a suitable open governance policy ensuring decisions are made, documented and adhered to in a public manner. Note: This typically means a Project Management Committee has been established with a process for adding new members. A robust Project Management Committee will typically draw upon developers, users and key stakeholders from multiple organisations as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
+  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/9/90/Icons-mini-icon_alert.gif)]] (looks like duplicate of "Open" item 1.c) The project has a suitable open governance policy ensuring decisions are made, documented and adhered to in a public manner. Note: This typically means a Project Management Committee has been established with a process for adding new members. A robust Project Management Committee will typically draw upon developers, users and key stakeholders from multiple organisations as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
+  * developers are actively solicited to have technical discussion directly through the dev list. Based on these improvements it seems we can keep with the overall regime for now.
+
   a. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] (duplicate of Open item 1.b) The project uses public communication channels for decision making to maintain transparency. E.g. archived email list(s), archived IRC channel(s), public issue tracker.
 
@@ -117 +115 @@
 In order to maintain a consistent level of quality, the project should follow defined release and testing processes.
 
- 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/1/11/Hourglass.png)]], [[Image(http://upload.wikimedia.org/wikipedia/commons/9/90/Icons-mini-icon_alert.gif)]] The project follows a defined release process: (patch revision in place, release policy review ongoing)
-  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/1/11/Hourglass.png)]], [[Image(http://upload.wikimedia.org/wikipedia/commons/9/90/Icons-mini-icon_alert.gif)]] Which includes execution of the testing process before releasing a stable release. (ongoing effort)
- 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/1/11/Hourglass.png)]], [[Image(http://upload.wikimedia.org/wikipedia/commons/9/90/Icons-mini-icon_alert.gif)]] The project follows a documented testing process. NOTE: Ideally, this includes both automated and manual testing. Ideally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests
- 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/1/11/Hourglass.png)]] Release and testing processes provide sufficient detail for an experienced programmer to follow.
+
+
+
+ 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] The project follows a defined release process: (patch revision in place, release policy review ongoing)
+  a. [[Image(http://upload.wikimedia.org/wikipedia/commons/9/90/Icons-mini-icon_alert.gif)]] (manual process) Which includes execution of the testing process before releasing a stable release.
+  * All patches submitted to the repository undergo review before being applied to the code base
+  * Milestones and tickets are used to prepare releases
+  * Releases adopt semantic versioning (starting from 8.4.0)
+  * Systemtests are to be run by developers before submitting patches (automated test after patch application under work).
+
+ 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] The project follows a documented testing process. NOTE: Ideally, this includes both automated and manual testing. Ideally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests
+  *  Release and regression testing has been improved, also with respect to its documentation on the wiki which is still work in progress but already gives the overall picture of the project's test method with systemtests. We encourage users to download forthcoming betas and run these tests on their environment to see it rasdaman can be successfully run there.
+ 1. [[Image(http://upload.wikimedia.org/wikipedia/commons/c/cc/Icons-mini-icon_accept.gif)]] Release and testing processes provide sufficient detail for an experienced programmer to follow.
+  * Release process makes use of the project trac roadmap feature, paired with the ticket manager. The latter has been extended to support "feature" tickets to ease tracking high-level features and assign them to release milestones. Testing system has been documented on wiki.
+