martinthomson / i-d-template

A template for IETF internet draft git repositories
Other
208 stars 182 forks source link

Unclear how tagging works with manual submission #289

Closed rmarx closed 3 years ago

rmarx commented 3 years ago

SUBMITTING.md says for the manual process:

Then you can tag your repository and upload the tags. The tag you should use is the full draft name including a revision number.

The used commands there are virtually the same as for the automated submission process, so it's a bit unclear how the automated pipeline is prevented from trying to re-submit the new tag to the datatracker.

Is there a certain time one should wait before pushing the tag (e.g., to make sure the datatracker is updated)? If it can be done directly after manually uploading the .xml to the datatracker, it would be good to explicitly state this, as currently I'm a bit hesitant to do so (especially since I'm manually submitting drafts that first need to be manually approved by working group chairs prior to publication).

MikeBishop commented 3 years ago

Possibly out-of-date answer: Deciding what the next draft should be looks at all tags, but deciding whether to submit a draft on push looks at annotated tags. Do git tag -a if you want the CI to submit for you; do git tag to indicate a submission you did manually.

martinthomson commented 3 years ago

Honestly, I hadn't really thought about that, but it's a neat answer. I had always imagined that if you had CI setup you would want to use the automated submission. Maybe I should just say that in the docs.

martinthomson commented 3 years ago

ec74607 includes some notes about this. Is that clearer @rmarx?

As for the other questions: pushing the tag should take effect within a couple of minutes at most. That's how long it takes to schedule and run a build in CI. You can check progress through https://github.com/<your>/<repo>/actions if you are using the default config or the Circle or Travis dashboards otherwise.

If you really want to submit manually, you can do that before pushing the tag. That will result in the CI build failing (datatracker won't let you create a submission when one is already pending), which is harmless: you only get an email notice of the failure.

Drafts that need authorization by chairs can still be submitted using the automated process. You don't get an email for a WG-00 draft. The email only goes to the chairs. The only shortcoming I'm aware of is that you can't mark the WG-00 draft as replacing the individual draft. That's just a limitation of the API. Chairs should have the ability to do that for you.

rmarx commented 3 years ago

Thanks both for the input.

My main use case is indeed the ability to upload a draft as replacing a previous one, which IIUC is only possible with manual upload.

While WG chairs can do this manually after submission, for qlog we had a weird two-step process where I had to split an individual draft in 2 individual drafts for the adoption call, and those then were replaced by WG drafts later. In this case, I'd still probably have to do manual submission (for the 2 individual drafts) even though I have CI setup IIUC.

I feel it would be good to mention explicitly either

  1. "datatracker won't let you create a submission when one is already pending" -> so it's "safe" to tag and push after manual submission, even for annotated tags
  2. tag without annotation to skip auto-submit even when using CI

maybe one of these can be worked into https://github.com/martinthomson/i-d-template/commit/ec74607430990417c2acc1d94ddc06b7fead73a9?

Thanks again for this project in general, it's been very useful as a newcomer!

MikeBishop commented 3 years ago

My main use case is indeed the ability to upload a draft as replacing a previous one, which IIUC is only possible with manual upload.

Similarly, I talked @b---c through a manual submission (and bypassed the Makefile's attempts to get us not to) because we needed to set replacement info while uploading to Datatracker. I don't think it's a good idea to block make submit until we're able to put replacement annotations in the Markdown.