The problem isn't the number of queries it's the number of reviews. As I said on the bug, it's very easy with the dashboard to create a query for all reviews on a server before you even understand what the dashboard does, and for the
eclipse.org Gerrit server this would mean adding 30,000 reviews to the task list which could have a huge impact on performance. The task list was not designed to scale to this number of tasks as it's intended to be a user's personal task list and not a caching mechanism for searches that may return tens of thousands of tasks.
I wasn’t aware of the issue of accidentally adding queries for all projects. That isn’t good and we should really have some kind of way of preventing this (at least a strongly worded click-through). Given general performance issues with pulling all of that from Gerrit API into local task data (even the basic non-patch set data), I think we need to have safe-guards to prevent this — Reviews isn’t designed to store the whole universe of reviews locally either. I guess I was thinking that we’d resolved this, sorry again for not paying closer attention to this.
For me even a greater concern would be if a bunch of Mylyn Eclipse users ended up doing the same thing; that might even cause significant performance issues on the server, which would *not* be good for the Mylyn Reviews reputation. :O
If there is a need for the search results to be cached, perhaps it would make sense to add an option to the Dashboard to cache specific searches rather than having all searches cached by default. My experience using Gerrit searches is that I usually have to make several searches before I find what I'm looking for and I wouldn't want all of those incorrect searches to have their results cached forever in my task list.
Yes, that matches my experience as well. I’m afraid that I haven’t been playing around with this either. We do have a chicken and egg problem here in that it’s very hard to get user feedback if we don’t actually have the tool more broadly available.
That said, the dashboard has been out since 3.11 and we don't have any hard rules about release train contributions either. To me SR1 sounds like a good compromise. RC4 is a bit late to add new components to the train as other won't have time to test compatibility with their components and SR1 gives us some more time to look into the technical issues raised here.
Yeah, given above I’m +1 on SR1 and -1 on RC4. Note that we should also have the nice new improvements for editing comments, and it might actually be easier to rise above the Luna noise if we do all of this in an SR. Let’s follow up on new bug I suggested below — could “someone” (Sam?) create a bug for that and post it here so we can take this off list, unless there are really strong objections to delaying. I know this is frustrating, guys..
_______________________________________________
mylyn-reviews-dev mailing list
mylyn-reviews-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev