You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2014/05/16 19:27:28 UTC
Moving towards a 1.9.x branch
We planned to release a year after 1.8.0, it doesn't look like we're going to
make that. However, we can still manage to a release out with some delay after
that. To that end I suggest that we need to start moving towards a 1.9.x branch.
We'd planned to defer new development and concentrate on fixes before our
branch point in Berlin last year. We never bothered to start that period. I
propose that we start that period now. Which would mean that any new features
be deferred from being added to trunk (branches are ok) until after we branch
1.9.x.
There are still numerous outstanding decisions that need to be made for some
things currently in trunk. We need to move to resolve these issues. Since
tracking these sorts of things in email is rather difficult I have made a new
1.9-blocker milestone. Please move bugs that you consider a blockers (or file
new ones if there isn't one already) for a 1.9.0 release against this
milestone. As always, the issue tracker is not a place for discussion, but it
is a useful place to track the conversations we have had (links to mailing list
archives) and for decisions that have been made, please keep this in mind.
I would rather we not spend our time in Berlin debating such things. I'd much
rather we spend it looking toward what we are going to do in 1.10 and other
future releases.
To that end I'd like to branch no later than June 13th. Please figure out what
blockers you have on a 1.9.0 release and have them appropriately flagged in the
issue tracker by May 23rd. I'd like to see us having a decision on what we're
going to do with those issues by June 6th. Then we can finish up with those
issues (or be well on the way towards it) by June 13th.
This is probably a rather aggressive time frame. Issues that require
considerable work may be found and may alter the time frame. The point of this
is not to create any sort of time limit on filing blockers, if new things are
found we'll deal with them. But I suspect if we don't make any sort of time
lines in this area that we will continue to piddle about and not make any sort
of forward progress on this release.
Re: Moving towards a 1.9.x branch
Posted by Branko Čibej <br...@wandisco.com>.
On 22.05.2014 16:15, Ivan Zhakov wrote:
> On 21 May 2014 14:11, Branko Čibej <br...@wandisco.com> wrote:
>> On 20.05.2014 16:19, Ivan Zhakov wrote:
>>
>> On 16 May 2014 21:27, Ben Reser <be...@reser.org> wrote:
>> [....]
>>
>> To that end I'd like to branch no later than June 13th. Please figure out
>> what
>> blockers you have on a 1.9.0 release and have them appropriately flagged in
>> the
>> issue tracker by May 23rd. I'd like to see us having a decision on what
>> we're
>> going to do with those issues by June 6th. Then we can finish up with those
>> issues (or be well on the way towards it) by June 13th.
>>
>> Hi Ben
>>
>> I've filled the following issues per your request:
>> * Issue #4501 "Remove svn_fs_move() API"
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4501
>>
>>
>> Why? It's an experimental API, and as such, doesn't prevent us from
>> completely removing it or changing it at any time. Also, as far as I'm
>> aware, it doesn't imply any changes in the storage layer.
>>
> You are demonstrating lack of knowledge on topic discussed. The
> svn_fs_move() *does* change disk format. Could you please be so kind
> to learn code before objecting:
> subversion\libsvn_fs_fs\tree.c:copy_helper() is a good starter. Thank
> you.
Eh? Yes, you get a couple new kinds of entries in the changes list, but
the format of the list or any other on-disk structure does not change.
You don't get those new entry types if you don't use the svn_fs_move API.
>> * Issue #4502 "Remove FSFS7 disk format changes"
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4502
>>
>>
>> Let's take your arguments one at a time:
>>
>> 1. and 2. essentially say that bugs in new FSFS code can cause data
>> corruption. True ... but this is true of /any/ change we make in the code.
>> If we take this argument at face value, we may as well revert back to FSFSv1
>> to reduce the risks. I hope you'll agree that doesn't make any sense. What
>> you need to do here is provide a plausible argument that the performance and
>> storage improvements brought by FSFSv7 do not outweigh the increased risk of
>> corruption.
>>
>> You have a point about 3, but it's not an argument for removing FSFSv7 code;
>> it's an argument for putting some effort into expanding the test suite. On
>> that note, I have to ask: what have YOU done to make this happen, apart from
>> telling others to write more tests? Do you have any specific suggestions for
>> the kind of tests that would satisfy you? Note that FSFSv7 is no different
>> in this respect than any other FSFS improvement in the past; so, for
>> example, the lack of cross-version regression tests could be construed as an
>> argument for blocking 1.9 even if FSFSv7 did not exist.
>>
>> 4. is just another way of saying 1., 2., and 3.; all the comments above
>> apply.
>>
>> Your last point is, so sorry, just nonsense. It doesn't matter where some
>> particular code was first written; the fact that logical addressing was
>> extracted from FSX has no bearing whatsoever on the code quality, or on
>> releasing FSFSv7. There is no code duplication in FSFS; on the contrary, the
>> code duplication is in FSX, which is experimental and could change
>> completely at some point; it's simply irrelevant to this discussion.
>>
>>
> The same problem here. Maybe I'm wrong but it seems that you do not
> fully understand the current state of the FSFS code. It so happened
> that I've found and fixed several nasty bugs in FSFSv6 and FSFSv7. And
> I'm just trying to say that we should not release FSFSv7 in the
> current state.
There will always be bugs, but that in itself is not an argument to
block a release. Can you please comment on the points I made instead of
just repeating that you've fixed some bugs?
> Anyway, you can just close issue #4502 if I'm wrong and you are
> clearly understand the code and related FSFSv7 format changes. Maybe
> I'm too conservative and care too much about the quality. Time will
> tell.
Look, nobody is ignoring your objections. I'm trying to have a
discussion about them so that we can maybe come to some agreement about
what we need to do to get FSFSv7 into a state that you would not object
to releasing it. You're apparently refusing to even have a discussion,
and that's not helpful. Telling me that I'm an idiot who can't read code
is, while possibly true, rather off-topic here.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Moving towards a 1.9.x branch
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 21 May 2014 14:11, Branko Čibej <br...@wandisco.com> wrote:
> On 20.05.2014 16:19, Ivan Zhakov wrote:
>
> On 16 May 2014 21:27, Ben Reser <be...@reser.org> wrote:
> [....]
>
> To that end I'd like to branch no later than June 13th. Please figure out
> what
> blockers you have on a 1.9.0 release and have them appropriately flagged in
> the
> issue tracker by May 23rd. I'd like to see us having a decision on what
> we're
> going to do with those issues by June 6th. Then we can finish up with those
> issues (or be well on the way towards it) by June 13th.
>
> Hi Ben
>
> I've filled the following issues per your request:
> * Issue #4501 "Remove svn_fs_move() API"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4501
>
>
> Why? It's an experimental API, and as such, doesn't prevent us from
> completely removing it or changing it at any time. Also, as far as I'm
> aware, it doesn't imply any changes in the storage layer.
>
You are demonstrating lack of knowledge on topic discussed. The
svn_fs_move() *does* change disk format. Could you please be so kind
to learn code before objecting:
subversion\libsvn_fs_fs\tree.c:copy_helper() is a good starter. Thank
you.
>
> * Issue #4502 "Remove FSFS7 disk format changes"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4502
>
>
> Let's take your arguments one at a time:
>
> 1. and 2. essentially say that bugs in new FSFS code can cause data
> corruption. True ... but this is true of /any/ change we make in the code.
> If we take this argument at face value, we may as well revert back to FSFSv1
> to reduce the risks. I hope you'll agree that doesn't make any sense. What
> you need to do here is provide a plausible argument that the performance and
> storage improvements brought by FSFSv7 do not outweigh the increased risk of
> corruption.
>
> You have a point about 3, but it's not an argument for removing FSFSv7 code;
> it's an argument for putting some effort into expanding the test suite. On
> that note, I have to ask: what have YOU done to make this happen, apart from
> telling others to write more tests? Do you have any specific suggestions for
> the kind of tests that would satisfy you? Note that FSFSv7 is no different
> in this respect than any other FSFS improvement in the past; so, for
> example, the lack of cross-version regression tests could be construed as an
> argument for blocking 1.9 even if FSFSv7 did not exist.
>
> 4. is just another way of saying 1., 2., and 3.; all the comments above
> apply.
>
> Your last point is, so sorry, just nonsense. It doesn't matter where some
> particular code was first written; the fact that logical addressing was
> extracted from FSX has no bearing whatsoever on the code quality, or on
> releasing FSFSv7. There is no code duplication in FSFS; on the contrary, the
> code duplication is in FSX, which is experimental and could change
> completely at some point; it's simply irrelevant to this discussion.
>
>
The same problem here. Maybe I'm wrong but it seems that you do not
fully understand the current state of the FSFS code. It so happened
that I've found and fixed several nasty bugs in FSFSv6 and FSFSv7. And
I'm just trying to say that we should not release FSFSv7 in the
current state.
Anyway, you can just close issue #4502 if I'm wrong and you are
clearly understand the code and related FSFSv7 format changes. Maybe
I'm too conservative and care too much about the quality. Time will
tell.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Moving towards a 1.9.x branch
Posted by Branko Čibej <br...@wandisco.com>.
On 20.05.2014 16:19, Ivan Zhakov wrote:
> On 16 May 2014 21:27, Ben Reser <be...@reser.org> wrote:
> [....]
>
>> To that end I'd like to branch no later than June 13th. Please figure out what
>> blockers you have on a 1.9.0 release and have them appropriately flagged in the
>> issue tracker by May 23rd. I'd like to see us having a decision on what we're
>> going to do with those issues by June 6th. Then we can finish up with those
>> issues (or be well on the way towards it) by June 13th.
>>
> Hi Ben
>
> I've filled the following issues per your request:
> * Issue #4501 "Remove svn_fs_move() API"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4501
Why? It's an experimental API, and as such, doesn't prevent us from
completely removing it or changing it at any time. Also, as far as I'm
aware, it doesn't imply any changes in the storage layer.
> * Issue #4502 "Remove FSFS7 disk format changes"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4502
Let's take your arguments one at a time:
* 1. and 2. essentially say that bugs in new FSFS code can cause data
corruption. True ... but this is true of /any/ change we make in
the code. If we take this argument at face value, we may as well
revert back to FSFSv1 to reduce the risks. I hope you'll agree that
doesn't make any sense. What you need to do here is provide a
plausible argument that the performance and storage improvements
brought by FSFSv7 do not outweigh the increased risk of corruption.
* You have a point about 3, but it's not an argument for removing
FSFSv7 code; it's an argument for putting some effort into expanding
the test suite. On that note, I have to ask: what have YOU done to
make this happen, apart from telling others to write more tests? Do
you have any specific suggestions for the kind of tests that would
satisfy you? Note that FSFSv7 is no different in this respect than
any other FSFS improvement in the past; so, for example, the lack of
cross-version regression tests could be construed as an argument for
blocking 1.9 even if FSFSv7 did not exist.
* 4. is just another way of saying 1., 2., and 3.; all the comments
above apply.
* Your last point is, so sorry, just nonsense. It doesn't matter where
some particular code was first written; the fact that logical
addressing was extracted from FSX has no bearing whatsoever on the
code quality, or on releasing FSFSv7. There is no code duplication
in FSFS; on the contrary, the code duplication is in FSX, which is
experimental and could change completely at some point; it's simply
irrelevant to this discussion.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Moving towards a 1.9.x branch
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 May 2014 21:27, Ben Reser <be...@reser.org> wrote:
[....]
> To that end I'd like to branch no later than June 13th. Please figure out what
> blockers you have on a 1.9.0 release and have them appropriately flagged in the
> issue tracker by May 23rd. I'd like to see us having a decision on what we're
> going to do with those issues by June 6th. Then we can finish up with those
> issues (or be well on the way towards it) by June 13th.
>
Hi Ben
I've filled the following issues per your request:
* Issue #4501 "Remove svn_fs_move() API"
http://subversion.tigris.org/issues/show_bug.cgi?id=4501
* Issue #4502 "Remove FSFS7 disk format changes"
http://subversion.tigris.org/issues/show_bug.cgi?id=4502
* Issue #4503 "Revert SVN__STREAM_CHUNK_SIZE back to 16kb (r1586922)"
http://subversion.tigris.org/issues/show_bug.cgi?id=4503
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Moving towards a 1.9.x branch
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, May 20, 2014 at 2:01 AM, Ben Reser <be...@reser.org> wrote:
> Stefan Fuhrmann, can you make a decision on Issue #4146:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4146
>
> Does that still need doing?
>
It hasn't been done but I a hard look at the code and it turned
out to be infeasible without massive code churn and still taking
a significant performance hit. Maybe, FSX can get rid of DAG
nodes altogether but that's nothing I would try in FSFS.
-- Stefan^2.
Re: Moving towards a 1.9.x branch
Posted by Ben Reser <be...@reser.org>.
On 5/19/14, 7:38 AM, Ben Reser wrote:
> Rather "1.9.0" still has a bunch of stuff in it that are not blockers, e.g.
> "true rename" and "encrypted password store." So I created a new milestone so
> I could track things that were distinctly blockers as opposed to things that
> were just "wish we had".
>
> If we want we can just shift that stuff to 1.9-consider and use "1.9.0" instead.
I moved most of the 1.9.0 bugs to 1.10-consider since most of them appear to be
things that aren't happening in 1.9.
I've moved the things filed under 1.9-blocker to 1.9.0 and removed the
1.9-blocker milestone.
Things that aren't necessarily blockers for 1.9.0 but that we want to record as
something to fix in 1.9 should be filed against 1.9.1, which I've also made. I
suspect for the time being we won't use that milestone, but will start moving
things as we triage.
Stefan Fuhrmann, can you make a decision on Issue #4146:
http://subversion.tigris.org/issues/show_bug.cgi?id=4146
Does that still need doing?
Re: Moving towards a 1.9.x branch
Posted by Ben Reser <be...@reser.org>.
On 5/19/14, 5:30 AM, Daniel Shahaf wrote:
> What is the difference between the "1.9-blocker" milestone and "1.9.0" milestone?
>
> Is one for "branch blockers" and the other for "RC blockers"?
I don't think there is such a thing as a "branch blocker," we can always fix
something after we branch.
Rather "1.9.0" still has a bunch of stuff in it that are not blockers, e.g.
"true rename" and "encrypted password store." So I created a new milestone so
I could track things that were distinctly blockers as opposed to things that
were just "wish we had".
If we want we can just shift that stuff to 1.9-consider and use "1.9.0" instead.
Re: Moving towards a 1.9.x branch
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ben Reser wrote on Fri, May 16, 2014 at 10:27:28 -0700:
> Since tracking these sorts of things in email is rather difficult I
> have made a new 1.9-blocker milestone. Please move bugs that you
> consider a blockers (or file new ones if there isn't one already) for
> a 1.9.0 release against this milestone.
What is the difference between the "1.9-blocker" milestone and "1.9.0" milestone?
Is one for "branch blockers" and the other for "RC blockers"?
Re: Moving towards a 1.9.x branch
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, May 19, 2014 at 12:42 PM, Julian Foad <ju...@btopenworld.com>wrote:
> Ben Reser wrote:
> > [...] I suggest that we need to start moving towards a 1.9.x branch.
> >
> > We'd planned to defer new development and concentrate on fixes before our
> > branch point [...] I propose that we start that period now. [...]
> >
> > There are still numerous outstanding decisions [...] I have made a new
> > 1.9-blocker milestone. Please move bugs that you consider a blockers
> (or file
> > new ones if there isn't one already) for a 1.9.0 release against this
> > milestone. As always, the issue tracker is not a place for discussion,
> but it
> > is a useful place to track the conversations [and] decisions [...]
> >
> > I would rather we not spend our time in Berlin debating such things.
> I'd much
> > rather we spend it looking toward what we are going to do in 1.10 and
> other
> > future releases.
>
> +1 to all that.
>
Another +1 from me.
> > [...] Please figure out what blockers you have on a 1.9.0 release and
> have
> > them appropriately flagged in the issue tracker by May 23rd. [...]
>
> I have filed issue #4499 "Remove move detection heuristics from public
> API".
>
And there is one more to come concerning the svn_fs_move function.
I'm currently working on bringing FSX up to par with FSFS
and hope to get everything done by Wed night.
-- Stefan^2.
Re: Moving towards a 1.9.x branch
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
> [...] I suggest that we need to start moving towards a 1.9.x branch.
>
> We'd planned to defer new development and concentrate on fixes before our
> branch point [...] I propose that we start that period now. [...]
>
> There are still numerous outstanding decisions [...] I have made a new
> 1.9-blocker milestone. Please move bugs that you consider a blockers (or file
> new ones if there isn't one already) for a 1.9.0 release against this
> milestone. As always, the issue tracker is not a place for discussion, but it
> is a useful place to track the conversations [and] decisions [...]
>
> I would rather we not spend our time in Berlin debating such things. I'd much
> rather we spend it looking toward what we are going to do in 1.10 and other
> future releases.
+1 to all that.
> [...] Please figure out what blockers you have on a 1.9.0 release and have
> them appropriately flagged in the issue tracker by May 23rd. [...]
I have filed issue #4499 "Remove move detection heuristics from public API".
- Julian