[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lilypond Issue handling system draft requirements
From: |
Urs Liska |
Subject: |
Re: Lilypond Issue handling system draft requirements |
Date: |
Mon, 04 May 2015 18:29:51 +0200 |
User-agent: |
K-9 Mail for Android |
Sorry if this raises old stuff again.
For me many of your requirwments could be rather easily (and partially
automatically ) be handled with an integrated system of code, review and
issues, i.e. a system that provides something like pull requests.
In addition to many of your list items this would also make it natural that the
reviewed code *is* the merged.
Urs
Am 4. Mai 2015 16:57:03 MESZ, schrieb Phil Holmes <address@hidden>:
>As promised, a starter list of requirements for the issue handling
>system,
>to allow us to check potential replacements to Google code.
>
>
>1. Allow creation of a new sequentially numbered issue, with
>text describing the issue’s title and details
>2. Allow tagging the issue with a range of types
>(e.g. Type-Critical = Defect which blocks a stable release,
>Type-Maintainability = Hinders future development)
>3. Allow tagging the issue with life-cycle stages
>(e.g. Accepted, started, fixed)
>4. Allow tagging issues with patch status
>5. Allow display of issues at different lifecycle stages
>(issues open, issues to be verified, all issues)
>6. Allow display of issues of different types
>(e.g. Critical, Documentation, …)
>7. Allow image attachment and display
>8. Allow non-image attachments
>9. Prevent non-registered users from adding issues
>10. Allow registered admins to add users
>11. Allow users to add comments to existing issues
>12. Provide an API to allow patchy to find issues with new patches,
>to detect the URL with the Rietveld link and to update the patch status
>
>once the patch is tested
>13. Provide an API for git-cl to allow automatic creation of issues
>to track patches.
>14. Allow export of the issue database in CSV form
>15. Allow issues to be closed as duplicates
>16. Allow issues to be blocked by other issues
>17. Email updates to (preferably) address@hidden
>18. Allow users to watch an issue and be informed of updates by email
>_______________________________________________
>lilypond-devel mailing list
>address@hidden
>https://lists.gnu.org/mailman/listinfo/lilypond-devel