[rfc-i] GitHub references
lars at netapp.com
Thu Mar 8 23:10:26 PST 2018
+1 on allowing hashes
Nothing else is really an archival reference
Sent from a mobile device; please excuse typos.
+49 151 120 55791
> On Mar 9, 2018, at 01:17, Martin Thomson <martin.thomson at gmail.com> wrote:
> Can you explain your concerns with using hashes?
> "July 2016" is effectively meaningless. Even if the month has passed
> and you verify that the content was the same throughout, git has this
> wonderful way of adding new content with old timestamps.
> I would be far more confident if you included a hash. A short hash is
> sufficient. For mping, "80a5713866" would describe the current state.
> On the title thing Paul pointed to, I agree with others that a title
> is valuable. It is reasonable to use the repo name as the title if
> one is not set. Or, to take the first header from the README if that
> appears to be better. Use discretion if they differ. Bob's
> suggestion draws on content that isn't in the source, which concerns
> On Fri, Mar 9, 2018 at 6:59 AM, Heather Flanagan (RFC Series Editor)
> <rse at rfc-editor.org> wrote:
>> Hello all,
>> The RFC Editor is proposing to update the reference format for
>> informative references to GitHub repositories (noting that GitHub
>> repositories are not currently accepted as normative references).
>> Specifically, we propose to standardize on the following:
>> 1) No author name(s). A repository may have many contributors, and there
>> is no way to easily determine major contributors versus all others.
>> 2) The title of the repository will be whatever is in the top left of
>> the main repository page.
>> 3) The URL will be to the main page of the repository.
>> 4) The reference will not include any particular commit hash. It will
>> include the date of the last commit at the time the RFC-to-be is edited.
>> Fan, X., Mathis, M., and D. Hamon, "Git Repository for
>> mping: An IP Level Performance Diagnostic", Sept 2013,
>> "mping", July 2016, <https://github.com/m-lab/mping>.
>> Does anyone have any feedback re: the above proposal? This is outside
>> the realm of CMOS today, so we're breaking some new ground here.
>> Heather Flanagan, RSE
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest