Thanks, though I'm really interested in HOW we should manage the TODO's. To be clear, my assumption is that once someone picks up a TODO item (by creating a pull-request) then the TODO item will be removed (whatever the system). So, starting new work will involve checking both the TODO list and current pull requests (as you've done here).
Also note: Pull requests to next do not preclude multiple people collaborating. It's fine to send pull requests to eachother (i.e. against someone else's topic branch). When accepted it will just become part of the original pull request against next. Anyway, my question remains, does anyone have any ideas for alternatives to what I wrote below? How about other problems or solutions I did not mention? On 08/09/2013 06:16 AM, liyang wrote: > Agree, recently I'm preparing to do some test cases about "virsh > iface-*" commands, but > I saw sanjeevpatro has done this job recently(I'm happy to see > sanjeevpatro did this), so I > think a TODO items will be a good way to solve such conflict :) > > On 2013-8-8 22:07, Chris Evich wrote: >> All, >> >> I think we have a shared need to communicate about tests we need. It >> was mentioned a few seeks ago by sathnaga on one of our hangouts, I've >> heard it more recently from several of our friends at Fujitsu, and now >> there's a clear need from our interal QE teams as well. >> >> Based on our experience using the tracking issue (to track both current >> and TODO items), it seems conceptually like a good direction to go. >> However, I think it required too much effort from maintainers (mostly >> just me at the time) to maintain it. So I am of two minds: >> >> 1) We need a way to publish and share testing needs from different >> groups, so that- >> a) We avoid multiple solutions for the same problem >> b) We avoid code merge conflicts >> c) All teams benefit from overlap in testing requirements >> 2) We'd all prefer to spend time coding (and other practical maters), >> than maintaining TODO-tracking schemes and enforcing workflow rules. >> >> This time around, I propose we ONLY track TODO items, since once work >> has started, a pull-request can also be started. I'm thinking we could >> use issue-labels instead of having a master tracking issue. The >> down-side is, only maintainers can set/change labels and assign issues. >> >> A text document could be an alternative, however it lacks mechanisms to >> notify and track accountability. Worse, if it's inside the main repo, >> then again only maintainers would have access to both modify and push >> the changes. So we can't escape the maintenance work here either, and >> there's the additional down-side of no-notification ability. >> >> Using a wiki page solves the notification problem, the maintainer-only >> problem, but (in my mind) makes the accountability problem worse - it's >> easily forgotten about and individual items cannot be assigned. >> >> Therefor, I'm inclined to think issues are the way to go, and >> maintainers will just have to deal with the ongoing maintenance they >> require (i.e. setting labels and assigning/re-assigning). >> >> Does anyone else have alternative ideas, or different opinions? >> > > -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
