On 08/01/2012 12:43 AM, Chris Evich wrote:
On 07/30/2012 02:52 PM, Lucas Meneghel Rodrigues wrote:
IMO, a tracking issue with references to the other issues seems good
enough, and it updates automatically (every time you refresh the
contents github queries the states of the referred issues). It seems
the better compromise.
All,
I spoke with cleber and lucas, and I think we have a solution that
will scale and help prevent us from duplicating work. We'll keep it
all within github and the mailing list but documented on the wiki.
Here's our idea (please give feedback), hopefully it looks simple and
boring :)
I think it should be a common workflow not just libvirt test.
Pic:
Tracking Issue
^
|
|
+------------+------------+------------+
| | | |
| | | |
Topic-Issue Topic-Issue Topic-Issue Topic-Issue
(Assigned) (Assigned) (open) (closed)
^ ^ ^
| | |
| | |
Pull Req. Mail Thread(s) Pull Req.
(open) (closed)
Yeah, Pull requests (Fork & Pull model) should be useful for monitoring
project status.
+1
Detail:
+ I'll open up a "tracking" issue on github and publish the number.
+ We can all monitor this for available and in-progress items.
+ It will be automatically updated, little/no maintenance required.
+ No discussion should be posted, it all happens in topic-issues
(below)
+ For each proposed test or enhancement, a github (topic) issue is
opened.
+ Summarize the proposed test/enhancement
+ Put 'future' label + topic label (virt-libvirt, client, etc.)
+ In issue description, mention "tracking issue #<number>"
+ The tracking issue will automatically be updated by the topic-
issues that mention "Adding to tracking issue #<number>",
providing back-links ownership and status.
+ Coding can, but doesn't need to start right away. Issues in
"open" status are free for the taking. Issues in "assigned"
status are actively being worked.
+ "Assigned" issues that go stale (no code posted w/in weeks/months)
can be moved back into "open" and/or be re-assigned as needed.
+ Start Coding, publish work:
+ Use the tracking issue to find the topic-issue in open,
unassigned status (create new one if needed).
+ Assign the topic-issue to yourself or someone your working with.
(or ask to be assigned on IRC or by mail).
+ Publish Option 1: Pull Request:
+ Open pull request on github
https://help.github.com/articles/using-pull-requests
+ Within pull-request description, mention:
"topic-issue #<number>"
+ Forward and back-links to pull request will automatically be
added to the topic-issue.
+ Comments/Code review can happen directly in pull request.
+ Ongoing revisions / code commits pushed up to fork'd topic-
branch will automatically update in the pull request.
+ Publish Option 2: Mailing List:
+ Use git send-email to mail patchset (use cover letter if it's
involving more than 2 patches).
+ Look up your mail in mailman archive and copy it's url.
https://www.redhat.com/archives/autotest-kernel/
+ Add comment to topic-issue pointing to the mail URL
+ Comments/Code review happens on mailing list
+ Future revisions result in new mail and further URLs
pasted into topic-issue.
+ Code is committed to next/main branch
+ topic-issue is marked "closed"
+ tracking issue auto-updates with topic-issue status
+ topic-issue can be re-opened if needed (ever)
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
