discuss: Thread: Rewriting old documents


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Rewriting old documents
From: "J. S. Evans" ####@####.####
Date: 24 Feb 2016 11:15:48 +0000
Message-Id: <J{X.48LGC.7L4n3mJzLbY.1MpP3Y@seznam.cz>

Hi all,

What's the best way to take over an old document.  I'd like to do a complete re-write of ''Linux-Complete-Backup-and-Recovery-HOWTO''. Would it be better to write an entirely new document while giving attribution to the original document and it's owner or edit the existing document and wiping out huge amounts of existing text that is no longer viable today (e.g. backing up with zip drives, etc.)?

Jason
Subject: RE: Rewriting old documents
From: Mark Komarinski ####@####.####
Date: 24 Feb 2016 12:49:40 +0000
Message-Id: <spn69pusia41ypcd0b2wttn4.1456318231691@email.android.com>

I'd say the latter only because you can track deltas in git.  Unless there's nothing you can reuse.

-------- Original message --------
From: "J. S. Evans" ####@####.#### 
Date: 2/24/2016  6:15 AM  (GMT-05:00) 
To: ####@####.#### 
Subject: Rewriting old documents 

Hi all,

What's the best way to take over an old document.  I'd like to do a complete re-write of ''Linux-Complete-Backup-and-Recovery-HOWTO''. Would it be better to write an entirely new document while giving attribution to the original document and it's owner or edit the existing document and wiping out huge amounts of existing text that is no longer viable today (e.g. backing up with zip drives, etc.)?

Jason
______________________
http://lists.tldp.org/

Subject: Re: Rewriting old documents
From: ####@####.####
Date: 24 Feb 2016 13:43:10 +0000
Message-Id: <201602240837.45157.rhkramer@gmail.com>

> -------- Original message --------
> From: "J. S. Evans" ####@####.####
> Date: 2/24/2016  6:15 AM  (GMT-05:00)
> To: ####@####.####
> Subject: Rewriting old documents
> 
> Hi all,
> 
> What's the best way to take over an old document.  I'd like to do a
> complete re-write of ''Linux-Complete-Backup-and-Recovery-HOWTO''. Would
> it be better to write an entirely new document while giving attribution to
> the original document and it's owner or edit the existing document and
> wiping out huge amounts of existing text that is no longer viable today
> (e.g. backing up with zip drives, etc.)?

I would like to see the document written so that there were what I'll call 
high level and (optionally) low level instructions.  In the case of backing up 
with zip drives, I'd suggest (unless the document title is something like 
"Backing up with Zip Drives") that first general instructions be given that 
would apply to backing up on (almost?) any local device, followed by sections 
(if necessary / appropriate) to backing up with zip drives, external USB 
drives, ...

Among other advantages, then, in the future, the document could be updated 
(when zip drives are obsolete, which I suppose they are ;-), the section on 
zip drives could be deleted (although I might suggest leaving a statement in 
the document under the zip drive heading saying something like "section 
removed, last version was published in version x.y..z of this document which 
is available in the archives of LDP".

And, new devices would be added new sections.
Subject: Re: Rewriting old documents
From: "Martin A. Brown" ####@####.####
Date: 24 Feb 2016 16:27:53 +0000
Message-Id: <alpine.LSU.2.11.1602240821570.2025@znpeba.jbaqresebt.arg>

Hello there again,

>What's the best way to take over an old document. 

>I'd like to do a complete re-write of 
>''Linux-Complete-Backup-and-Recovery-HOWTO''. 

Wonderful!

I think you could use our process for taking over unmaintained 
documents:

  http://tldp.org/authors/unmaint.html

Charles Curley used to be active on this mailing list and may still 
be here, but perhaps emailing him to see if he would let you take 
over the document is one way to start (if you are going to use the 
existing document).

>Would it be better to write an entirely new document while giving 
>attribution to the original document and it's owner or edit the 
>existing document and wiping out huge amounts of existing text that 
>is no longer viable today (e.g. backing up with zip drives, etc.)?

I think that depends on the author's reaction.

You could go either way.  If the author wishes to leave the document 
as it is, then, perhaps write a new one and credit the original 
author as appropriate.  (If the author turns over the document to 
you, I'd suggest retaining the author as a document author.)

Best regards and thank you,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/
Subject: Re: Rewriting old documents
From: "J. S. Evans" ####@####.####
Date: 25 Feb 2016 06:38:37 +0000
Message-Id: <56CEA191.1000004@email.cz>

That's kind of the idea that I have right now. 

This is my outline at the moment is: 1. How to gather and compress your
files and what files you should back up. 2. How and where to send files
(i.e. physical media, cloud storage, NAS) 3. How to recover files.  I'll
also touch on how to make images of VM's in KVM and VirtualBox that can
be backed up and recovered also. I considered writing about LVM images,
making VM images of entire systems, backing up with tools like
NetBackup, etc. but I think those topics might be better for future
HOWTO's as they would make this one too broad in scope. I really want to
focus on file-level backups for newbies at this point.

Jason

On 24.2.2016 14:37, ####@####.#### wrote:
>> -------- Original message --------
>> From: "J. S. Evans" ####@####.####
>> Date: 2/24/2016  6:15 AM  (GMT-05:00)
>> To: ####@####.####
>> Subject: Rewriting old documents
>>
>> Hi all,
>>
>> What's the best way to take over an old document.  I'd like to do a
>> complete re-write of ''Linux-Complete-Backup-and-Recovery-HOWTO''. Would
>> it be better to write an entirely new document while giving attribution to
>> the original document and it's owner or edit the existing document and
>> wiping out huge amounts of existing text that is no longer viable today
>> (e.g. backing up with zip drives, etc.)?
> I would like to see the document written so that there were what I'll call 
> high level and (optionally) low level instructions.  In the case of backing up 
> with zip drives, I'd suggest (unless the document title is something like 
> "Backing up with Zip Drives") that first general instructions be given that 
> would apply to backing up on (almost?) any local device, followed by sections 
> (if necessary / appropriate) to backing up with zip drives, external USB 
> drives, ...
>
> Among other advantages, then, in the future, the document could be updated 
> (when zip drives are obsolete, which I suppose they are ;-), the section on 
> zip drives could be deleted (although I might suggest leaving a statement in 
> the document under the zip drive heading saying something like "section 
> removed, last version was published in version x.y..z of this document which 
> is available in the archives of LDP".
>
> And, new devices would be added new sections.
>
> ______________________
> http://lists.tldp.org/
>


Subject: Re: Rewriting old documents
From: ####@####.####
Date: 25 Feb 2016 13:51:54 +0000
Message-Id: <201602250852.31365.rhkramer@gmail.com>

On Thursday, February 25, 2016 01:39:13 AM J. S. Evans wrote:
> That's kind of the idea that I have right now.
> 
> This is my outline at the moment is: 1. How to gather and compress your
> files and what files you should back up. 2. How and where to send files
> (i.e. physical media, cloud storage, NAS) 3. How to recover files.  I'll
> also touch on how to make images of VM's in KVM and VirtualBox that can
> be backed up and recovered also. I considered writing about LVM images,
> making VM images of entire systems, backing up with tools like
> NetBackup, etc. but I think those topics might be better for future
> HOWTO's as they would make this one too broad in scope. I really want to
> focus on file-level backups for newbies at this point.

Sounds good to me!  Of course, if I find the time to read your document 
(possibly as it is developed), I may offer other suggestions.
[<<] [<] Page 1 of 1 [>] [>>]


  ©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.