Julian Foad wrote on Wed, 27 May 2020 21:41 +0100:
> Branko Čibej wrote:
> >>> On 27.05.2020 19:30, Stefan Sperling wrote:
> >>>> Out of the blue, I have received nitpicking of changes I made to the
> >>>> website and the announce message I sent. I've received this feedback
> >>>> via the mailing list moderation mechanism.
> >>>>
> >>>> Can anyone tell me what's going on here? Who even wrote this?
> [...]
>
> Note the response was from moderators of announce.a.o not our own
> announce_at_s.a.o. They likely haven't seen this ensuing discussion on our
> dev@.
>
Moderators should always sign their names when they reject messages,
because ezmlm doesn't add that information by itself. If the
announce_at_a.o moderators don't already follow common-sense practice,
they should be reminded to do so.
FWIW, I said so on board@ at 2019-07-15 15:58, but that message was
buried deep in a long thread and could have easily been missed.
> > So, that anonymous moderator's complaint is doubly silly given that
> > there are currently 4 releases on dist/release and you can only have one
> > file named "KEYS" there. I'm pretty sure downstream users who use the
> > source release are intelligent enough to interpret "KEYS" as "*.KEYS" if
> > necessary.
>
Indeed, the policy requires that we have a KEYS file. We _have_ a KEYS
file; it's just that it's per-release rather than per-PMC. Even
presupposing that this design makes us incompliant with the letter of
the policy, the moderator should not have stopped there but proceeded
to ask whether our download page, _as it stands_, achieves the _end_ of
the policy, which is to provide end-users with the data and know-how
required to cryptographically verify the release artifacts in
a standardized manner.¹
It does, so our announcement should have been moderated through, period.
The moderator might have followed up with a bug report on our dev@ list,
of course, but the reasons given did not justify a rejection. Not every
bug is a showstopper; doubly so when one is entrusted with gating the
work of a community one is not a member of.²
Instead, the moderator used their power to unilaterally require us to
change our release artifacts at the eleventh hour according to his or
her personal, strict/pedantic interpretation of the release policy,
holding our users' awareness of our release hostage to ensure our
compliance.
I do not know of a good reason to have a per-PMC KEYS file that covers
all past and future releases, even if that's what the letter of the
policy requires. A per-release KEYS file generated from LDAP is better
in several ways [more on that later].
In fact, I would consider naming the KEYS file for a particular release
a technical decision, and therefore, I'd argue that moderator breached
the convention that the ASF leaves technical decisions to projects.
More generally, the reason ASF works at all is that it doesn't tell
projects what to do, and in the few exceptions to that, it doesn't tell
them _how_ to do it. Foundation-wide expert groups in various domains
are available to advise PMCs on the options available to them, but it is
always up to a PMC to choose from the various courses of action that
meet the few Foundation-wide requirements. The presumption is that PMCs
know what's best for their users.
The ASF is not supposed to be a place where an external party forbids us
to announce our release until some arbitrary formal dicta are met, when
all the substantive, semantic requirements are already met. The ASF
exists to serve its projects and their users. The purpose of announce@,
Infra, Brand, D&I, and the other Foundation-wide groups is to enable and
support, rather than police. For this reason, Apache Software
Foundation cross-project policies SHOULD NOT MUST.³ Variance between
projects is normal and inevitable, given the large number and different
technology stacks and application areas of PMCs.
(Besides, I also question whether those release policy pages are
actually normative/binding. IIRC, changes to them are subject to
neither a consensus process nor approval by an Officer of the
Foundation, which means they simply reflect the opinion of whoever
bothered to spend time editing them to reflect his or her personal
opinion.)
The moderator's point about a link to KEYS download.html is correct —
.
% svn up -q
% ag KEYS | vipe
download.html:230: the <a href="https://www.apache.org/dist/subversion/KEYS"
download.html:231: >KEYS</a> as well as the <code>asc</code> signature file for the
%
.
— but did not justify blocking the release announcement.
> There is some history:
The moderator's advocated approach of using per-PMC KEYS files leads to
committers having to, whenever they update their private keys, manually
update the KEYS file of every Apache project they have commit access to.
Our approach has been to use KEYS files generated automatically from
LDAP, in order to avoid this busywork.
This is the original reason our KEYS files are different.
> the KEYS file issue was discussed between us and them somewhere
> (dev_at_community.a.o ?) a year or two ago but no consensus was reached.
IIRC, the feedback given to us in that thread was the direct reason I
made release.py create "subversion-%(version)s.KEYS" files in the first
place. This design addresses one of the points of feedback from that
thread, while not introducing the "public keys can never be removed from
the KEYS file, even if they are only required for verifying decade-old
artifacts" problem that the one-KEYS-file-per-PMC design has.
IIRC I made all these points on the thread at the time.
> There is some ASF-wide policy they are trying to enforce.
FWIW, Infra has implicitly endorsed our *.KEYS file naming pattern:
https://issues.apache.org/jira/browse/INFRA-19421
> Clearly this isn't a good way to go about it.
>
> When I received similar rejections on some previous releases, I sighed
> and ignored them, thinking that reaching announce_at_a.o isn't that
> important and in each case it was the last thing at the end of a tiring
> day so I lacked the motivation to pursue it.
Well, it sounds like we have some technical debt to pay off.
Someone could start a discussion with the announce_at_a.o moderators. The
escalation path, IIRC, is: announce-owner@, press@, VP M&P (= Sally),
operations@, board@, members@.
However, I think it's a problem worth solving, one way or the other.
Our release managers should not get emotionally fatigued at the very
point where HACKING specifically instructs them to enjoy their
$favorite_beverage.
Cheers,
Daniel
(who's reminded of Incubator's podling releases vetoing saga)
¹ Compare how we don't reject out of hand patches unaccompanied by log
messages.
² Compare the point regularly made on general_at_incubator, that podling
release reviewers should, upon reviewing a podling release that has
minor incompliances with the release policy, cast "+1 despite the release
policy incompliances, but fix them before your next release" votes rather
than vetoes.
³ "MUST" is to be taken as a verb.
Received on 2020-05-28 07:40:53 CEST