Re: [PATCH general-docs] update DevGuide for Mercurial

Mats Lidell writes:

 > In the patch you have kept cvs-manager but on our web page we refer to
 > MercurialAdministrator which links or [email protected]! (This refers to
 > access rights for the xemacs repository. Isn't that what the cvs mail
 > address was about. Access rights?) 

Yes.

 > But you mention release process. Do I need to read the dev guide to
 > find the cvs parts you have kept? (reasonable I guess ;-)

I think so.  My original intention with the general-docs package was
that we (== me and anybody who wants to help) would develop a way to
include a "base" set of packages in the distribution tarball, and
general-docs would be included in the tarball including the "sumo"
package.

I'll respond to some of Mike's questions here, too.

 > >>>>> Mike Kupfer <[email protected]> writes:

 > > - I left in the @cindex tags that refer to CVS.  Should those just be
 > >   changed from "CVS" to "Mercurial"?

Either that, or the whole paragraph indexed be removed if it doesn't
apply to Mercurial.

 > > - There was some email back in May about CNAMEs and Bitbucket--are any
 > >   changes needed to the DevGuide to deal with that?

We should change any references to "hg.xemacs.org" to "bitbucket.com", I
think.  In practice hg.xemacs.org should continue to work indefinitely
for SSH, because I don't think it's worth it for Bitbucket to muck with
their SSH configuration to prevent it.  But readonly access via http
(which last I checked still worked) could fail at any time if they
change their virtual host configuration.

 > > - I didn't change the process rule in Section 5.10 that says "(t)he
 > >   log message should refer unambiguously to the 'COMMIT' message,
 > >   preferably via the RFC 2822 message ID".  This is something we don't
 > >   seem to be doing, so should that text remain?
 > 
 > No. I think you should remove it. It is good if the dev guide tries to
 > be close to what we actually are doing.

Do remove mit.  There's no point anymore.  Nowadays the commit message
should be easy to find (if anyone cares) from the log message date.
But back in the CVS days, at release time I often found myself
frustrated by very long delays for something as simple as "cvs log",
and the ChangeLog isn't necessarily helpful because ChangeLog dates
typically reflect the *proposal* date for a patch rather than its
*commit* date.  (Especially for patches by non-committers.)  DVCS
means that "$VCS log" is always available and fast.