Thanks Ryan for the feedback and clarification. About the DuplicateSearch we need to search not only the exact word or phrase all the combinations of phrase which user enter in summary field ( if we use Ticket Query API it search only the exact match for the word or phrase)
So we need to find matches for tickets in the following order, Exact phrase enter in summary field Part of the phrase enter in summary field a significant words in summary field to get all these search results at once it is better to use the BloodhoundSearch API so it would be better starts with TracSearch API and introduce incremental feature set to BloodhoundSearh API as you suggested earlier. what you think about this it would be great if I can have feedback on that. On Mon, Mar 17, 2014 at 10:40 AM, Ryan Ollos <[email protected]>wrote: > On Wed, Mar 12, 2014 at 6:19 AM, Thimal Kempitiya <[email protected] > >wrote: > > > Hi Ryan, > > Thanks for the suggestions, ticket and feedback. I know you are replying > to > > this thread with busy schedule and I very much appreciate that. > > Thanks again for the ticket I start working on that here is the github > > repository on that I didn't do much yet, I currently trying it. > > https://github.com/thimalk/bloodhound-789 > > > > About the DuplicateSearch, my initial thought was to work with > > BloodhoundSearchAPI. What is the difference between the two APIs > > > The BloodhoundSearchPlugin is much more powerful, and was meant as a > replacement for the Trac Search API. I might have been leading you a little > here though. I'm not sure you need to interact with the search components. > It may work to just use the ticket Query API. The Query API has support for > searching ticket summaries and descriptions that contain words and phrases. > > > > and what > > you mean by the "an incremental set of feature, Trac search API first, > then > > BloodhoundSearchAPI." can I please have more clarification on this. > > > > It's for you to decide, but I'm just suggesting you aim for the minimal > effort to get the simplest version of the feature working, and then expand > on that later. > > > > Yeah it would be better to start without the BloodhoundMultiproductPlugin > > at first and then test with with, it would be great if you can help to > run > > bloodhound without the Bloodhound multiproduct environment. > > > > This might take a few weeks to accomplish, but we'll aim to get there by > the start of your project. One of your "incremental features" can then be > to add support for the multiproduct API later in the project. > > > > As the student proposal period is started it would be great if you can > give > > advise on the proposal. Is there specific things that you expect and also > > is there any sample proposals related to bloodhound project that we can > get > > idea > > > > > You can look at Antonia's proposal from last summer, > https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0007 > You can also see how it evolved by looking at the page history. From what > she said last week, version 1 represents the proposal she submitted to > GSoC. and other changes were made as the project progressed. > https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0007?action=history > > Let me know if you have more questions and I'll try to get back to you > quickly during the week. Sorry that I haven't done a good job at getting > back to you quickly. > -- *Thimal Kempitiya <http://www.facebook.com/thimalk> UndergraduateDepartment of Computer Science and Engineering University of Moratuwa.*
