Re: Issue sweep

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
Received on 2015-02-19 16:32:15 CET