Re: The RPC's roadmap regarding GitHub

[Michael Richardson <[e-mail]>]

This thread probably belongs in rfc-interest.

Mike Ounsworth <mike=[e-mail]> wrote:
    > 1) Whether the authors of the draft have been working in github as the
    > document moves through WG. This would include things like:

...

    > 2) The RPC will, while intaking a document into the RFC Queue, create a
    > new RPC-owned github repo and hard-copy the .xml or .md from whehever
    > the authors have been working on it. The RPC will do their iterative
    > work in this gh repo, which is available to the authors to follow along
    > if they prefer this over other review methods.

If the process is going to be git*HUB* centric, then a fork of (1) to make
(2) would be best.
(This can also be done in a *GIT* only way, which is a feature of git, and
removes the github centric-ness)

In general, I would prefer if we would *NOT* introduce new dependancies on
github.  It's no longer stable or reliable.  I really wish we were doing this
on an LLC hosted gitlab or forgeo.

    > My personal view is that where the WG has a gh repo for the draft, that
    > should be considered the official copy. When the RFC is published, any
    > changes made by the RPC should be backported into it so that it builds
    > the same version of the document as the published RFC. I think this is
    > important so that if, in the future, the WG decides to de a -bis of
    > that RFC, they have an up-to-date copy of the document source to start
    > from. If the RPC finds that (2) is a convenient way for them to work, I
    > have no problem with that, but I think that should be considered
    > RPC-internal process and should not supersede a WG-owned repo in terms
    > of which one is "the official copy".

I think that it shouldn't be a problem to create a PR, squashed if desired,
against the original repo.

    > Given this, the end-state that I would like to see is that where a
    > WG-owned gh repo already exists, the RPC should work there not in a
    > newly created hard-copy. I see risks of (2) that we end up with two

Fork solves with PR solves many issues of authorization.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **