-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving Crypt4GH into its own GitHub repo #40
Comments
The Crypt4GH specification is written in LaTeX and published as a PDF document. The recently added BED specification is similarly LaTeX/PDF, and its authors considered whether they would be best served by joining LSG's other LaTeX/PDF specifications in the hts-specs repository or by creating a new individual repository under the github.com/ga4gh organisation. In the end, the BED authors found the following arguments convincing:
The same arguments apply for Crypt4GH IMHO, though I notice that the document has not been updated since it was added in 2019 and there is only one crypt4gh-labelled issue (which has garnered no comments). (So to date Crypt4GH has not gained much from that synergy, and in fact has barely benefitted from being in a GitHub repository at all!) Is there an itemisation of the advantages to Crypt4GH of moving to its own GitHub repo?
As described at samtools.github.io, the GitHub samtools organisation is shared between what is now GA4GH LSG (samtools/hts-specs repo), Broad-related Java developers (samtools/htsjdk and samtools/htsjdk-next-beta repos), and Sanger-related C developers (samtools/htslib, samtools/samtools, samtools/bcftools et al). This is partly for historical reasons — e.g. the hts-specs repository predates GA4GH's formation. So that's the reason for the organisational location; being supported first in the |
The Crypt4GH encrypted file format standard is currently part of the hts-specs repo, where it lives next to the SAM, BAM, CRAM, VCF, BED file format standards: https://github.com/samtools/hts-specs. The reason it was placed in there was originally that it is essentially another file format standard (not an API, etc). And samtools was actually the first tool that natively supported it.
However, there have been calls to move Crypt4GH into its own GitHub repo instead; which is reasonable. We have two questions:
1 - Is this a good idea? Does it fit with the larger view on standards in the GA4GH?
2 - What would be the best name/location for this new repo? (Is there a naming scheme that differentiates between standards, implementations, APIs, etc. in https://github.com/ga4gh/?)
The text was updated successfully, but these errors were encountered: