Stephen, you say that the right direction seems so obvious. (I am
reminded of mathematical jokes about obvious . Obvious is in the eyes of
the beholder.)
From where I sit, there is no obvious good way to balance the need for
community agreement on what we publish as RFC text with the need to be
able to process errata easily and quickly. While being able to unwind
it is better than nothing, it is not sufficient since that still
requires that someone notice when errors are made.
I hope there is a way to balance those conflicts. But calling the
answer "obvious" does not help.
Yours,
Joel
On 12/16/2024 8:49 PM, Stephen Farrell wrote:
Hiya,
On 17/12/2024 01:38, Eric Rescorla wrote:
On Mon, Dec 16, 2024 at 5:23 PM Stephen Farrell
<stephen.farr...@cs.tcd.ie>
wrote:
On 17/12/2024 01:11, Eric Rescorla wrote:
As a repeat errata ignoring offender, I don't think making the process
clearer is the issue.
+1
Whilst I was an AD the main problem with errata was the time it took
to acquire enough state to make a decision. With the errata setup as
was that was prohibitive, and I don't think that's changed since, and
as ekr says, the actual payoff for that effort (for the community) is
so low, there were far better ways to spend AD effort, despite all of
that looking "bad."
IMO, we need an entirely new approach, not any set of tweaks to the
currently utterly useless system, hence draft-farrell-errata.
I agree with Stephen that we need an entirely new approach.
I would probably design a somewhat different set of mechanisms than
those in draft-farrell,
That'd be fine by me. There's lots of design space available to
play with.
but I think that it is asking the right questions,
and
in particular is working from the right principles, which I take to be.
- Some easy way to go from the RFC to filing an issue
- Per-issue discussion with straightforward resolution and approval
rules.
- Errata as "diffs" against the text so they can be automatically
applied
- A default "errata applied" view of the RFC.
I suspect if we had some agreement on those, we could design something
new without *too much* contention.
I agree with those principles stated above. I'd be confident the RPC
could translate those into a prototype system people could play with
and eventually approve (and maybe even like:-).
I'm sure there'd be some discussion needed and learning from trying
things out, but the "right" direction seems so obvious that I'm really
puzzled about the source of the stream managers' reported problems.
It's not urgent though (we've lived with the current disfunctional
system for a long time;-), but I suspect a good next step might be
someone explaining the stream managers' position as reported by Jean.
Cheers,
S.
-Ekr
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
