236848 - update and merge CVS & source code docs

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect)

Description

[benc]

Bug 64262 was the start of a full re-write of the cvs documentation.

This bug is for CVS + source code documentation.

The new pages is:
http://www.mozilla.org/catalog/development/compiling/cvs-sourcecode.html

The old page is:
http://www.mozilla.org/cvs.html

Pages that will need to be updated:
http://www.mozilla.org/download-mozilla.html

Comment 1

[Robert Mohr]

<http://www.mozilla.org/download-mozilla.html> is updated.  I don't know how to
set up HTTP redirection, so I can't fix the rest of the bug.

Comment 2

[Dave Miller [:justdave]]

redirects are my job (or Myk's).  What needs to be redirected, and where to?

Comment 3

[Robert Mohr]

/cvs.html to /catalog/development/compiling/cvs-sourcecode.html I believe.

/source.html has also been updated to point to new page.

Comment 4

[benc]

please add EOL the documents by adding a link + a note at the top.

I would like the old document to be visible for historical reasons.

Comment 5

[benc]

Well the old (and new) document are now completely inaccurate, because we've
transitioned to cvs via SSH.

I will be doing some testing of the new setup, and then I'll update the docs,
hopefully at the end of this week.

Comment 6

[fantasai]

benc, keeping around outdated docs is useless and confusing. /cvs.html is also a
well-established document, and since it's still there, it's still being actively
maintained. You should merge it with cvs-sourcecode.html, update it, and then
delete+redirect cvs-sourcecode.html. If we're going to move documents around, it
certainly shouldn't be into the /catalog hierarchy: docs don't belong there.

Comment 7

[Anne (:annevk)]

*** Bug 239630 has been marked as a duplicate of this bug. ***

Comment 8

[benc]

(In reply to comment #6)
> benc, keeping around outdated docs is useless and confusing. /cvs.html is also a
> well-established document, and since it's still there, it's still being actively
> maintained.

Have you looked at the document history? There has been one change this year,
and that change was to link do a document whose content should be integrated in
that file.

> You should merge it with cvs-sourcecode.html, update it, and then
> delete+redirect cvs-sourcecode.html. If we're going to move documents around, it
> certainly shouldn't be into the /catalog hierarchy: docs don't belong there.

Outside of one condition, I do not care where the files end up, as long as I
don't have to move them twice because of the continued indecision. I don't know
if you are aware of this, but I've been having problems with getting people to
decide where files go for perhaps about 3 years. What I need are solutions and a
consensus that will not change on me in another 12 months.

As for merging the file to a root level file, I really think that is a mistake.
The whole idea of re-writing the cvs docs was to make them both rationalized,
maintainable, modular and readable, and to get them out of the logjam of files
that are living at the root level.

Comment 9

[fantasai]

> Have you looked at the document history?

Yes. It tells me that people are confused about which doc is supposed to exist
and which is only there for "historical purposes".

> I've been having problems with getting people to decide where files go for
> perhaps about 3 years.

I can't do anything about the past 3 years, but in the future you should talk to
me (or email website-drivers) about these problems.

> to get them out of the logjam of files that are living at the root level.

I agree with this, but /catalog is not the right place. Since /cvs.html already
exists, I suggest we continue to use that URL until we've got a better one.
I've suggested to dbaron that moving the CVS docs to devmo might be a good idea.
It will be a few weeks before we can move it there, though.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Redirects added, to resolve repeated confusion (e.g., bug 271121).  You're
welcome to improve the existing documents, but don't fork them, and don't add
stuff inside catalog.

Comment 11

[Benjamin Smedberg]

I am maintaining the pull+build docs. What exactly is the issue of this bug, or
can it be resolved?

Comment 12

[benc]

If you look in cvs, URL for this bug is is still a file in CVS, and it is the
re-write I had made. There are several improvements I made when I wrote it,
which might be nice to carry back to your document.

1- References to the other CVS documentation that has been added.
2- Instructions for using FTP and warnings about doing checkout of the entire
tree are at the top of the document.
3- Removal of tarball instructions (they really do belong in a separate document
about FTP download of code).

You might also want to add links to the cvs docs I wrote about cvs clients for
specific operating systems:

http://www.mozilla.org/catalog/development/tools/cvs-win32.html
http://www.mozilla.org/catalog/development/tools/cvs-macosx.html

I'm glad to see that someone who has more understanding of the build system
wants to maintain these documents. Can we add more information about determining
if you have the right version of make + example steps of using the new
"MOZ_CO_PROJECT" variable (it is used when you run gmake, not do cvs checkout,
right?)

Comment 13

[victory <[e-mail]>]

now all pages #c0 mentioned has been redirected to MDC.
this bug shouldn't be mark as FIXED now?

Comment 14

[Nickolay_Ponomarev]

Both pages redirect to http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS, please edit the wiki directly if anything else need to be changed about that document.