cloud backend: merge to trunk #1819

New Issue

tahoe-lafs · 2012-09-30T22:14:36Z

davidsarah commented

2012-09-30 22:14:36 +00:00

Rebase the [cloud backend branch]source:cloud-backend for landing on trunk, after the v1.10 release.

Depends on #1818.

Rebase the [cloud backend branch]source:cloud-backend for landing on trunk, after the v1.10 release. Depends on #1818.

tahoe-lafs added the

labels 2012-09-30 22:14:36 +00:00

tahoe-lafs added this to the 1.11.0 milestone 2012-09-30 22:14:36 +00:00

tahoe-lafs added

code-storage

and removed

code

labels 2012-09-30 22:15:54 +00:00

davidsarah commented

2012-11-20 00:53:31 +00:00

Starting the merge now. It will be done on my github branch at https://github.com/davidsarah/tahoe-lafs/commits/1819-cloud-merge.

Starting the merge now. It will be done on my github branch at <https://github.com/davidsarah/tahoe-lafs/commits/1819-cloud-merge>.

zancas commented

2012-12-04 17:44:00 +00:00

Replying to davidsarah:

If I Understand Correctly the proper URL for cloning this repository is now named: https://github.com/davidsarah/tahoe-lafs.git

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1819#issuecomment-89681): > If I Understand Correctly the proper URL for _cloning_ this repository is now named: <https://github.com/davidsarah/tahoe-lafs.git>

davidsarah commented

2012-12-04 19:11:37 +00:00

Replying to [Zancas]comment:5:

If I Understand Correctly the proper URL for cloning this repository is now named: https://github.com/davidsarah/tahoe-lafs.git

That's correct.

Replying to [Zancas]comment:5: > If I Understand Correctly the proper URL for _cloning_ this repository is now named: <https://github.com/davidsarah/tahoe-lafs.git> That's correct.

daira commented

2013-05-01 15:09:17 +00:00

The branch to look at is now https://github.com/LeastAuthority/tahoe-lafs/commits/1819-cloud-merge (at https://github.com/LeastAuthority/tahoe-lafs.git ).

The branch to look at is now <https://github.com/LeastAuthority/tahoe-lafs/commits/1819-cloud-merge> (at <https://github.com/LeastAuthority/tahoe-lafs.git> ).

daira commented

2013-07-04 19:24:25 +00:00

The following tickets block merging pluggable backends and/or leasedb to trunk: [blocks-cloud-merge keyword query]query:status=!closed&keywords=~blocks-cloud-merge&order=priority

daira commented

2013-07-12 20:07:46 +00:00

Preserving these github comments relating to b0fc0987 to stop them getting clobbered by a force-push:

zooko: How is this different than setting expire.enabled = false (as described in source:docs/garbage-collection.rst)?

daira: expire.enabled controls whether leases expire (that is, whether leases past their expiry timestamp are removed). This setting, which is just intended for debugging, controls whether shares with no leases are removed. Setting expire.enabled to false would not have had any effect on the kind of bug I believed was present in the accounting crawler.

zooko: I see. Thanks. I'd rather we not commit code to trunk which is, like this, solely for debugging.

daira: Hmm. We have lots of code that is just for debugging.

zooko: Well, this patch, I don't feel particularly good about. It makes it harder for someone reading the code, and for little gain. We could use other ways to disable share deletion for debugging, next time we want to do that.

daira: I'm sorry you don't feel good about this patch. I'll probably omit it when rebasing the branch to trunk, but I'd like to keep it on this branch until I've debugged #1921 and confirmed that #1987 is invalid.

zooko: Okay!

Preserving these github comments relating to [b0fc0987](https://github.com/LeastAuthority/tahoe-lafs/commit/b0fc09876076df5104a72787701c6fdeb7c70719) to stop them getting clobbered by a force-push: > zooko: How is this different than setting `expire.enabled = false` (as described in source:docs/garbage-collection.rst)? > > daira: `expire.enabled` controls whether leases expire (that is, whether leases past their expiry timestamp are removed). This setting, which is just intended for debugging, controls whether shares with no leases are removed. Setting `expire.enabled` to false would not have had any effect on the kind of bug I believed was present in the accounting crawler. > > zooko: I see. Thanks. I'd rather we not commit code to trunk which is, like this, solely for debugging. > > daira: Hmm. We have lots of code that is just for debugging. > > zooko: Well, this patch, I don't feel particularly good about. It makes it harder for someone reading the code, and for little gain. We could use other ways to disable share deletion for debugging, next time we want to do that. > > daira: I'm sorry you don't feel good about this patch. I'll probably omit it when rebasing the branch to trunk, but I'd like to keep it on this branch until I've debugged #1921 and confirmed that #1987 is invalid. > > zooko: Okay!

zooko commented

2013-07-22 19:22:48 +00:00

I made a branch called 1819-cloud-merge-opensource which has the same licensing declarations as trunk and which omits the four cloud storage connectors (googlestorage, msazure, openstack, s3), and I updated 1819-cloud-merge to state its own (non-!Free/Open-Source) licensing statement.

I posted [//pipermail/tahoe-dev/2013-July/008610.html a lengthy description of the existence of this code and the licensing situation and LeastAuthority.com's business plans].

I made a branch called [1819-cloud-merge-opensource](https://github.com/LeastAuthority/tahoe-lafs/tree/1819-cloud-merge-opensource) which has the same licensing declarations as trunk and which omits the four cloud storage connectors (googlestorage, msazure, openstack, s3), and I updated [1819-cloud-merge](https://github.com/LeastAuthority/tahoe-lafs/tree/1819-cloud-merge) to state its own (non-!Free/Open-Source) licensing statement. I posted [//pipermail/tahoe-dev/2013-July/008610.html a lengthy description of the existence of this code and the licensing situation and [LeastAuthority](wiki/LeastAuthority).com's business plans].

tahoe-lafs modified the milestone from 1.11.0 to 1.12.0

2013-07-22 20:51:19 +00:00

daira commented

2014-04-09 04:02:49 +00:00

This branch has been moved to https://github.com/tahoe-lafs/tahoe-lafs/commits/1819-cloud-merge. It is now fully open-source.

See the blocks-cloud-merge keyword for things remaining to be done.

This branch has been moved to <https://github.com/tahoe-lafs/tahoe-lafs/commits/1819-cloud-merge>. It is now fully open-source. See the [blocks-cloud-merge](https://tahoe-lafs.org/trac/tahoe-lafs/query?status=assigned&status=new&status=reopened&keywords=~blocks-cloud-merge&order=priority) keyword for things remaining to be done.

daira commented

2015-04-17 17:18:16 +00:00

This needs to be rebased because some of the patches on it (for dbutil and deferredutil) were cherry-picked into the #2406 branches for Magic Folder, and later onto master.

This needs to be rebased because some of the patches on it (for `dbutil` and `deferredutil`) were cherry-picked into the #2406 branches for Magic Folder, and later onto master.

daira commented

2015-04-17 22:04:30 +00:00

Rebased to https://github.com/tahoe-lafs/tahoe-lafs/commits/1819.cloud-merge.2. The rebase was complicated (it was quite a deep fork) and ~~could have ~~has introduced bugs.

This branch is currently failing with:

allmydata.PackagingError: 
PackagingError: no version info for txAWS == 0.2.1.post5
PackagingError: no version info for oauth2client == 1.1.0

which prevents running the test suite.

Rebased to <https://github.com/tahoe-lafs/tahoe-lafs/commits/1819.cloud-merge.2>. The rebase was complicated (it was quite a deep fork) and ~~could have ~~has introduced bugs. This branch is currently failing with: ``` allmydata.PackagingError: PackagingError: no version info for txAWS == 0.2.1.post5 PackagingError: no version info for oauth2client == 1.1.0 ``` which prevents running the test suite.

daira commented

2015-04-17 23:11:44 +00:00

The dependency problem is fixed, now the test suite fails with some real bugs:

FAILED (skips=13, expectedFailures=4, failures=12, errors=18, successes=1222)

The dependency problem is fixed, now the test suite fails with some real bugs: ``` FAILED (skips=13, expectedFailures=4, failures=12, errors=18, successes=1222) ```

daira commented

2015-04-17 23:13:45 +00:00

I'm so glad we have a decent test suite. Merges like this would be just impossible otherwise.

I'm going to leave it there for now since working on Magic Folder is a higher priority.

I'm so glad we have a decent test suite. Merges like this would be just impossible otherwise. I'm going to leave it there for now since working on Magic Folder is a higher priority.

warner commented

2016-03-22 05:02:25 +00:00

Milestone renamed

warner modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00

renaming milestone

warner modified the milestone from 1.13.0 to 1.14.0

2016-06-28 18:17:14 +00:00

exarkun commented

2017-08-08 13:20:07 +00:00

So far as I can 1819.cloud-merge.2 no longer reflects the current state of this effort. There is an 1819.cloud-merge.3 branch but even that is not current. Instead, ticket:2237 is where all of the action is happening these days.

It seems like /tahoe-lafs/trac-2024-07-25/issues/6850 and /tahoe-lafs/trac-2024-07-25/issues/6851 were efforts at avoiding an unmergeable mega-branch and that strikes me as a good idea. However, everything seems to have been balled up for ticket:2237 at this point (perhaps due to communication failures, perhaps for other reasons, I don't really know).

There is a plan on ticket:2237 to get this work merged. I think this ticket probably no longer serves much purpose. We will need tickets for the pieces of ticket:2237 which are broken off for merge into master but the shape of those tickets will be dictated entirely by the shape of the pieces of code that can easily be broken off of the mega-branch.

I suggest this be closed.

So far as I can 1819.cloud-merge.2 no longer reflects the current state of this effort. There is an 1819.cloud-merge.3 branch but even that is not current. Instead, ticket:2237 is where all of the action is happening these days. It seems like [/tahoe-lafs/trac-2024-07-25/issues/6850](/tahoe-lafs/trac-2024-07-25/issues/6850) and [/tahoe-lafs/trac-2024-07-25/issues/6851](/tahoe-lafs/trac-2024-07-25/issues/6851) were efforts at avoiding an unmergeable mega-branch and that strikes me as a good idea. However, everything seems to have been balled up for ticket:2237 at this point (perhaps due to communication failures, perhaps for other reasons, I don't really know). There is a plan on ticket:2237 to get this work merged. I think this ticket probably no longer serves much purpose. We will need tickets for the pieces of ticket:2237 which are broken off for merge into master but the shape of those tickets will be dictated entirely by the shape of the pieces of code that can easily be broken off of the mega-branch. I suggest this be closed.

exarkun commented

2017-08-10 12:39:16 +00:00

Closing. See ticket:2237.

exarkun added the

wontfix

label 2017-08-10 12:39:16 +00:00

exarkun closed this issue

2017-08-10 12:39:16 +00:00

Sign in to join this conversation.