search

dhcwg / rfc8415bis

RFC8415bis
The Unlicense
0 stars 1 forks source link

Put better makefiles ci #5

Closed mcr closed 1 year ago

mcr commented 1 year ago

This pull request reparents the repo with the MT template, and imports the -02.xml file (with the document name updated). This does all the work in github actions, or locally, as you wish.

tomaszmrugalski commented 1 year ago

The CI job has a step called Archieve Built Drafts. It claims to upload them somewhere. Do you know where? Is this a stable, long term storage?

bevolz commented 1 year ago

I also agree that keeping multiple copies is confusing.Well, I obviously like it. Sometimes there’s a need to undo things done in a newer draft and also much easier to fine issues (especially xml related) when you can easily compare to a known “good” copy (i.e., submitted as draft). Tagging does work too but more easily forgotten.Also, if we submit xml version (which is what I’ve been doing), perhaps possible to pull that from datatracker?I understand that it likely messes up automation since file name changes over time as draft progresses.- Bernie (from iPad)On Jul 9, 2023, at 5:10 PM, Tomek Mrugalski @.***> wrote: @tomaszmrugalski commented on this pull request.

In draft-dhcwg-dhc-rfc8415bis.xml:

@@ -1,6738 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?>

I think you missed my point. I'm OK with removing them, just not the way how you proposed by simply deleting them. This way you'd lose the history of changes, you wouldn't be able to use git blame to find out who committed specific line, etc. I also agree that keeping multiple copies is confusing. I did apply my changes to wrong file... I don't have a good answer how to handle this properly, just some vague idea that could possibly work. We could do interactive rebase to rewrite history. We could keep renaming a single file to match whatever filename the next commit wanted to update. At the end, we would have a single file with the changes applied by appropriate authors. It's a bit more work. I can do an experiment some time next week if you feel it's useful.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

mcr commented 1 year ago

I think you missed my point. I'm OK with removing them, just not the way how you proposed by simply deleting them.

If you'd like I can go back and commit each of them as .xml and pile them up properly. I tried to do this when we first started, but got told it wasn't important.

mcr commented 1 year ago

I also agree that keeping multiple copies is confusing.Well, I obviously like it. Sometimes there’s a need to undo things done in a newer draft and also much easier to fine issues (especially xml related) when you can easily compare to a known “good” copy

  1. Well, 99% of the XML issues go away if you'd let us use kramdown as I originally proposed. And the formatting of the XML is really really really poor, so no wonder there are problems with debugging xml2rfc issues. I basically begged you to let me setup the repo properly when we started.

  2. Clearly, git and revision control does not suit you. If you aren't doing a git commit every ~20 minutes, right after you type "make", then you aren't really using revision control. It's just a complicated USB drive.

  3. git cat-file HEAD^^^ foo.xml >oldfile.xml

tomaszmrugalski commented 1 year ago

@mcr, I tried to clean up this PR, but removing the commit that deleted extra files caused the job to fail. If you need the original commits, I've pushed all your changes to old-files-removal branch.

bevolz commented 1 year ago

My email to Eric and Suresh about the Implementation Status section bounced for that email addres for Sheng. It does seem to be his IETF email but not sure what might be going on.- Bernie (from iPad)On Aug 17, 2023, at 5:37 PM, Michael Richardson @.***> wrote: @mcr commented on this pull request.

In .github/CODEOWNERS:

@@ -0,0 +1,3 @@ +# Automatically generated CODEOWNERS +# Regenerate with make update-codeowners +draft-ietf-dhc-rfc8415bis.xml @. @. @. @. @.***

I don't know anything about this, but that address is what I expect to use for IETF work. Sheng did leave Huawei, so I think his address is correct.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

mcr commented 1 year ago

My email to Eric and Suresh about the Implementation Status section bounced for that email addres for Sheng.

He replied to me at that address.