> (Disclaimer: I still have not read this full thread.)
OK...
>> is there any reason not to?
>
> If someone properly integrates Tahoe-LAFS withing Tails (including
> patching tails-persistence-setup, design doc, and whatever nobody has
> thought of yet), then I'm happy.
Since you didn't read the entire thread... I want to make it
explicitly clear that there
is most definitely not one "proper integration" design for Tails and
Tahoe-LAFS...
AND Tahoe-LAFS cannot help with persistence... wrong tool for the job.
But Tahoe-LAFS is great for backups. My proposed idea was to create a backup
"system" which involves the Tails persistent volume assistant and a
number of other
tools including Tahoe-LAFS. This is by no means necessary to use
Tahoe-LAFS on Tails...
and in fact many users may not want "backups" but instead choose to
use Tahoe-LAFS on Tails
in a different way completely.
There could be another track to follow... that might be better for the
first iteration:
Do the minimal amount of work possible to get Tails to ship Tahoe-LAFS...
No fancy backup system. Just Tahoe-LAFS + a GUI + user docs... to help
users configure their Tahoe client.
What do you think of this?
It's more work than *only* shipping the deb package but less work than creating
a whole backup system that integrates with the Tails persistent volume...
> I'm yet to see a branch that implements this, and that we can check
> out and test. Also see
> https://tails.boum.org/contribute/merge_policy/, particularly the
> "Documentation is not optional" section.
Of course documentation is not optional... but I understand that you
may feel the need to say it aloud here.
When I get the approval of the Tahoe-LAFS core dev team then I will
write the design doc
and execute the rest of the plan...
Right now we are still in the design phase of the Tails + Tahoe-LAFS
"backup integration"...
> I'm wondering whether, maybe, the best first step would be to add
> a page about Tahoe-LAFS in our documentation, that gives an overview
> of the pre-requisites (Tails installed with Tails Installer,
> persistent volume configured) and needed additional steps (I guess:
> have tahoe-lafs installed at every boot with the "Additional software
> packages" feature, make the right directories persistent, use it),
> pointing to the relevant documentation pages.
My original plan outlines several different software components... and
most of them
do not yet exist. So it seems to me that the first steps would involve
writing a design
doc... sharing it... make sure everyone agrees... and then writing
those software components.
Are we saying the same thing here? I think we are.
ah but instead of design doc you mention user documentation. I am
confused by this.
I would prefer to work on user docs when I have a design doc and I've
started to write code to implement the design.
I mean... think about it... I don't have approval yet from the
Tahoe-LAFS team... so I don't want to waste
my time writing user docs if the project is going to get scrapped if
they disapprove.
> Then, it's easy for anyone interested to try out, and while early
> testers give it a try, you can work on integrating Tahoe-Lafs within
> Tails, which is now the main blocker to install the software by
> default, from my PoV. And the branch that does the integration already
> has the user doc ready, it just needs to drop the bullet point about
> adding tahoe-lafs to the list of "Additional software packages".
OK... clearly am confused and do not understand. My apologies for
misunderstanding you :
It sounds like you are saying that writing docs for non-existent
software would make it easy for existent software to be used.
It seems to me that the next steps should be for us all to agree on
some sort of design... that is... if anything actually needs to be
designed and it isn't obvious that anything should be designed...
after all... Tahoe-LAFS works just fine on Tails. Furthermore this is
much more flexible than any backup system could ever be... and for
some use cases it will be the *only* way.
Cheers,
David
