Contributing Source Code to OpenPetra.org: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
(→‎Tracking of Bugs and Things to do: using Github issues instead of Mantis)
 
(4 intermediate revisions by the same user not shown)
Line 11: Line 11:


''When you file bugs or request features please make sure that you are following our [[Mini-guide for Bug reporting]]!''
''When you file bugs or request features please make sure that you are following our [[Mini-guide for Bug reporting]]!''
== OM Internal issue tracker Mantis ==
This is not public anymore, and the information is only kept here for reference of the OM development team.
===Workflow of bugs and features in Mantis bug tracker ===
Mantis provides the following status codes to keep track of a bug or a feature:<br>
New, feedback, acknowledged, confirmed, assigned, resolved, closed.<br>
The possible values for the next status are shown in the diagram below.
:'''current status: possible next status codes'''
:*New: feedback, acknowledged, confirmed, assigned, resolved, closed
:*Feedback: acknowledged, confirmed, assigned, resolved, closed
:*Acknowledged: feedback, confirmed, assigned, resolved, closed.
:*Confirmed: feedback, assigned, resolved, closed
:*Assigned: feedback, completed, resolved, closed
:*Completed: feedback, resolved, closed
:*Resolved: feedback(reopened), assigned, tested, closed
:*Tested: feedback(reopened), approved, closed
:*Approved: feedback(reopened), resolved(retest), closed
:*Closed: feedback(reopened), assigned, resolved(retest)
====Workflow for Resolving a Bug (Mainly For Developers)====
* When you (are fairly certain that you) have fixed the issue that the Bug is about and have committed the fix for it to a Branch of the Bazaar code repository then first set the Bug to 'completed'.
** Add any comment that may be helpful (e.g. on how the fix was done) plus any tips for testers on how to test the fix or other special instructions for them (when appropriate) already at this stage!
* Once the Branch in which the Bug got fixed by you got merged into trunk set the Bug to 'resolved'. When you do this please observe the following:
** Add a hyperlink to the Launchpad web page in the 'Commit Link' field that shows the exact trunk revision that your branch got merged into trunk.  Example: https://bazaar.launchpad.net/~openpetracore/openpetraorg/trunkhosted/revision/3128
** Choose the 'Fixed in Version' from the ComboBox as follows:
*** Pick the Version that is topmost in the ComboBox to signalise that this resolved Bug was one that mattered to users / was visible to users / that was reported by users originally  - that Version will always be ending with an ''even number''.  Example 'Beta1 0.6.2'
*** If you want to record that the Bug that that was resolved is about something that the users didn't know about or was a 'technical', 'under the hood' problem that didn't affect the users (much), or that crept up between the last release and this release and hence the users were never exposed to it, then set the Fixed in Version to the first version below the topmost Version - that Version will always be ending with an ''uneven number'' followed by ' Dev'.  Example: 'Beta1 0.6.1 Dev'.
** Note on the Versions that are presented in the 'Fixed in Version' ComboBox: some Versions will be shown with a leading Project name, e.g. '[Core Modules]', and that can be confusing. That is apparently down to some quirk / 'feature' of how Projects are organised in Mantis. I think MatthiasS once looked into it but found no (or no quick) solution to it...
** Add any comment that is helpful.
*** If the bug was first set to completed and then to resolved (as suggested above) then it can be helpful to tell the testers that this Bug is now in trunk and hence that they can now test the fix.
** It isn't necessary to re-assign the Bug to the bug reporter or the tracker user that was last involved in the bug - the Test Department will pick up fixed bugs and deal with the testing and the priority in which bugs will get tested by themselves and in their own time!
*** Also, the bug reporter will automatically get notified by Mantis that you have resolved the bug (see next paragraph).
====Workflow once a Bug/Feature gets Resolved====
The person who reported the bug gets emails sent by Mantis about every change to a bug or feature (e.g. Note added, Status changed). <br>
When that person gets an email that notifies him/her about the fact that the bug/feature's status has changed to 'resolved', <br>
that person can then make sure that the fix is providing the desired functionality. <br>
If this person does not have the skills or equipment to fully test the bugfix/new feature, the bug needs to be passed on to a qualified person within the OpenPetra team, <br>
who will then consult specialists from the business departments if needed. This 'passing on' is done using the 'Assign To' button on a bug. <br>
However, Reporters (as opposed to Developers or Administrators) don't have access to that facility; they just can add a Note and the developer gets notified via email <br>
about that fact, and if the developer needs to pass the bug on, he/she needs to use the 'Assign To' button on that bug for that.
===Special workflow for features related to the project plan===
The severity of a bug can be set to “feature” declaring it as a feature rather than a bug.<br>
We plan to over the time enter all of the major project plan tasks as features into Mantis. <br>
These features will have the field ProjectPlanID set to its corresponding ID from the main project plan. <br>
If an issue is classified as a feature and has been given a ProjectPlanID, a special workflow applies .<br>
Once the feature has reached the status resolved, it should then be moved to a different queue for testing.<br>
This is done by “move issue” in Mantis. There are subprojects provided for testing related to each of the modules.<br>
Moving the feature to one of these subprojects will make it obvious that this issue is ready for testing. <br>
Only features in status "resolved" are ready to be tested.<br>
If the test fails, the issue will have to be reopened which means the status will be set to “feedback”. <br>
There might be either known or new bugs related to this feature. If so, these relationships should be made known in Mantis, too.<br>
That way the feature can only be closed if all its children are closed as well. This makes it possible to track the completeness<br>
of a feature. The bugfixes should be tested first before the complete feature is marked as resolved again and a final test is done.<br>
The feature remains in the test queue. Once the issue has been successfully tested and approved, it is set to closed<br>
and moved back to its original queue. The original queue can be found in the history of this feature.<br>
===Tools for automatic mass processing of Mantis Bugs===
We have two tools that allow us to do efficient mass-processing of bugs.
* [[Releases and Patching#Mantis_Tracker_2|MantisUpdateVersions.exe]]
** it can set the 'Version Fixed In' for ''resolved'' Bugs. The bug numbers are passed in on the command line.
** it can add the 'Next Release' all projects in Mantis
* MantisCloseBugs.exe
** it can close Bugs in Mantis based on input from an CSV file.
** Usage: (1) Filter the desired Bugs in Mantis as follows: status=resolved, 'Fixed in Version': select all versions before a certain version (e.g. Alpha 0.2.20). (2) Export the list of Bugs as CSV file. (3) Run this tool with the export file as an input and the Version that you chose to not be included anymore (e.g. Alpha 0.2.20.) The tool will set all those bugs to closed and add a Note to each Bug that this was done by an automatic process.


==Questions and Discussions==
==Questions and Discussions==
For questions and discussions there are two places where this should happen:
Questions and discussions should happen in the '''Forum'''. It can be found here: [https://forum.openpetra.org/t/developer-area Developer Forum]
* Questions and discussions which should be trackable over time and might lateron shed light on how decisions were made in the project:
** Those discussions should happen in the '''Forum'''. It can be found here: [http://sourceforge.net/apps/phpbb/openpetraorg/viewforum.php?f=3&start=0 Developer Forum]
* Questions and discussions which are about short-lived things or problems and where it isn't necessary to have a record of:
** Those should happen on our '''IRC Channel'''. It can be found on irc.freenode.net in room #OpenPetra
 


==Documentation==
==Documentation==
Line 97: Line 22:
** documents outside the wiki might become forgotten on the local machine of a developer (or on a network drive) and no-one else will have (easy) access to them
** documents outside the wiki might become forgotten on the local machine of a developer (or on a network drive) and no-one else will have (easy) access to them


 
==Contributing Code and Patches==
==Bazaar Source Code Repository and Patches==
See [[Submitting patches and features]] for more information.
* 3 of the ''Core developers'' have write access to the Bazaar code repository of OpenPetra hosted at Launchpad ([https://code.launchpad.net/openpetraorg lp:openpetraorg]).
* ''New developers'' should ask for a mentor. See [[Submitting patches and features]] for more information.
* ''Occasional developers'' need to
# check out the Bazaar repository from [https://code.launchpad.net/openpetraorg lp:openpetraorg]
# or even better create a branch on [http://launchpad.net/ Launchpad] for themselves for the change. Add a patch to the bug tracker record at http://tracker.openpetra.org/ or add the link to the bazaar branch at http://launchpad.net/


==Copyright of Contributions==
==Copyright of Contributions==
We need to still discuss how we deal with the copyright of contributions. See also the discussion on this blog about [http://blogs.gnome.org/bolsh/2009/04/08/copyright-assignment-and-other-barriers-to-entry/ copyright assignment]. <br />
We need to still discuss how we deal with the copyright of contributions. See also the discussion on this blog about [http://blogs.gnome.org/bolsh/2009/04/08/copyright-assignment-and-other-barriers-to-entry/ copyright assignment]. <br />
Please let us know what you would prefer! OM is a charity, and it might be a good copyright holder to make relicensing easier. But if that is a big problem for you, please let us know, and we can discuss it.
Please let us know what you would prefer! OM is a charity, and it might be a good copyright holder to make relicensing easier. But if that is a big problem for you, please let us know, and we can discuss it.

Latest revision as of 19:33, 4 November 2020

Tracking of Bugs and Things to do

We are managing the projects, todo lists, feature requests, and bugs all in one place, at Github issues.

Github issues Information

We use Github issues for tracking of those things. You can get there via this link: https://github.com/openpetra/openpetra/issues

These issues are public, i.e. everyone with web access can get to it and see the Bugs.

  • The fact that the issue tracking system for OpenPetra is public needs to be kept in mind when filing bugs or adding information and attachments and screenshots!

Before you record something you think is not working, or does not seem what you think it ought to do, or if the application issues an error dialog, please have a look if someone already posted a similar issue.

When you file bugs or request features please make sure that you are following our Mini-guide for Bug reporting!

Questions and Discussions

Questions and discussions should happen in the Forum. It can be found here: Developer Forum

Documentation

  • Technical details of an implementation in OpenPetra should always be documented in this OpenPetra wiki.
  • Do not use documents (of any file format) for documentation of technical details of an implementation in OpenPetra, because
    • the wiki should be the single central source of information about OpenPetra
    • documents in various file formats don't usually have a change history, but the wiki keeps track of the change history
    • documents outside the wiki might become forgotten on the local machine of a developer (or on a network drive) and no-one else will have (easy) access to them

Contributing Code and Patches

See Submitting patches and features for more information.

Copyright of Contributions

We need to still discuss how we deal with the copyright of contributions. See also the discussion on this blog about copyright assignment.
Please let us know what you would prefer! OM is a charity, and it might be a good copyright holder to make relicensing easier. But if that is a big problem for you, please let us know, and we can discuss it.

Retrieved from ‘https://wiki.openpetra.org/index.php?title=Contributing_Source_Code_to_OpenPetra.org&oldid=4864’