[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue sweep

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Feb 2015 15:31:16 +0000

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:

  ra_neon hides "GNOME keyring locked and non-interactive"
  Merge conflict text of expanded keyword incorrect when svn:k
  Wrong commit to tag from "mixed" local copy: trunk + some br
  1.6 locks removed that should be kept
  1.7 client asserts setting property on 1.8 symlink
  merge to shallow WC, repeat merge to infinite depth WC is br
  svn:global-ignores doesn't honor whitespace separated patter
  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

This is an archived mail posted to the Subversion Dev mailing list.