You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2015/02/19 13:18:17 UTC
Issue sweep
We have the following open issues that have a target milestone set.
1.6.x 1 (1 defect) REVIEW
1.7.x 4 (4 defect) REVIEW
1.7-consider 23 (13 defect)
1.8.1 2 (2 defect) REVIEW
1.8.x 1 (1 defect) REVIEW
1.8-consider 24 (22 defect)
1.9.0 1 (1 defect)
1.9.x 0
1.9-consider 52 (1 defect)
1.10-consider 11 (7 defect)
I suggest we should:
* 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'.
* 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.
Thoughts? Volunteers?
- Julian
Re: Issue sweep
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> milestone 1.7.x:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4254
>> 1.7 client asserts setting property on 1.8 symlink
That's more or less WONTFIX, it's a bug in 1.7 that I think will not get
fixed before 1.9.
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4117
>> ra_neon hides "GNOME keyring locked and non-interactive"
>
> Philip's closed that.
The same, it's a bug in 1.7 that I think will not fixed before 1.9.
I closed 4117 before looking at 4254, then I realised that strictly
speaking 1.7 is still supported so I was unsure whether these should be
closing WONTFIX.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Issue sweep
Posted by Julian Foad <ju...@btopenworld.com>.
>>> * 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'.
Only two of those (pre-1.9-targetted) issues remain at this moment:
milestone 1.7.x:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4254
> 1.7 client asserts setting property on 1.8 symlink
milestone 1.8.x:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4531
> server-side copy (over dav) uses too much memory
The rest, we've closed:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4117
> ra_neon hides "GNOME keyring locked and non-interactive"
Philip's closed that.
> http://subversion.tigris.org/issues/show_bug.cgi?id=4155
> Merge conflict text of expanded keyword incorrect when svn:k
I've closed that -- it was fixed for 1.8.0. It wasn't ever fixed in the 1.7.x series AFAIK -- should we instead keep the issue open because a fix hasn't been backported? No -- keeping the issue open is not the right way to say that -- that's not what we do for other fixes in general.
> http://subversion.tigris.org/issues/show_bug.cgi?id=4191
> Wrong commit to tag from "mixed" local copy: trunk + some br
I've closed that too -- same considerations.
> http://subversion.tigris.org/issues/show_bug.cgi?id=4196
> 1.6 locks removed that should be kept
Philip's closed this as WONTFIX.
> http://subversion.tigris.org/issues/show_bug.cgi?id=4367
> merge to shallow WC, repeat merge to infinite depth WC is br
I've closed that -- it was fixed for 1.8.0.
> http://subversion.tigris.org/issues/show_bug.cgi?id=4380
> svn:global-ignores doesn't honor whitespace separated patter
I've closed that by deeming it correct and fixing the documentation.
- Julian
Re: Issue sweep
Posted by Julian Foad <ju...@btopenworld.com>.
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
RE: Issue sweep
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Julian Foad [mailto:julianfoad@btopenworld.com]
> Sent: donderdag 19 februari 2015 13:18
> To: dev@subversion.apache.org
> Subject: Issue sweep
>
> We have the following open issues that have a target milestone set.
>
> 1.6.x 1 (1 defect) REVIEW
>
> 1.7.x 4 (4 defect) REVIEW
> 1.7-consider 23 (13 defect)
>
> 1.8.1 2 (2 defect) REVIEW
> 1.8.x 1 (1 defect) REVIEW
> 1.8-consider 24 (22 defect)
>
> 1.9.0 1 (1 defect)
> 1.9.x 0
> 1.9-consider 52 (1 defect)
>
> 1.10-consider 11 (7 defect)
>
> I suggest we should:
>
> * 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'.
>
> * 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...
Can somebody with more privileges on Tigris create the right targets?
Bert