You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Fuhrmann <st...@wandisco.com> on 2013/06/30 12:48:20 UTC
fsfs-format7 integration plan
Hi all,
This is based on what was discussed in Berlin already.
The goal is to get FSFS improvements reviewed & integrated
into /trunk a.s.a.p. and to bring the code for the new backend
to /trunk as well and continue development there. So, the
plan is:
* On the fsfs-format7 branch, duplicate the fsfs-f7 code and
turn it into a new experimental fs backend. I will name it FSX,
with "X" standing for "experimental". It pronounce it "fisiks"
which underlines its design goals.
* Rip out the f7 code from the fsfs backend.
* Open a "fsfs-improvements" integration branch. Merge all fsfs
relevant changes in there in a hopefully review-friendly way.
* Let people review (give them 2 weeks) & merge the integration
branch to /trunk.
* Continue work on fsx during that period and merge it directly
to /trunk once the fsfs-improvements branch got closed.
Everbody fine with that? Comments?
-- Stefan^2.
Re: fsfs-format7 integration plan
Posted by Daniel Shahaf <da...@apache.org>.
Stefan Fuhrmann wrote on Mon, Jul 01, 2013 at 13:42:19 +0200:
> On Sun, Jun 30, 2013 at 3:20 PM, Daniel Shahaf <da...@apache.org> wrote:
>
> > On Sun, Jun 30, 2013 at 12:48:20PM +0200, Stefan Fuhrmann wrote:
> > > Hi all,
> > >
> > > This is based on what was discussed in Berlin already.
> > >
> > > The goal is to get FSFS improvements reviewed & integrated
> > > into /trunk a.s.a.p. and to bring the code for the new backend
> > > to /trunk as well and continue development there. So, the
> > > plan is:
> > >
> > > * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> > > turn it into a new experimental fs backend. I will name it FSX,
> > > with "X" standing for "experimental". It pronounce it "fisiks"
> > > which underlines its design goals.
> > >
> > > * Rip out the f7 code from the fsfs backend.
> > >
> > > * Open a "fsfs-improvements" integration branch. Merge all fsfs
> > > relevant changes in there in a hopefully review-friendly way.
> > >
> > > * Let people review (give them 2 weeks) & merge the integration
> > > branch to /trunk.
> > >
> > > * Continue work on fsx during that period and merge it directly
> > > to /trunk once the fsfs-improvements branch got closed.
> > >
> > > Everbody fine with that? Comments?
> > >
> >
> > IIUC, you plan to bifurcate the current changes fsfs-format7 to two sets:
> > one
> > that will end up in trunk libsvn_fs_fs via the fsfs-improvements branch
> > (will
> > that be f6 or f7?), and one that will end up in trunk as libsvn_fs_x (via
> > the
> > fsfs-format7 branch). Right?
> >
>
> That is correct.
>
> One might be even identify a third group:
> Changes and extensions to lib_subr & friends.
> I think, I will merge them "as we go" since they
> are small enough for normal review.
Right. Your change yesterday to the fs loader for >2 backends is an
example of this.
Re: fsfs-format7 integration plan
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Sun, Jun 30, 2013 at 3:20 PM, Daniel Shahaf <da...@apache.org> wrote:
> On Sun, Jun 30, 2013 at 12:48:20PM +0200, Stefan Fuhrmann wrote:
> > Hi all,
> >
> > This is based on what was discussed in Berlin already.
> >
> > The goal is to get FSFS improvements reviewed & integrated
> > into /trunk a.s.a.p. and to bring the code for the new backend
> > to /trunk as well and continue development there. So, the
> > plan is:
> >
> > * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> > turn it into a new experimental fs backend. I will name it FSX,
> > with "X" standing for "experimental". It pronounce it "fisiks"
> > which underlines its design goals.
> >
> > * Rip out the f7 code from the fsfs backend.
> >
> > * Open a "fsfs-improvements" integration branch. Merge all fsfs
> > relevant changes in there in a hopefully review-friendly way.
> >
> > * Let people review (give them 2 weeks) & merge the integration
> > branch to /trunk.
> >
> > * Continue work on fsx during that period and merge it directly
> > to /trunk once the fsfs-improvements branch got closed.
> >
> > Everbody fine with that? Comments?
> >
>
> IIUC, you plan to bifurcate the current changes fsfs-format7 to two sets:
> one
> that will end up in trunk libsvn_fs_fs via the fsfs-improvements branch
> (will
> that be f6 or f7?), and one that will end up in trunk as libsvn_fs_x (via
> the
> fsfs-format7 branch). Right?
>
That is correct.
One might be even identify a third group:
Changes and extensions to lib_subr & friends.
I think, I will merge them "as we go" since they
are small enough for normal review.
> That sounds good to me. Your 3rd and 4th bullets address the "Don't
> destabilize FSFS" concern.
>
-- Stefan^2.
Re: fsfs-format7 integration plan
Posted by Daniel Shahaf <da...@apache.org>.
On Sun, Jun 30, 2013 at 12:48:20PM +0200, Stefan Fuhrmann wrote:
> Hi all,
>
> This is based on what was discussed in Berlin already.
>
> The goal is to get FSFS improvements reviewed & integrated
> into /trunk a.s.a.p. and to bring the code for the new backend
> to /trunk as well and continue development there. So, the
> plan is:
>
> * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> turn it into a new experimental fs backend. I will name it FSX,
> with "X" standing for "experimental". It pronounce it "fisiks"
> which underlines its design goals.
>
> * Rip out the f7 code from the fsfs backend.
>
> * Open a "fsfs-improvements" integration branch. Merge all fsfs
> relevant changes in there in a hopefully review-friendly way.
>
> * Let people review (give them 2 weeks) & merge the integration
> branch to /trunk.
>
> * Continue work on fsx during that period and merge it directly
> to /trunk once the fsfs-improvements branch got closed.
>
> Everbody fine with that? Comments?
>
IIUC, you plan to bifurcate the current changes fsfs-format7 to two sets: one
that will end up in trunk libsvn_fs_fs via the fsfs-improvements branch (will
that be f6 or f7?), and one that will end up in trunk as libsvn_fs_x (via the
fsfs-format7 branch). Right?
That sounds good to me. Your 3rd and 4th bullets address the "Don't
destabilize FSFS" concern.
> -- Stefan^2.
Re: fsfs-format7 integration plan
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/01/2013 09:42 AM, Stefan Sperling wrote:
> On Mon, Jul 01, 2013 at 09:08:17AM -0400, C. Michael Pilato wrote:
>> {{{
>> Should we require vote-based approval on the reintegration of feature
>> branches? At least some of the hackathon attendees favor the typical “three
>> +1's and no vetos” – the room was not polled for general consensus here,
>> though. Proponents claim that this both helps to solve the inherent dangers
>> of code bombs (it minimizes *cognitive* destabilization) and also encourages
>> feature composers to do a better job of vetting their designs in advance so
>> as to a) ignite interest and attention and b) reduce the chance of
>> widespread disapproval of the feature or the approach taken.
>> }}}
>>
>> But I don't recall any follow-up discussion or anything approaching
>> consensus having happened in an official channel.
>
> I like the idea. Should we start a separate thread to discuss this?
>
+1
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: fsfs-format7 integration plan
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jul 01, 2013 at 09:08:17AM -0400, C. Michael Pilato wrote:
> {{{
> Should we require vote-based approval on the reintegration of feature
> branches? At least some of the hackathon attendees favor the typical “three
> +1's and no vetos” – the room was not polled for general consensus here,
> though. Proponents claim that this both helps to solve the inherent dangers
> of code bombs (it minimizes *cognitive* destabilization) and also encourages
> feature composers to do a better job of vetting their designs in advance so
> as to a) ignite interest and attention and b) reduce the chance of
> widespread disapproval of the feature or the approach taken.
> }}}
>
> But I don't recall any follow-up discussion or anything approaching
> consensus having happened in an official channel.
I like the idea. Should we start a separate thread to discuss this?
Re: fsfs-format7 integration plan
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/01/2013 08:50 AM, Daniel Shahaf wrote:
> Ivan Zhakov wrote on Mon, Jul 01, 2013 at 16:42:27 +0400:
>> I remember we discussed policy about requiring three +1 for merging
>> branches.
>
> Link, please?
>
My recollection was that the discussion that was had occurred in person in
Berlin. I included a mention thereof in my email to dev@ that summarized
the whole release timeline change proposal[1].
{{{
Should we require vote-based approval on the reintegration of feature
branches? At least some of the hackathon attendees favor the typical “three
+1's and no vetos” – the room was not polled for general consensus here,
though. Proponents claim that this both helps to solve the inherent dangers
of code bombs (it minimizes *cognitive* destabilization) and also encourages
feature composers to do a better job of vetting their designs in advance so
as to a) ignite interest and attention and b) reduce the chance of
widespread disapproval of the feature or the approach taken.
}}}
But I don't recall any follow-up discussion or anything approaching
consensus having happened in an official channel.
-- C-Mike
[1] http://svn.haxx.se/dev/archive-2013-06/0243.shtml
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: fsfs-format7 integration plan
Posted by Daniel Shahaf <da...@elego.de>.
Ivan Zhakov wrote on Mon, Jul 01, 2013 at 16:42:27 +0400:
> I remember we discussed policy about requiring three +1 for merging
> branches.
Link, please?
Re: fsfs-format7 integration plan
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sun, Jun 30, 2013 at 2:48 PM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
> Hi all,
>
> This is based on what was discussed in Berlin already.
>
> The goal is to get FSFS improvements reviewed & integrated
> into /trunk a.s.a.p. and to bring the code for the new backend
> to /trunk as well and continue development there. So, the
> plan is:
>
> * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> turn it into a new experimental fs backend. I will name it FSX,
> with "X" standing for "experimental". It pronounce it "fisiks"
> which underlines its design goals.
>
> * Rip out the f7 code from the fsfs backend.
>
> * Open a "fsfs-improvements" integration branch. Merge all fsfs
> relevant changes in there in a hopefully review-friendly way.
>
> * Let people review (give them 2 weeks) & merge the integration
> branch to /trunk.
>
> * Continue work on fsx during that period and merge it directly
> to /trunk once the fsfs-improvements branch got closed.
>
> Everbody fine with that? Comments?
>
I remember we discussed policy about requiring three +1 for merging
branches. I think these fsfs branches is good candidate for this
policy.
It also makes sense to remove any backward compatibility code from
FSX, since it's new FS layer.
--
Ivan Zhakov
Re: fsfs-format7 integration plan
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, Jul 2, 2013 at 9:00 PM, Ben Reser <be...@reser.org> wrote:
> On Tue, Jul 2, 2013 at 5:07 AM, Greg Stein <gs...@gmail.com> wrote:
>> As noted on IRC earlier, we just deprecated BDB so that we wouldn't
>> have to continue supporting multiple backends. But it seems you have
>> just created a third/new backend.
>
> I think that's an incorrect assertion about why we deprecated BDB.
> The goal was not to have one backend it was to get rid of BDB. Some
> reasons were:
> 1) BDB is not being actively improved so FSFS is surpassing it.
> 2) BDB support requires an extra dependency which requires extra
> effort on our part to install and test with.
>
+1.
> There is no conflict in my opinion to creating another backend
> provided it is being actively improved. I pretty much expect us to
> replace FSFS with something new at some point and have some overlap
> there again. It might even be another DB based backend that has some
> dependencies.
Completely agree.
--
Ivan Zhakov
AW: fsfs-format7 integration plan
Posted by Markus Schaber <m....@codesys.com>.
Hi,
Von: Ben Reser [mailto:ben@reser.org]
>
> On Tue, Jul 2, 2013 at 5:07 AM, Greg Stein <gs...@gmail.com> wrote:
> > As noted on IRC earlier, we just deprecated BDB so that we wouldn't
> > have to continue supporting multiple backends. But it seems you have
> > just created a third/new backend.
>
> I think that's an incorrect assertion about why we deprecated BDB.
> The goal was not to have one backend it was to get rid of BDB. Some reasons
> were:
> 1) BDB is not being actively improved so FSFS is surpassing it.
> 2) BDB support requires an extra dependency which requires extra effort on
> our part to install and test with.
I want to add another reason:
3) BDB changes licenses at will, and none of them is on the list of "good"
Licenses according to http://www.apache.org/legal/resolved.html#category-a
AFAICS, the drop of neon just removed the only other dependency with a
"critical" license.
I'm not a license zealot, but the mix of different commercial-only and copyleft
licenses in the dependencies of a free software which is clearly non-copylefted
(and proud of it) is ugly, at least. :-)
> There is no conflict in my opinion to creating another backend provided it is
> being actively improved. I pretty much expect us to replace FSFS with
> something new at some point and have some overlap there again. It might even
> be another DB based backend that has some dependencies.
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: fsfs-format7 integration plan
Posted by Ben Reser <be...@reser.org>.
On Tue, Jul 2, 2013 at 5:07 AM, Greg Stein <gs...@gmail.com> wrote:
> As noted on IRC earlier, we just deprecated BDB so that we wouldn't
> have to continue supporting multiple backends. But it seems you have
> just created a third/new backend.
I think that's an incorrect assertion about why we deprecated BDB.
The goal was not to have one backend it was to get rid of BDB. Some
reasons were:
1) BDB is not being actively improved so FSFS is surpassing it.
2) BDB support requires an extra dependency which requires extra
effort on our part to install and test with.
There is no conflict in my opinion to creating another backend
provided it is being actively improved. I pretty much expect us to
replace FSFS with something new at some point and have some overlap
there again. It might even be another DB based backend that has some
dependencies.
Re: fsfs-format7 integration plan
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Jul 2, 2013 at 7:07 AM, Greg Stein <gs...@gmail.com> wrote:
> On Sun, Jun 30, 2013 at 6:48 AM, Stefan Fuhrmann
> <st...@wandisco.com> wrote:
> > Hi all,
> >
> > This is based on what was discussed in Berlin already.
> >
> > The goal is to get FSFS improvements reviewed & integrated
> > into /trunk a.s.a.p. and to bring the code for the new backend
> > to /trunk as well and continue development there. So, the
> > plan is:
> >
> > * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> > turn it into a new experimental fs backend. I will name it FSX,
> > with "X" standing for "experimental". It pronounce it "fisiks"
> > which underlines its design goals.
>
> Today, you ripped out all FSFS support from the FSX backend. That
> implies you have an entirely new backend, rather than an upgrade path
> for existing FSFS user.
>
There are no upgrade paths even within FSFS itself.
We simply said "from now on, you may try feature X,
if that should not be prevented by some earlier feature".
1.8 for the first time, tried to actually touch existing
data during an upgrade and ran into (resolvable) trouble.
On the implementation side, those franken-repos that
have seen various format upgrades are very troublesome.
As noted on IRC earlier, we just deprecated BDB so that we wouldn't
> have to continue supporting multiple backends. But it seems you have
> just created a third/new backend.
>
Well, we still support BDB. My understand is that we
simply don't add new features to it and that we reserve
the right to drop support entirely at any future release.
FSX is a new backend, true. But initial support for it
will be less than for BDB: We should run regression tests
but explicitly mark it as "unfit for production usage"
(see my other post for more on that).
By the time FSX may become a stable and fully supported
backend, it will likely have an FS2 interface. It might also
be next-to-impossible to implement FS2 on a 1.0 FSFS
repository or even any fsfs format. In that scenario, FSX
would be the only backend and everything else is legacy.
> > * Rip out the f7 code from the fsfs backend.
> >
> > * Open a "fsfs-improvements" integration branch. Merge all fsfs
> > relevant changes in there in a hopefully review-friendly way.
>
> Is the idea that people can test FSX independently? And then changes
> will go into FSFS on this branch? And then it will get to trunk as
> part of FSFS? And that FSX will never land on trunk?
>
> If that is true, then why rip out the f7 support from FSFS on the branch?
>
See my other post. Haven't been entirely clear upon the
whole strategy until I actually removed backwards compat
stuff to see how much that helps.
> > * Let people review (give them 2 weeks) & merge the integration
> > branch to /trunk.
> >
> > * Continue work on fsx during that period and merge it directly
> > to /trunk once the fsfs-improvements branch got closed.
>
> See. This part confuses me. It sounds like we're moving to multiple
> back ends again.
>
> I thought we wanted to avoid that?
>
See above. For now, FSX is an experimental test-bed for
everything nice-to-have on the backend side. The things
we learn from that will help us make much more informed
decisions about FS2 as well as the future of FSFS and
FSX alike.
-- Stefan^2.
Re: fsfs-format7 integration plan
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jun 30, 2013 at 6:48 AM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
> Hi all,
>
> This is based on what was discussed in Berlin already.
>
> The goal is to get FSFS improvements reviewed & integrated
> into /trunk a.s.a.p. and to bring the code for the new backend
> to /trunk as well and continue development there. So, the
> plan is:
>
> * On the fsfs-format7 branch, duplicate the fsfs-f7 code and
> turn it into a new experimental fs backend. I will name it FSX,
> with "X" standing for "experimental". It pronounce it "fisiks"
> which underlines its design goals.
Today, you ripped out all FSFS support from the FSX backend. That
implies you have an entirely new backend, rather than an upgrade path
for existing FSFS user.
As noted on IRC earlier, we just deprecated BDB so that we wouldn't
have to continue supporting multiple backends. But it seems you have
just created a third/new backend.
> * Rip out the f7 code from the fsfs backend.
>
> * Open a "fsfs-improvements" integration branch. Merge all fsfs
> relevant changes in there in a hopefully review-friendly way.
Is the idea that people can test FSX independently? And then changes
will go into FSFS on this branch? And then it will get to trunk as
part of FSFS? And that FSX will never land on trunk?
If that is true, then why rip out the f7 support from FSFS on the branch?
> * Let people review (give them 2 weeks) & merge the integration
> branch to /trunk.
>
> * Continue work on fsx during that period and merge it directly
> to /trunk once the fsfs-improvements branch got closed.
See. This part confuses me. It sounds like we're moving to multiple
back ends again.
I thought we wanted to avoid that?
Cheers,
-g