The proposal is for the RPC to own the repository in which AUTH48 is done. 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.
--Richard On Wed, Sep 17, 2025 at 5:05 PM Ronald Tse <[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]> 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]>> 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] > 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] >
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
