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 mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
