Bert Huijben wrote: > Julian Foad wrote: >> >> * Review each of the eight issues marked 'REVIEW' above to see if the >> milestone still should be set to a specific old release series. If not, >> change it to 'unscheduled'.
Here they are, for easier reference: http://subversion.tigris.org/issues/show_bug.cgi?id=4117 ra_neon hides "GNOME keyring locked and non-interactive" http://subversion.tigris.org/issues/show_bug.cgi?id=4155 Merge conflict text of expanded keyword incorrect when svn:k http://subversion.tigris.org/issues/show_bug.cgi?id=4191 Wrong commit to tag from "mixed" local copy: trunk + some br http://subversion.tigris.org/issues/show_bug.cgi?id=4196 1.6 locks removed that should be kept http://subversion.tigris.org/issues/show_bug.cgi?id=4254 1.7 client asserts setting property on 1.8 symlink http://subversion.tigris.org/issues/show_bug.cgi?id=4367 merge to shallow WC, repeat merge to infinite depth WC is br http://subversion.tigris.org/issues/show_bug.cgi?id=4380 svn:global-ignores doesn't honor whitespace separated patter http://subversion.tigris.org/issues/show_bug.cgi?id=4531 server-side copy (over dav) uses too much memory >> * Bulk reassign every 1.[789]-consider issue to 'unscheduled'. If we >> didn't fix it for 1.7 or 1.8 or 1.9 there is no particular reason why >> we should *automatically* prioritize it over any other unscheduled >> issue for the 1.10 development period. > > Usually we would bump 1.X-consider to 1.(X+1) consider instead of the big > unscheduled... Yes, but I am suggesting it makes more sense to do something different. In the meantime, I have bumped them to 1.10-consider, and now we have the following stats: 1.6.x 1 (1 defect) REVIEW 1.7.x 4 (4 defect) REVIEW 1.8.1 2 (2 defect) REVIEW 1.8.x 1 (1 defect) REVIEW 1.9.0 1 (1 defect) 1.9.x 0 1.9-consider 0 1.10-consider 110 (43 defect) I suggest that there is little reason why an issue now marked '1.10-consider' should be treated differently from one marked 'unscheduled'. All it means is somebody, sometime in the past, thought this issue should ideally be fixed in the 'next' release (at that time) rather than in any future release when we got around to it. But now we know that the issue was *not* fixed in that next release (at the time), what reason do we have to think it should *now* be prioritized over the other (unscheduled) issues? > Can somebody with more privileges on Tigris create the right targets? I have added 1.9.x and 1.10.0, and 1.10-consider is already there. - Julian
