On Thu, Sep 18, 2025 at 9:40 AM Jean Mahoney <[email protected]> wrote:
> Hi all, > > On 9/17/25 10:06 PM, Richard Barnes wrote: > > The proposal is for the RPC to own the repository in which AUTH48 is > done. > > [JM] Yes, this would be an RPC-owned repo, which fits into our broader > version control strategy. > > > > > If the WG / authors have a repo, it would be up to them to port any > > changes from the RPC repo back to that one. > > [JM] It is on the roadmap to provide tooling assistance to authors port > changes to their repos after the completion of AUTH48. Please see [1]. > I'm not sure we need much in the way of tooling here. If you're working in the source format, the easiest thing is for the editor to just copy the final source. Generally, transplanting commits from one repo to another that doesn't share a common ancestor is somewhere between fraught and incoherent, so I don't think a lot of time should be spent trying to improve on the naive copy-the-source workflow. -Ekr > Thanks! > Jean > > [1] https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc_github_roadmap > > > > > --Richard > > > > On Wed, Sep 17, 2025 at 5:05 PM Ronald Tse > > <[email protected] <mailto:[email protected]>> > > wrote: > > > > As an observer outside this discussion, thank you to all who have > > been participating! > > > > From Richard’s proposal (which seems to me reasonable and > > effective), my question is whether the repository of the eventually > > to-be-published RFC would belong to the RPC or the author(s). > > > > I imagine it is somewhat awkward if the RPC/editor had to go to > > various authors’ repositories to make and track PRs. Different > > authors would likely use different repository structures. > > > > Perhaps the model would be having the Internet-Draft being developed > > at the authors’ repository, then at AUTH48 the RPC creates their own > > version of the repository for editorial and publication purposes? > > > > Ron > > _____________________________________ > > > > Ronald Tse > > Ribose Inc. > > > > +=========================================================+ > > This message may contain confidential and/or privileged > > information. If you are not the addressee or authorized to > > receive this for the addressee, you must not use, copy, > > disclose or take any action based on this message or any > > information herein. If you have received this message in > > error, please advise the sender immediately by reply e-mail > > and delete this message. Thank you for your cooperation. > > +=========================================================+ > > > >> On 18 Sep 2025, at 11:02 AM, Brian E Carpenter > >> <[email protected] <mailto:[email protected]>> > >> wrote: > >> > >>> Just to be clear, if the authors want to make unsolicited changes > >>> beyond what the RPC changed, they should be generating their own > >>> PRs, not making those changes to the RPC's PR. > >> > >> And if the changes are not purely editorial, they must be reported > >> to the WG, as long as we're talking about IETF Consensus > >> documents. So that changes the game. > >> > >> BTW I'm not sure the procedure that Richard outlined is complete. > >> There's an important step in the current procedure that he didn't > >> list: > >> > >> 2a. Script sends RPC's specfic questions to authors in a second > email > >> > >> and step 3 should read: > >> > >> 3. Authors respond to email including answering those specific > >> questions > >> > >> So how are those questions handled via Github? And how does the > >> RPC nag authors that don't reply? > >> > >> Brian > >> > >> On 18-Sep-25 14:43, Eric Rescorla wrote: > >>> On Wed, Sep 17, 2025 at 7:27 PM Paul Hoffman <[email protected] > >>> <mailto:[email protected]> <mailto:[email protected] > >>> <mailto:[email protected]>>> wrote: > >>> On 17 Sep 2025, at 19:09, Eric Rescorla wrote: > >>> > To be clear, what I was trying to say was not that all the > >>> RPC's changes > >>> > should be in one PR -- though I think that's easiest for > >>> the RPC at this > >>> > point -- but rather that as they iterate on a given set of > >>> changes they > >>> > should be in a single PR. > >>> How do you picture those author responses to the PR going? > >>> Simply as comments in the PR? Text changes done as commits in the > >>> branch that created the PR? Or something else? > >>> Comments to the PR that specify what the authors want clearly > >>> and/or Github suggestions that specify the exact changes. > >>> I don't think commits in the branch that created the PR are > >>> helpful and generally may not be permitted by the GitHub > >>> permissions model (depending on exactly how things are specified). > >>> I ask because I suck at commenting in PRs for documents, and > >>> when I do so, I get wildly different advice from the authors > >>> about the proper way to comment in a PR. It would be good if the > >>> RPC could say to authors ahead of time how the authors should > >>> interact with the PR (just as they are told how to respond to > >>> AUTH48 email). > >>> Well, hopefully this situation is clearer because the space of > >>> reasonable comments is rather smaller, as the authors should only > >>> be commenting on text the RPC has changed, and so mostly you > >>> should either be saying "Please revert this change" or "Here is > >>> yet another alternate piece of text". > >>> Just to be clear, if the authors want to make unsolicited changes > >>> beyond what the RPC changed, they should be generating their own > >>> PRs, not making those changes to the RPC's PR. > >>> -Ekr > >>> --Paul Hoffman > >>> _______________________________________________ > >>> rfc-interest mailing list -- [email protected] > >>> <mailto:[email protected]> > >>> To unsubscribe send an email to [email protected] > >>> <mailto:[email protected]> > >> _______________________________________________ > >> rfc-interest mailing list [email protected] > >> <mailto:[email protected]> > >> To unsubscribe send an email [email protected] > >> <mailto:[email protected]> > > > > _______________________________________________ > > rfc-interest mailing list -- [email protected] > > <mailto:[email protected]> > > To unsubscribe send an email to [email protected] > > <mailto:[email protected]> > > > > > > _______________________________________________ > > rfc-interest mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
