EPrints Technical Mailing List Archive

Message: #08502


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Duplicate repositories between eprints and eprints user group on github.


CAUTION: This e-mail originated outside the University of Southampton.
Hi David,
Thanks for acting on those four - it all helps reduce the problem!

I hope you're able to find out about the others without too much difficulty , would be good to see these confusing duplications resolved!

Karl.

From: David R Newman <drn@ecs.soton.ac.uk>
Sent: Thursday, 28 January 2021 1:12 PM
To: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>; Karl Goetz <karl.goetz@utas.edu.au>
Subject: Re: [EP-tech] Duplicate repositories between eprints and eprints user group on github.
 

Hi Karl,


I have archived and added appropriate "[DEPRECATED] see eprintsug/..." information to the descriptions for the following eprints organization GitHub repositories (-> to the official repository on eprintsug):


eprints/rioxx -> eprintsug/rioxx2

eprints/youtube_importer -> eprintsug/youtube_import

eprints/datacite -> eprintsug/DataCiteDoi

eprints/irus -> eprintsug/irus


Archiving these I don't believe is too controversial, as none of them have been updated in more than 5 years.  eprints/reports is also probably archivable but as the latest update is more recent I would want to have a closer look before making a decision.  I am not sure eprints/issues2 and eprintsug/issues are necessarily the same thing.  I have not looked at eprintsug/issues in any detail so would similarly want to take a closer look before making a decision.  I will need to have a chat with some people about eprints/irstats2 GitHub repository before archiving that.  For the rest, a bit of work is needed to make sure eprintsug inherits any useful changesets from equivalent eprints GitHub repository and may require discussion with various developers about how to go about this.


Talking about other eprints organization repositories not in eprintsug.  I am responsible for some of the more recent ones (plumx and idsidsids) and probably have made commits to some of the others than have been modified in the last few years.  However, I think a fair few of the "not modified in the last five yearS" GitHub repositories could probably be archived.  They are mostly a bit before my time, so would want to speak with others before making any archiving decisions.


Regards


David Newman


On 28/01/2021 00:07, Karl Goetz via Eprints-tech wrote:
CAUTION: This e-mail originated outside the University of Southampton.
Hi,
Almost two years ago there was a lively discussion about ePrints Bazaar [1]; which produced many suggestions.

In a similar vein I'd like to (once again?) raise the issue of duplicate repositories between ePrints User Group on GitHub (eprintsug [2]) and ePrints.org project (eprints [3]).

tl:dr: I propose that any repository which is also in the user group should _only_ live in the user group. This is especially true when the user group has improvements over the original repo.

[1] [EP-tech] please close the Bazaar ; https://www.eprints.org/eptech/msg07916.html



Longer version:

With one exception the repositories have newer fixes in eprintsug than eprints but the help/issue tracking and other references often point to the old/abandoned version in the main eprints project.

I checked all public repositories the in eprints project has and their status in eprintsug. I've split them in to those which are in both and those only in eprints project.

In both:
https://github.com/eprints/rioxx       - last updated 8 years ago - not in user group, but rioxx2 is (https://github.com/eprintsug/rioxx2)
https://github.com/eprints/youtube_importer       - last updated 8 years ago - in user group as youtube_import; updated last year
https://github.com/eprints/datacite  - last updated 8 years ago - in user group as DataCiteDoi ; updated last year
https://github.com/eprints/reports   - last updated 2 years ago - in user group as reports, updated late last year
https://github.com/eprints/irus          - last update 8 years ago - in user group as irus, updated late 2019
https://github.com/eprints/issues2   - last update 3 years ago - in user group as issues, updated early 2019
https://github.com/eprints/EPrintsArchivematica   - last update 11 months ago - in user group as EPrintsArchivematica, updated 3 months ago. In a twist, eprintsug is the *original* and eprints has the *fork*
https://github.com/eprints/orcid_support                - last update 40 days ago - in user group as orcid_support, updated mid 2020. This repo has been forked - user group had an extra 13 commits before eprints repo added one last month.
https://github.com/eprints/hefce_oa   - last updated 15 months ago - in user group as hefce_oa, updated 21 days ago
https://github.com/eprints/orcid_support_advance  - last update 1 day ago - in user group as orcid_support_advance, updated early 2020. Here eprints is ahead by 4 commits
https://github.com/eprints/irstats2    - last update 4 years ago - in user group as irstats2, updated 1 day ago (eprints irstats2 says it was updated 5 hours ago but I can't figure out what that update might have been).


This list of 11 already shows the problem: out of date forks in both projects, one where the projects have diverged, some with eprints.github.io pages despite active work being done in the user group (irstats2 is an example of that).

So, I suggest the duplication is removed, by removing the copies on the eprints side.

Issues I can think of:
  • Initial work and coordination required for such a thing to happen
  • The target account must not have a repository with the same name, or a fork in the same network [4]
  • Broken links. If a repository is transferred links are updated but transfer may not be possible (see point above) [4 again]. In this instance it might be required to update the description in github + readme to say 'look at the user group' then make repositories read only.
  • If moving things piecemeal issues can be transferred but it looks very laborious [5] and bulk moving isn't supported [6]
are there blockers which others can think of which make this suggestion unworkable?

thanks,

Karl.


PS.
Not in user group (at least not obviously so) but included for context.

https://github.com/eprints/essex_data - last update 8 years ago - not in user group
https://github.com/eprints/ptm - last update 8 years ago - not in user group
https://github.com/eprints/apache_debian - last updated 9 years ago - not in user group
https://github.com/eprints/verify_doi - last updated 8 years ago - not in user group
https://github.com/eprints/labs - last updated 8 years ago - not in user group
https://github.com/eprints/eprints-fr - last updated 7 years ago - not in user group
https://github.com/eprints/epkieker - last updated 7 years ago - not in user group
https://github.com/eprints/scripts - last updated 7 years ago - not in user group
https://github.com/eprints/modal - last updated 6 years ago - not in user group
https://github.com/eprints/funders - last updated 6 years ago - not in user group (dependency of https://github.com/eprintsug/gu-funder-fields ?)
https://github.com/eprints/tweepository - last updated 4 years ago - not in user group
https://github.com/eprints/maintainer_tools - last updated 3 years ago - not in user group
https://github.com/eprints/resourcesync - last updated 2 years ago - not in user group
https://github.com/eprints/impact_lib - last updated 2 years ago - not in user group
https://github.com/eprints/annotations - last updated 2 years ago - not in user group
https://github.com/eprints/richtext - last updated 2 years ago - not in user group
https://github.com/eprints/plumx - last updated 4 months ago - not in user group
https://github.com/eprints/idsidsids - last updated 3 months ago - not in user group
https://github.com/eprints/daterangepicker - last updated 3 months ago - not in user group
https://github.com/eprints/ref_support - last updated 17 days ago - not in user group





University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.


*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/

Virus-free. www.avg.com