You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2013/01/16 20:29:34 UTC
1.8 Release Status : Issue triage
Re the roadmap item "Issue Triage -- Review open issues for the 1.8.0,
1.8-consider, and 1.7.x, milestones". A quick overview of where we
are:
There are 8 issues with the 1.7.x milestone. I reviewed each, none of
them is a 1.8 blocker. All are either neon-only or are limited to
1.7.x and are already fixed on 1.8. So it looks like we are all set
here.
3869 DEFECT P2 All issues@subversion michael_o NEW 1.7.x svn
fails with segmentation fault when neon cannot obtain cr
4117 DEFECT P3 All issues@subversion philip NEW 1.7.x ra_neon
hides "GNOME keyring locked and non-interactive"
4155 DEFECT P4 All issues@subversion svarnau NEW 1.7.x Merge
conflict text of expanded keyword incorrect when svn:k
4191 DEFECT P3 All issues@subversion foma1000 NEW 1.7.x Wrong
commit to tag from "mixed" local copy: trunk + some br
4219 DEFECT P3 All issues@subversion julianfoad NEW 1.7.x svn
delete fails with "403 Forbidden" if root is not readabl
4254 DEFECT P3 All issues@subversion philip NEW 1.7.x 1.7
client asserts setting property on 1.8 symlink
4257 DEFECT P3 All issues@subversion philip NEW 1.7.x neon
get_dir leads to bogus NODES rows
4271 DEFECT P3 PC issues@subversion ochapman NEW 1.7.x
ra_neon fails to properly handle newly introduced Neon error
~~~~~
We have 82 issues with the 1.8.-consider milestone. A lot of these
are older issues that just keep getting pushed to the next release (68
of these were filed in 2011 or earlier). Now might be a great time to
take a look at any 1.8-consider issues you've reported or which are
assigned to you and set them to 'unscheduled' if that is more
appropriate. My assumption about these issues is that we are using
the '1-8-consider' milestone to explicitly state that these issues are
not 1.8 blockers, more of a "nice to have if we have time before
1.8."...if that assumption is not shared with the wider community then
we'll need a more thorough review of these issues.
~~~~~
We have 13 issues with the 1.8.0 milestone and which are thus presumed
blockers for 1.8. They breakdown as follows:
6 are actively being worked on (or at least have recently had a dev
assigned to them):
4037 DEFECT P3 All philip stsp STARTE 1.8.0 auto-merge
locally moved dir with incoming file/dir move dur
4232 DEFECT P3 All philip stsp NEW 1.8.0 local moves in
mixed-revision working copies
4284 DEFECT P3 All issues@subversion danielsh STARTE 1.8.0
svnauthz-validate: --username argument should become a subco
4238 DEFECT P3 All julianfoad stsp NEW 1.8.0 merge -cA,B with
--accept option aborts if rA conflicts
4291 DEFECT P3 All philip rhuijben NEW 1.8.0 Commit of a move
with a move of a subtree below
3990 TASK P3 All cmpilato danielsh NEW 1.8.0 ra_serf as
default requires server config changes
1 is marked as STARTED and assigned to a dev, but it's not clear that
this is actually a blocker or if any ongoing work is taking place:
4280 DEFECT P3 All brane danielsh STARTE 1.8.0 prompt the
controlling terminal, rather than stdin
1 is marked as STARTED and is *not* assigned to a dev, so it's not
clear if any ongoing work is taking place. Nor does it seem to be a
hard 1.8 blocker:
4285 DEFECT P3 All issues@subversion danielsh STARTE 1.8.0
svnpubsub API changes
2 have not been marked as started nor been assigned to a dev and look
to be legitimate blockers:
4293 DEFECT P3 All issues@subversion stsp NEW 1.8.0 cannot
move dir containing file external
4290 TASK P3 All issues@subversion cmpilato NEW 1.8.0 Remove
(or make permanent) WC-NG temporary APIs
1 has not been marked as started nor been assigned but is tied to an
open serf issue:
4274 DEFECT P3 All issues@subversion philip NEW 1.8.0 serf
client hangs when server crashes
2 have not been marked as started nor been assigned and appear to be a
legitmate blockers, but have had no activity for many months:
4211 DEFECT P3 All issues@subversion philip NEW 1.8.0 FSFS
verify needs to handle node verification better
3995 TASK P3 All issues@subversion danielsh NEW 1.8.0
Redesign svn_fs_verify() for 1.8
For those last 7 issues, if you are the reporter, the assignee, and/or
know the problem space well perhaps you could take a look and comment,
assign, start/close, etc. as appropriate.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Release Status : Issue triage
Posted by Branko Čibej <br...@wandisco.com>.
On 20.01.2013 03:36, Branko Čibej wrote:
> On 20.01.2013 02:51, Justin Erenkrantz wrote:
>> On Fri, Jan 18, 2013 at 7:54 AM, Branko Čibej <brane@wandisco.com
>> <ma...@wandisco.com>> wrote:
>>
>> Doesn't help ... apparently because we get both APR_POLLIN and
>> APR_POLLHUP events, and the former is processed first, the
>> function returns without error in the previous block:
>>
>> /* If we decided to reset our connection, return now as we don't
>> * want to write.
>> */
>> if ((conn->seen_in_pollset & APR_POLLHUP) != 0) {
>> return APR_SUCCESS;
>> }
>>
>> I don't know enough about Serf to even begin guessing at the
>> correct solution.
>>
>>
>> The same if check works in that block too. =)
>
> I guessed it should have, but when I tried that, the silly thing still
> hung. I suppose I must've done something silly in the copy/paste.
Verified on Mac OS X. Accordingly I closed issue 4274 and submitted
http://subversion.tigris.org/issues/show_bug.cgi?id=4296
to remind us of the release blocker.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: 1.8 Release Status : Issue triage
Posted by Branko Čibej <br...@wandisco.com>.
On 20.01.2013 02:51, Justin Erenkrantz wrote:
> On Fri, Jan 18, 2013 at 7:54 AM, Branko Čibej <brane@wandisco.com
> <ma...@wandisco.com>> wrote:
>
> Doesn't help ... apparently because we get both APR_POLLIN and
> APR_POLLHUP events, and the former is processed first, the
> function returns without error in the previous block:
>
> /* If we decided to reset our connection, return now as we don't
> * want to write.
> */
> if ((conn->seen_in_pollset & APR_POLLHUP) != 0) {
> return APR_SUCCESS;
> }
>
> I don't know enough about Serf to even begin guessing at the
> correct solution.
>
>
> The same if check works in that block too. =)
I guessed it should have, but when I tried that, the silly thing still
hung. I suppose I must've done something silly in the copy/paste.
> With the debug-abort flag set with serf r1717+ (backported to 1.2.x
> as well):
>
> % svn ls http://localhost:21974/svn-test-work/repositories/basic_tests-3
> svn: E120108: Unable to connect to a repository at URL
> 'http://localhost:21974/svn-test-work/repositories/basic_tests-3'
> svn: E120108: Error running context: The server unexpectedly closed
> the connection.
>
> Enjoy. -- justin
Thanks. Testing this right now.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: 1.8 Release Status : Issue triage
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Jan 18, 2013 at 7:54 AM, Branko Čibej <br...@wandisco.com> wrote:
> Doesn't help ... apparently because we get both APR_POLLIN and
> APR_POLLHUP events, and the former is processed first, the function returns
> without error in the previous block:
>
> /* If we decided to reset our connection, return now as we don't
> * want to write.
> */
> if ((conn->seen_in_pollset & APR_POLLHUP) != 0) {
> return APR_SUCCESS;
> }
>
> I don't know enough about Serf to even begin guessing at the correct
> solution.
>
The same if check works in that block too. =) With the debug-abort flag
set with serf r1717+ (backported to 1.2.x as well):
% svn ls http://localhost:21974/svn-test-work/repositories/basic_tests-3
svn: E120108: Unable to connect to a repository at URL '
http://localhost:21974/svn-test-work/repositories/basic_tests-3'
svn: E120108: Error running context: The server unexpectedly closed the
connection.
Enjoy. -- justin
Re: 1.8 Release Status : Issue triage
Posted by Branko Čibej <br...@wandisco.com>.
On 18.01.2013 12:42, Justin Erenkrantz wrote:
> On Thu, Jan 17, 2013 at 1:19 AM, Branko Čibej <brane@wandisco.com
> <ma...@wandisco.com>> wrote:
>
> > 1 has not been marked as started nor been assigned but is tied to an
> > open serf issue:
> > 4274 DEFECT P3 All issues@subversion philip
> NEW 1.8.0 serf
> > client hangs when server crashes
>
> I reviewed this the other day and submitted
>
> https://code.google.com/p/serf/issues/detail?id=94
>
> as I believe the root cause is in Serf itself.
>
>
> How about this? If the connection never resulted in a successful HTTP
> response during its current lifetime (which gets zero'd in
> reset_connection), then we can return an error back upstream. I think
> we'll still be fine on Windows as the HUP should be detected *after*
> the full response is read by serf. So, in this case, we should bug
> out after a max of 2 attempts...and maybe one if OPTIONS is the first
> request on the connection.
>
> Index: outgoing.c
> ===================================================================
> --- outgoing.c (revision 1716)
> +++ outgoing.c (working copy)
> @@ -1111,7 +1111,10 @@
> /* The connection got reset by the server. On Windows this
> can happen
> when all data is read, so just cleanup the connection and open
> a new one. */
> - return reset_connection(conn, 1);
> + if (conn->completed_responses) {
> + return reset_connection(conn, 1);
> + }
> + return APR_EGENERAL;
> }
> if ((events & APR_POLLERR) != 0) {
> /* We might be talking to a buggy HTTP server that doesn't
>
Doesn't help ... apparently because we get both APR_POLLIN and
APR_POLLHUP events, and the former is processed first, the function
returns without error in the previous block:
/* If we decided to reset our connection, return now as we don't
* want to write.
*/
if ((conn->seen_in_pollset & APR_POLLHUP) != 0) {
return APR_SUCCESS;
}
I don't know enough about Serf to even begin guessing at the correct
solution.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: 1.8 Release Status : Issue triage
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Jan 17, 2013 at 1:19 AM, Branko Čibej <br...@wandisco.com> wrote:
> > 1 has not been marked as started nor been assigned but is tied to an
> > open serf issue:
> > 4274 DEFECT P3 All issues@subversion philip NEW
> 1.8.0 serf
> > client hangs when server crashes
>
> I reviewed this the other day and submitted
>
> https://code.google.com/p/serf/issues/detail?id=94
>
> as I believe the root cause is in Serf itself.
>
>
How about this? If the connection never resulted in a successful HTTP
response during its current lifetime (which gets zero'd in
reset_connection), then we can return an error back upstream. I think
we'll still be fine on Windows as the HUP should be detected *after* the
full response is read by serf. So, in this case, we should bug out after a
max of 2 attempts...and maybe one if OPTIONS is the first request on the
connection. -- justin
Index: outgoing.c
===================================================================
--- outgoing.c (revision 1716)
+++ outgoing.c (working copy)
@@ -1111,7 +1111,10 @@
/* The connection got reset by the server. On Windows this can
happen
when all data is read, so just cleanup the connection and open
a new one. */
- return reset_connection(conn, 1);
+ if (conn->completed_responses) {
+ return reset_connection(conn, 1);
+ }
+ return APR_EGENERAL;
}
if ((events & APR_POLLERR) != 0) {
/* We might be talking to a buggy HTTP server that doesn't
Re: 1.8 Release Status : Issue triage
Posted by Branko Čibej <br...@wandisco.com>.
On 16.01.2013 20:29, Paul Burba wrote:
> 1 is marked as STARTED and assigned to a dev, but it's not clear that
> this is actually a blocker or if any ongoing work is taking place:
> 4280 DEFECT P3 All brane danielsh STARTE 1.8.0 prompt the
> controlling terminal, rather than stdin
This is not strictly a blocker (hence P3) but it'd be yucky not to fix
prompting, given --force-interactive. And yes, I'm working on it, at
this point mainly reviewing what needs to be done.
I expect it'll turn out that we'll have to hoist the getpass
implementation out of APR and expand on it (APR doesn't try /dev/tty on
OSes that might have it, and doesn't do output to the Windows console,
etc.; it also doesn't provide an API for echoed input).
> 4290 TASK P3 All issues@subversion cmpilato NEW 1.8.0 Remove
> (or make permanent) WC-NG temporary APIs
I recently moved this one to the 1.8.0 milestone. Having made an
excursion into WC-NG not too long ago, I was confused by all those
"temporary, to be removed" private APIs in there. So now is as good a
time as any to either make them permanent or throw them away, as the
issue description suggests.
I'll get to this after #4280 unless someone else picks it up; and I'd
really prefer that one of the WC-NG authors does the review.
> 1 has not been marked as started nor been assigned but is tied to an
> open serf issue:
> 4274 DEFECT P3 All issues@subversion philip NEW 1.8.0 serf
> client hangs when server crashes
I reviewed this the other day and submitted
https://code.google.com/p/serf/issues/detail?id=94
as I believe the root cause is in Serf itself.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: 1.8 Release Status : Issue triage
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Jan 17, 2013 at 7:09 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 16.01.2013 22:39, Stefan Fuhrmann wrote:
> > On Wed, Jan 16, 2013 at 8:29 PM, Paul Burba <ptburba@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >
> > 2 have not been marked as started nor been assigned and appear to be
> a
> > legitmate blockers, but have had no activity for many months:
> > 4211 DEFECT P3 All issues@subversion philip
> > NEW 1.8.0 FSFS
> > verify needs to handle node verification better
> > 3995 TASK P3 All issues@subversion danielsh
> > NEW 1.8.0
> > Redesign svn_fs_verify() for 1.8
> >
> >
> > I'm taking these two as they have bugged me ever since.
> > Not sure how much we can actually do for 1.8 but I will
> > try things over the weekend.
>
> There's been a lot of progress on this front since the issues were
> filed. I think these basically just need review and can probably be
> closed without much further effort.
>
As of r1435746, verify is about as fast as in 1.7
while providing UI feedback even during the initial
phase where 1.7 remains silent.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: 1.8 Release Status : Issue triage
Posted by Branko Čibej <br...@wandisco.com>.
On 16.01.2013 22:39, Stefan Fuhrmann wrote:
> On Wed, Jan 16, 2013 at 8:29 PM, Paul Burba <ptburba@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> 2 have not been marked as started nor been assigned and appear to be a
> legitmate blockers, but have had no activity for many months:
> 4211 DEFECT P3 All issues@subversion philip
> NEW 1.8.0 FSFS
> verify needs to handle node verification better
> 3995 TASK P3 All issues@subversion danielsh
> NEW 1.8.0
> Redesign svn_fs_verify() for 1.8
>
>
> I'm taking these two as they have bugged me ever since.
> Not sure how much we can actually do for 1.8 but I will
> try things over the weekend.
There's been a lot of progress on this front since the issues were
filed. I think these basically just need review and can probably be
closed without much further effort.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: 1.8 Release Status : Issue triage
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Jan 16, 2013 at 8:29 PM, Paul Burba <pt...@gmail.com> wrote:
>
> 2 have not been marked as started nor been assigned and appear to be a
> legitmate blockers, but have had no activity for many months:
> 4211 DEFECT P3 All issues@subversion philip NEW
> 1.8.0 FSFS
> verify needs to handle node verification better
> 3995 TASK P3 All issues@subversion danielsh
> NEW 1.8.0
> Redesign svn_fs_verify() for 1.8
>
I'm taking these two as they have bugged me ever since.
Not sure how much we can actually do for 1.8 but I will
try things over the weekend.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: 1.8 Release Status : Issue triage
Posted by Ben Reser <be...@reser.org>.
On Wed, Jan 16, 2013 at 11:29 AM, Paul Burba <pt...@gmail.com> wrote:
> 4284 DEFECT P3 All issues@subversion danielsh STARTE 1.8.0
> svnauthz-validate: --username argument should become a subco
There's no real blocker with 4284. The only issue is dealing with the
Windows build to make it expose the compatibility mode for svnauthz,
which can be as simple as making it copy the svnauthz command to
svnauthz-validate.
> 1 is marked as STARTED and is *not* assigned to a dev, so it's not
> clear if any ongoing work is taking place. Nor does it seem to be a
> hard 1.8 blocker:
> 4285 DEFECT P3 All issues@subversion danielsh STARTE 1.8.0
> svnpubsub API changes
I think most of the changes are done here. Daniel, Greg and I were
having some discussion about this stuff today. There might be some
changes between now and 1.8 branching, but I doubt this will hold us
up.