[rfc-i] [Ietf-and-github] RFC Editor & Github

Benjamin Kaduk kaduk at mit.edu
Sun Feb 24 20:09:55 PST 2019


On Sun, Feb 24, 2019 at 02:15:14PM -0800, Eric Rescorla wrote:
> On Sun, Feb 24, 2019 at 8:42 AM Ted Lemon <mellon at fugue.com> wrote:
> 
> > So the theme I’m hearing here is that the github problem tracking tools
> > suck for RFC editing, which is no surprise to me.   Am I hearing that
> > correctly?
> 
> 
> Perhaps. The premise behind this WG (and I think experience) is that at

I can't answer Ted's question because I'm not sure I'm interpreting it
properly.  Are the "github problem tracking tools" supposed to be "github
issues", "github pull requests", both, or neither?  (We did use pull
requests during the aforementioned experiment, but I would describe that as
just being an easy way to get a webpage that we can attach comments to and
not a normal github pull request workflow.

> least for some WGs, the Github tools are pretty good -- or at least better
> than what people were using before -- for developing the IDs that are the
> input for RFCs. I recognize that there are people who don't seem to feel
> that way, but I don't think that that's useful to debate here.

I agree -- I think the premise here is that we assume as a precondition
that there is some WG for which github is a useful way to work on I-Ds, and
we ignore the other WGs.

-Ben

> As a number of people have noted, I don't think the way we used Github for
> the final copy-editing and typesetting phase of the RFCs worked that well
> the one time we tried it. From my perspective, there were a number of
> problems there, but the main one was intermixing copy-editing changes
> (initiated by the RPC) with substantive changes (initiated by the author,
> WG chairs, and ADs). The result was that the RPC was exposed to a lot of
> churn as we worked through those issues. With that said, I did find that
> having a tool which allowed one to track every change initiated by RPC and
> respond to it was very helpful. At present, we do this by using two tools
> together (diffs plus NEW/OLD), but this is a fairly clumsy system compared
> to a tool like Pull Requests, let alone a top-tier tool like Phabricator.
> As an analogy, open source projects used to mostly do code review by
> examining diffs and then commenting on them, and most systems have now
> moved to integrated diff and review tools instead.
> 
> -Ekr
> 
> 
> 
> 
>  What about the actual revision control system?   Was that a problem, or
> > was it the other stuff that didn’t work?
> >
> > _______________________________________________
> > Ietf-and-github mailing list
> > Ietf-and-github at ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-and-github
> >


More information about the rfc-interest mailing list