* Chris Evich <cev...@redhat.com> [2012-07-31 12:43:15]: > 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 :) >
This looks better. Lucas, Folks started sending ppc64 KVM-Autotest/Libvirt-Autotest. We need to find a better way to maintain/port these patches for ppc64. --Pradeep > > Pic: > > Tracking Issue > ^ > | > | > +------------+------------+------------+ > | | | | > | | | | > Topic-Issue Topic-Issue Topic-Issue Topic-Issue > (Assigned) (Assigned) (open) (closed) > ^ ^ ^ > | | | > | | | > Pull Req. Mail Thread(s) Pull Req. > (open) (closed) > > > 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) > > -- > Chris Evich, RHCA, RHCE, RHCDS, RHCSS > Quality Assurance Engineer > e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 > _______________________________________________ > Autotest mailing list > Autotest@test.kernel.org > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
