Subject: Re: [Ietf-and-github] [Ext] GIT WG disposition

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Jun 2021 11:43:04 -0500

Just to follow up on this ...

On Mon, Aug 31, 2020 at 10:21 AM tjw ietf <[email-masked]> wrote:

> Ok with closing the wg
>
> I think we’ll see chairs looking for some initial guidance.
>
> Reconsider the mailing list in 9 months?
> That should be two meeting cycles.

I think we may see chairs, and even non-chairs who might someday be chairs,
asking for non-initial guidance, too.

I opened https://github.com/martinthomson/i-d-template/issues/293 in the
very much appreciated i-d-template repo about "interesting" things that
were happening to our draft in the MOPS repo with Circle CI, and that
discussion (again, much appreciated) morphed into a discussion of whether
CircleCI is helpful for continuous integration, or whether we (in this
case, MOPS) should be moving to Github Actions.

To be clear, I'm not talking about a recommendation that IETF WG-owned
repos should all do something, because I don't believe in Santa Claus,
either. I'm only asking about where people can be aware of what other WGs
are doing, and how they are doing it, so WG chairs don't have to figure out
what to do and how to do it, on their own.

I can't be the only person who copies repos to set up other repos, rather
than investigating how to best set up a repo from scratch each time ...

I THINK this mailing list could/would be an appropriate place to have a
discussion about that, but wanted to ask what other people think.

Best,

Spencer

> Tim
>
> Sent from my iPhone
>
> > On Aug 31, 2020, at 10:35, Paul Hoffman <[email-masked]> wrote:
> >
> > On Aug 31, 2020, at 7:33 AM, Lars Eggert <[email-masked]> wrote:
> >>
> >> Hi,
> >>
> >>> On 2020-8-31, at 15:52, Alissa Cooper <[email-masked]> wrote:
> >>> The chairs and I would like to close the group while keeping the
> mailing list open. Please respond if you have any concerns about this,
> otherwise I’ll hit the close button next week.
> >>
> >> I have a mild general preference to also see mailing lists close when
> WGs go away - do we expect significant future discussion here?
> >
> > Personally, I do expect that there will be bursts of "how do I do $x",
> "my WG wants to do $y, is that acceptable", and so on. Not enough for a
> chartered WG, but enough for a mailing list.
> >
> > --Paul Hoffman_______________________________________________
> > Ietf-and-github mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-and-github
>
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jun 2021 16:54:45 +0000

*   To be clear, I'm not talking about a recommendation that IETF WG-owned repos should all do something, because I don't believe in Santa Claus, either. I'm only asking about where people can be aware of what other WGs are doing, and how they are doing it, so WG chairs don't have to figure out what to do and how to do it, on their own.

Naming things consistently, such as ietf-wg-xxxx helps make it easier to find them. That’s in the RFC.

  *   I THINK this mailing list could/would be an appropriate place to have a discussion about that, but wanted to ask what other people think.

I wrote some scripts to handle common WG-chair workflow adopt a draft, etc.  They need some work.  Issues and PR’s welcome: https://github.com/richsalz/ietf-gh-scripts

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 24 Jun 2021 13:05:36 -0400

So I'm sure i'm doing this all wrong, but scraping
https://datatracker.ietf.org/wg/ I see 121 WGs.

running a bunch of curl against github.com/ietf-wg-<wg>

I end up with
  26 200
  95 404

I am sure the secretariat has better numbers

On Thu, Jun 24, 2021 at 12:54 PM Salz, Rich <[email-masked]> wrote:

>
>    - To be clear, I'm not talking about a recommendation that IETF
>    WG-owned repos should all do something, because I don't believe in Santa
>    Claus, either. I'm only asking about where people can be aware of what
>    other WGs are doing, and how they are doing it, so WG chairs don't have to
>    figure out what to do and how to do it, on their own.
>
>
>
>    - I THINK this mailing list could/would be an appropriate place to
>    have a discussion about that, but wanted to ask what other people think.
>
>
>
> I wrote some scripts to handle common WG-chair workflow adopt a draft,
> etc.  They need some work.  Issues and PR’s welcome:
> https://github.com/richsalz/ietf-gh-scripts
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jun 2021 17:10:20 +0000

Yup, we’re not the github police either.  And some WG’s existed before the RFC.

Many WG’s have updated their datatracker page to point to their org/repo.  E.g., https://datatracker.ietf.org/wg/httpapi/about/ for “additional resources”  Fetching that is even scriptable

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Jun 2021 13:23:20 -0500

Just following up,

> Yup, we’re not the github police either.  And some WG’s existed before the

We made the decision (correctly, I thought) to include darned little about
the way Github repos are set up and administered in a published BCP, but
that leaves open the question of where we could publicize as a venue for
topics that draft authors should be aware of, that would be pretty
dynamic(*).

The "CircleCI breakage" issue I mentioned earlier in this thread is one
example, along with the related question of what other people are doing
(Travis, Github Actions, or who knows what). So that was in an issue in the
i-d-template repo (https://github.com/martinthomson/i-d-template/issues/293
).

Last week's interesting topic was on tools-discuss - it turns out that
although we are just starting to publish drafts and RFCs with
internationalized names, we're apparently seeing non-transliterated names
in references now (even expired ones), and there might be interesting
consequences. So that was on an IETF mailing list (
https://mailarchive.ietf.org/arch/msg/tools-discuss/eCDha5w4NLx-PX0DzenHC7CSJcE/
).

A day or two before that, I tripped over a bug that kramdown-rfc2629
currently produces v2 rfcxml (aka xml2rfc v2 input), but xml2rfc
command-line by default assumes --v3. If it sees v2 input, it internally
runs the v2->v3 converter, so the tools team needs to change the
datatracker's submit code (which uses xml2rfc as a library) to run v2v3
when it sees v2 now instead of just running the v2 parser. This one was
discussed in a TRAC ticket, by Robert Sparks' request (at
https://trac.ietf.org/trac/ietfdb/ticket/3305).

I know people (I'm co-chair with Michael Richardson and I have zoom taco
lunches with Robert and Henrik almost every Friday), and even for me, this
is kind of a snipe hunt ... I can't imagine being a new participant, and
I'd just as soon not drive people crazy because they have to answer the
same questions multiple times.

Best,

Spencer

(*) Should that be a Github repo? Ducking now ...

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2021 21:04:45 +0200

On 2021-06-24, at 20:23, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> A day or two before that, I tripped over a bug that kramdown-rfc2629 currently produces v2 rfcxml (aka xml2rfc v2 input),

(That is not the bug.)
Kramdown-rfc2629 actually produces output that is optimized for conversion by xml2rfc into whatever xml2rfc happens to consider to be the v3 of the day.
(Using the --v3 flag on kramdown-rfc2629 enables using all of the v3 features and gives up v2 compatibility for that.)

> but xml2rfc command-line by default assumes --v3. If it sees v2 input, it internally runs the v2->v3 converter,

Exactly, but that is designed to eat v3-in-a-v2-shell as produced by kramdown-rfc.

> so the tools team needs to change the datatracker's submit code (which uses xml2rfc as a library) to run v2v3 when it sees v2 now instead of just running the v2 parser.

Right, *that* is the bug (i.e., trying to stick to pre-transition software when the <rfc> element doesn’t happen to look just right).
(Note that the pre-transition software is *not* being used by the RFC production center, so this approach is not only the wrong one to run a transition, but also produces late surprises when publishing the document as an RFC.)

> This one was discussed in a TRAC ticket, by Robert Sparks' request (at https://trac.ietf.org/trac/ietfdb/ticket/3305).

Indeed, and I look forward to getting that fixed.

I still recommend generating the .v2v3.xml before going to datatracker's submission interface, so there is more control over the generation process; it has not always been clear what version of xml2rfc is running under the submission process (sometimes weird environmental issues such as locale mess this up).

(If the above sounds a bit jaded:  The transition strategy used by xml2rfc works exceedingly well, and I have a lot of respect for Henrik and others getting this right at such an amazing level of precision.  It’s just incredibly frustrating when that great tool then is wedged into a submission process that doesn’t handle the transition as well.)

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Jun 2021 15:16:39 -0500

Hi, Carsten,

On Thu, Jun 24, 2021 at 2:04 PM Carsten Bormann <[email-masked]> wrote:

> currently produces v2 rfcxml (aka xml2rfc v2 input),
>
> (That is not the bug.)
> Kramdown-rfc2629 actually produces output that is optimized for conversion
> by xml2rfc into whatever xml2rfc happens to consider to be the v3 of the
> day.
> (Using the --v3 flag on kramdown-rfc2629 enables using all of the v3
> features and gives up v2 compatibility for that.)
>
> > so the tools team needs to change the datatracker's submit code (which
> uses xml2rfc as a library) to run v2v3 when it sees v2 now instead of just
> running the v2 parser.
>
> Right, *that* is the bug (i.e., trying to stick to pre-transition software
> when the <rfc> element doesn’t happen to look just right).
> (Note that the pre-transition software is *not* being used by the RFC
> production center, so this approach is not only the wrong one to run a
> transition, but also produces late surprises when publishing the document
> as an RFC.)
>

Of course, I owe everyone who maintains the tools I use a mention of
appreciation - I understand how to USE them in most cases unless something
goes sideways, but don't understand the ins and outs well enough to be
comfortable opening github issues, TRAC issues, or dropping email to
tools-discuss, unless I'm pretty sure I'm not wasting their/your time!

My apologies about anything else I mischaracterized, of course.

And now, I hope, back to the search for a place that makes sense to talk
about commonly used IETF draft production tools, some, but not all, being
under control of the tools team ...

Best,

Spencer

> > This one was discussed in a TRAC ticket, by Robert Sparks' request (at
> I still recommend generating the .v2v3.xml before going to datatracker's
> submission interface, so there is more control over the generation process;
> it has not always been clear what version of xml2rfc is running under the
> submission process (sometimes weird environmental issues such as locale
> mess this up).
>
> (If the above sounds a bit jaded:  The transition strategy used by xml2rfc
> works exceedingly well, and I have a lot of respect for Henrik and others
> getting this right at such an amazing level of precision.  It’s just
> incredibly frustrating when that great tool then is wedged into a
> submission process that doesn’t handle the transition as well.)
>
> Grüße, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2021 22:24:03 +0200

On 2021-06-24, at 22:16, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> And now, I hope, back to the search for a place that makes sense to talk about commonly used IETF draft production tools, some, but not all, being under control of the tools team ...

I’d say that is still tools-discuss.

We also have rfc-markdown for kramdown-rfc and mmark discussions, xml2rfc and xml2rfc-dev, and of course this place (ietf-and-github) for how-to-use-git-in-ietf-wg-practice discussion.

There is unavoidable overlap between them, also with rfc-interest which should get the RFCXML vocabulary discussion.

Grüße, Carsten