173583 - Milestones get alphabetically sorted

Status: RESOLVED DUPLICATE of bug 97736

(Bugzilla :: Query/Bug List, defect, P3)

Description

[Gervase Markham [:gerv]]

When I was looking at Bug 173567, I noticed that when you select Browser or
MailNews on the query page, the milestones you can see are ---, Future, M1, M10
and M11. These seem to be in case-insensitive alphabetical order.

We sort them in query.cgi, and we shouldn't - they are stored in the
versioncache in sortkey order, and we should keep them that way.

Gerv

Comment 1

[Gervase Markham [:gerv]]

DeCCing Asa - this was originally going to be a different bug, about reversing
the sort order of the milestones on b.m.o. so that the most recent had the
lowest numbers. We should still do that, but this bug needs to be fixed first.

Gerv

Comment 2

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Stop sorting the milestones.

Gerv

Comment 3

[Christian Reis]

Just a quick question: doesn't this introduce problems when reinserting
milestones for multiple selections? IIRC this was something I thought about and
couldn't solve for the query.cgi sort order issues. But maybe I'm mistaken.

Comment 4

[Gervase Markham [:gerv]]

Yes, now that you mention it, it does :-) 

Presumably the Right Thing To Do here is to get the JS to use sortkeys properly.
Here's a scheme off the top of my head. In the JS we have a "2D array", with the
milestones in global sortkey order across:

            M1   M2    M3   mozilla1.0   mozilla1.1  mozilla1.2  ...
FooProduct  1    1     1
BarProduct                      1            1           1
BazProduct  1          1                     1
...

Then, to get the list for a given list of products (e.g. FooProduct and
BazProduct), you merely create another "line":
MyList:     1    1     1                     1 
which you make a logical OR of the lines for each product in your list. You then
print the milestones for each value that's a 1, in that order.

How's that sound?

Gerv

Comment 5

[Christian Reis]

I am off to southern brazil this week to present a paper on Bugzilla; so I'm
rather unavailable. Having said that, I think:

a) This bug is really a dupe of a bug MattyT filed a year ago

b) Your approach is quite different from what I do today, but it looks generic
enough to support sortkeys on everything (since that's where we are going). I
think it is probably slower than what I do today (since it has quadratic
complexity, while I *think* ours today is at worst quadratic and has some evil
hacks to avoid the slowness). I should point out I also *think* this will
increase the pagesize. But if we need non-alphabetical sorting, it seems to be
the way to go.

Comment 6

[Gervase Markham [:gerv]]

> b) Your approach is quite different from what I do today, but it looks generic
> enough to support sortkeys on everything (since that's where we are going). I
> think it is probably slower than what I do today (since it has quadratic
> complexity, 

Saying it has "quadratic complexity" is wrong. If it had quadratic complexity,
doubling the number of products would lead to a 4x increase in the amount of
work, and it doesn't - it leads to a 2x increase. It has linear complexity along
two axes. I'm not worried about the performance of this because, unlike the
current solution, no sorting is involved at all.

> I should point out I also *think* this will
> increase the pagesize. 

Actually, the opposite. Currently, any milestone name in more than one product
is listed in the page once for each product. In my scheme, each unique name
would be listed only once. This balances out the fact (at least on b.m.o.) that
we need two characters (a digit and a comma) for each milestone/product
intersection.

Gerv

Comment 7

[Christian Reis]

Would this work for Products with sortkeys too? I'm assuming yes..

Comment 8

[Gervase Markham [:gerv]]

Products with sortkeys is a far, far easier problem, because there's no
dimensionality about it. If Products have sortkeys, just pass in an
already-sorted list.

Gerv

Comment 9

[Christian Reis]

*** Bug 177110 has been marked as a duplicate of this bug. ***

Comment 10

[Christian Reis]

Gerv, this bug is a dupe of bug 97736, in reality. Can we move the discussion
down there, if we want to revive it?

*** This bug has been marked as a duplicate of 97736 ***

Comment 11

[Vlad Dascalu]

clearing target in DUPLICATE/WORKSFORME/INVALID/WONTFIX bugs so they'll show up
as untriaged if they get reopened.