Hiya,

On 17/12/2024 01:56, Joel Halpern wrote:
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.)

That's fair. And why I was asking for that explanation.

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.

I think I said there's an obviously right direction. There are many
ways to go in that direction though, sure, but the feedback Jean
reported puzzlingly seemed to question the direction, not a specific
way to go there.

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 don't see what's hard, compared to what we have now - define who
can approve and how things get approved, so doing it is easier. My
draft outlines one approach, and as ekr noted, there're others.

I hope there is a way to balance those conflicts.  But calling the answer "obvious" does not help.

I didn't make any claim about "the answer." I do claim the direction
is utterly obvious though, yes. And I think that claim is justifiable
and also useful, if we want to do better than the currently failing
system.

Cheers,
S.


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




Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org

Reply via email to