Re: https://melpa.org/packages/w3m-20180221.2059.tar: Not found

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2018-11-29 08:43, Colin Baxter wrote:
> Would not moving from CVS to git add to confusion in that there would be
> two emacs-w3m git distributions, only one of which would be official. At
> least with CVS, a user does not have to worry about getting the `wrong'
> URL, the labels git and CVS being sufficient discriminators. Just a
> thought.

A thought worth considering and responding to; here are my initial
thoughts, for what they're worth:

1] There already does exist some measure of small confusion, in that may
   emacs users install emacs-w3m using MELPA, think that method gives
   them the latest official release. It's a reasonable assumption, and
   based upon the lack of complaints, it seems that the administration
   of 'emacs orphanage' seems to be conscientious in keeping the
   unofficial mirror accurate and up-to-date.

2] Based upon the account name chosen for 'emacs orphanage', my guess is
   that project doesn't see itself as an ideal source for emacs
   projects, and they would be glad to rid themselves of any project for
   which the developers would step forward and fill whatever gap led to
   'emacs orphanage' assuming a role.

3] Having the emacs-w3m project migrate to git would benefit the project
   greatly by making it easier to manage the project, and easier for
   people to contribute to it.

   3.1] Does anyone who has used git *like* cvs? Personally, I tried. I
        really did try very hard, and found myself writing complex
        scripts to perform tasks that are simple commands in git. Also,
        my internet connectivity isn't great, so it can be a drag to
        need to connect to a CVS half a world away for any version
        control action (or we could all move to Japan).

4] One option the project could consider is just to adopt the
   'emacs-orphanage' git repository as its own. The advantage of this is
   that all the people worldwide who may possibly have cloned that
   repository, and developed code based upon it, would have compatible
   commit hashes on their master branch with the official repository.

   4.1] A barrier to this option would be if some deficiency were to be
        found in the 'emacs-orphanage' repository. I noticed that their
        copy omits historical branches, but that could easily be fixed.
        A more serious possible issue would be the theoretical that some
        historical meta-data is missing from the emacs-orphanage commits.

5] It may be a simpler quality-assurance task for the project to perform
   its own migration from scratch, instead of relying on the
   'emacs-orphanage' repository. On the other hand, 'emacs-orphanage'
   likely has more experience performing these type of migrations.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0