search

martinthomson / i-d-template

A template for IETF internet draft git repositories
Other
211 stars 183 forks source link

difference between the "automated process" and "make upload"? #321

Closed jkunze closed 2 years ago

jkunze commented 2 years ago

What is the relationship between (a) the "Automated Process" section described in https://github.com/martinthomson/i-d-template/blob/main/doc/SUBMITTING.md (and are the two sections that follow it meant to be subsections) and (b) the "make upload" recommendation described in https://github.com/martinthomson/i-d-template/blob/main/doc/FEATURES.md ?

Are these meant to be alternatives, or are we meant to do both? My current guess is that the "git tag ...; make upload" would be a slightly more automated process than the "Automated Process" (but I haven't tried it yet).

martinthomson commented 2 years ago

@jkunze the automated process uses the continuous service to manage the whole process. It just runs make upload on the server. I find that it is more reliable as the environment there is more tightly controlled.

The sections on the submitting doc are intended to be alternatives (aside from the debugging step). I've taken another go at updating those instructions, see if it makes sense.

jkunze commented 2 years ago

Great. The SUBMITTING doc makes sense. It was just at odds with the FEATURES doc, which I was naturally drawn to since I like the command line and being able to use the various make targets from bash. Are you saying that people shouldn't normally run "make upload" themselves (which worked for me) but preer the instructions in SUBMITTING instead?

martinthomson commented 2 years ago

I have a personal preference for the CI-based setup because it is generally more predictable, but I don't think I would actively discourage using make upload. If you are comfortable with it, great.

jkunze commented 2 years ago

Right. Before tagging and 'make upload' I did push to github and monitored the actions to make sure they completed. I will in the future prefer the more predictable CI-based setup, and probably would have headed to the SUBMITTING doc if there were a note at the top of the FEATURES doc (which reads like a nice step by step process) explaining why I might prefer to go there. Thanks for your help!