On Thu, Mar 22, 2012 at 2:49 AM, Guilherme Salgado <guilherme.salg...@linaro.org> wrote: > Except it crashes if you pass any(*milestones) *and* > exclude_conjoined_tasks=True because _build_exclude_conjoined_clause() > assumes params.milestone is a single IMilestone instance. And fixing > _build_exclude_conjoined_clause() seems to involve doing up to 3 joins > for every milestone passed in, which sounds scary to me.
I've thought about this a little bit, and here is what I think is up: - bug search is crufty - but less crufty than having a different search out there -> I *really* don't like the idea of another bug search implementation existing. What we have is fraught enough. I think in terms of LoC, maintenance and overall sustainability it is much better to fix what we have (it doesn't have to issue one query, its allow to issue N - and does today, but N is constant for a given search irrespective of the number of found results). *but* can you just search on productseries (and not product) or do you really have both product and series targeted bugs targeted to the same milestones? That would let you defer diving into bugSearch while still meeting your goals... - milestones are meant to have the same toplevel|series split tasks have, so probably this is more of that tech debt we raised during the discussion about milestones a few months back. - OnlySeriesTasks would remove the non-series bugtasks and conjoined masters anyway, and that is in the list of things Ubuntu wants done,.. I'll try and find you on IRC, to get a better understanding of the use case involved. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp