[emacs-w3m:13065] Re: https://melpa.org/packages/w3m-20180221.2059.tar: Not found
Colin Baxter <[email protected]>
| Newsgroups | gmane.emacs.w3m |
|---|---|
| Message-ID | <[email protected]> |
>>>>> Boruch Baum <[email protected]> writes: > 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 This is an extremely thoughtful response. Thank you. I use CVS and git in my own work and don't have any particular preference, but, naively, I had not appreciated the subtleties involved in choosing between them. The absence or corruption of data from commits of a legacy git could be an issue, as you point out. Perhaps retaining the status quo isn't a bad idea! Thanks again for your reply, best wishes, Colin Baxter [email protected]