On Mon, Jul 30, 2012 at 11:29 AM, Chris Evich <cev...@redhat.com> wrote: > On 07/30/2012 02:28 AM, Satheesh Rajendran wrote: >> >> On Fri, 2012-07-27 at 12:58 -0400, Chris Evich wrote: >>> >>> On 07/27/2012 12:20 PM, Lucas Meneghel Rodrigues wrote: >>>> >>>> On Fri, Jul 27, 2012 at 1:10 PM, Pradeep Kumar Surisetty >>>> <psuri...@linux.vnet.ibm.com> wrote: >>>>> >>>>> * Chris Evich<cev...@redhat.com> [2012-07-27 10:27:21]: >>>>> >>>>>> On 07/27/2012 10:12 AM, Thomas Jarosch wrote: >>>>>>> >>>>>>> On Friday, 27. July 2012 15:45:26 Pradeep Kumar Surisetty wrote: >>>>>>>>> >>>>>>>>> I think a libvirt TODO list is a fantastic idea! How about I put a >>>>>>>>> list >>>>>>>>> up on the virt. autotest wiki? That way everyone can edit and put >>>>>>>>> status, notes, etc. next to each item. I think this would help >>>>>>>>> coordination across companies and teams. Thanks Yu for the >>>>>>>>> suggestion! >>>>>>>> >>>>>>>> >>>>>>>> Autotest wiki is a better place. >>>>>>> >>>>>>> >>>>>>> What about a simple text file in git? >>>>>>> >>>>>>> It's close to the code and shouldn't change that much. >>>>>>> >>>>>>> Thomas >>>>>> >>>>>> >>>>>> Thanks for the suggestions guys. Lucas is generally opposed to having >>>>>> things like this in the tree. He also thinks doing it on the wiki >>>>>> will >>>>>> get out of date quickly. My own experience with wiki's reminds me >>>>>> he's >>>>>> is probably right. >>>>>> >>>>>> What about Trello.com? We can drag/drop items around, and there can >>>>>> be >>>>>> comments/discussion for each - if not just links to GitHub issues/pull >>>>>> requests. Anyone opposed to using Trello? >>>>> >>>>> >>>>> Lets not have too many websites. >>>>> we can have all autotest details/updates in Github. >>>> >>>> >>>> Ok, so what about a placeholder issue that accounts for TODO and has >>>> references to all sub issues that you guys will handle? It should be >>>> fairly straightforward and functional. >>>> >>> >>> Then keeping the "index" issue updated would be the pain :( >>> I also dislike idea of using yet another website, it's a valid concern. >>> >>> Maybe a hybrid approach, use a wiki page as the index linking to issues >>> for each topic/test? It seems doing tables in RST on wiki isn't all >>> that bad. Embedding links could get ugly though, we may just have to >>> reference issues by number w/o links :( >>> >>> I'd like to have it be libvirt specific, and once it's complete we'll >>> nuke it. We just need something temporary to coordinate who's working >>> on which parts and provide room for comments. I don't envision it will >>> be around for more than 6mo - 1yr. Once we burn through the 70-or-so >>> commands, future additions would just be incremental. >>> >>> For a table, I'm thinking something like: >>> >>> | Function/Test | Dependency | issue link | >>> >> >> My suggestion also would be using the Git hub itself, >> and as discussed above github issue tracker >> (https://github.com/autotest/autotest/issues) for >> this purpose is a good idea, so that the issues can be assigned to >> individual and notified about the comments and changes. >> >> If we are maintaining a table as well to track again the libvirt >> specific issues, we should make sure it is not outdated as there is a >> manual update is required every time anyone rising a issue. >> >> Labels in the issue tracker should also help us to differentiate the >> libvirt specific issues. >> >> Is there a way in git hub to get the notification for a group of people >> if there is a change in the particular issue label?. >> >> >> Regards, >> -Satheesh. >> >> > > Thanks for the feedback. It seems the majority so far would prefer to just > use issues. Yes, having a table on the wiki could easily get out of date, > let's forget that. > > I like your idea of using labels and assignment. I don't think you can be > notified if a label changes, unless someone posts a comment. Right now, we > have a 'future' label, should we use that or make a new one like 'libvirt > todo' (or similar)? > > If not, we could always dump them in 'future' with something special in the > issue name, like '[libvirt]'. Then search can find them easily too. > > lmr, > > Is there any special access needed so folks can assign issues to themselves?
I guess they have to be repo collaborators :\ 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. -- Lucas _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
