> n this way, the automation would be triggered
>at the formal tag pushed
>after the vote passed.
Correct me if I am wrong, however, if a release vote includes only sources,
then creating and publishing binaries separately would violate the release
policy.
Creating the binaries and publishing
Thank Chris for your feedback!
You're right and an alternative is to postpone the binaries release until
the vote passed, while the vote still focuses on sources and any users can
build their binaries to verify.
In this way, the automation would be triggered at the formal tag pushed
after the
Hi Tison,
well with most projects that use Maven as distribution chanel, the RC artifacts
are in a staging repo in Nexus. If the vote fails, then this repo is dropped
and nothing is released to the outside world. If it passes, we click on
"release" and the artifacts are released to the outside
> if It's ok to still publish RCs without a vote
I think we vote for RCs so we always provide RCs without a vote. At least
it's what I'm experiencing among Flink, Pulsar, and so on.
Best,
tison.
Christofer Dutz 于2023年7月4日周二 19:52写道：
> Hi Tison,
>
> Well, it definitely is better than without,
Hi Tison,
Well, it definitely is better than without, however I am still not sure, if
It's ok to still publish RCs without a vote.
Currently there's quite a bit of discussion on the matter of releasing binary
artifacts, so I would call this part a bit in flux right now.
But hopefully someone
Hi Chris.
1. Is -rc suffix a satisfied alternative to you?
2. This can be part of binary release topics. I read our policy to release
sources only so I don't push an alert for doing so. But I do assume -rc
suffix could be an improvement before the podling getting graduated.
Best,
tison.
Hi all,
I don't think this procedure is ok according to our policies.
Simply not listing a release on the project page will not help anyone using
this as a dependency.
At least, every time I update a dependency, I never check the projects page, if
this is even a released version.
Chris
Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.
1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
2. Python PyPi -
Hi Tison,
Would it be possible to provide us with links to documentation about
how you deploy your binary artifacts and how they can be revoked if a
vote fails?
I think this is useful for IPMC members when they are reviewing your
release candidates. It's nice to review the binaries as well as
Tison: STOP cross-posting between private and public lists. You have been
advised to stop doing so once, and this is now TWICE. No more.
Regards,
Greg Stein
Infrastructure Administrator, ASF
On Mon, Jul 3, 2023 at 6:01 AM tison wrote:
> Hi Daniel,
>
> Thanks for your information! That can be
One of my Pekko colleagues found that this process is documented. I
wasn't aware that this approach has been approved as long as the
security team signs off.
https://infra.apache.org/release-signing.html#automated-release-signing
On Mon, 3 Jul 2023 at 12:04, tison wrote:
>
> Update mailing
Update mailing list. Or if I should start a new thread totally?
Best,
tison.
tison 于2023年7月3日周一 19:00写道：
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect
> is the lack
Hi Daniel,
Thanks for your information! That can be an alternative for the signing key.
Right now the blocker I met is 403 from the Nexus server which I suspect is
the lack of permissions from the Nexus credentials. Could you confirm or
correct it?
Best,
tison.
tison 于2023年7月3日周一 18:58写道：
>
Hi PJ,
Thanks for sharing your thoughts!
For signing key, it's a resolved topic from my perspective. I use -
1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
2. Load the key from our 1password service, while since it's a specific
key, I feel comfortable to pass it to INFRA
On 2023-07-03 12:52, PJ Fanning wrote:
Adding the Incubator general list.
My view would be that non-snapshot binary artifacts should be signed
with a personal signing key - ideally the signing key that was used to
release the related source release. Unfortunately, this would mean
adding a
Adding the Incubator general list.
My view would be that non-snapshot binary artifacts should be signed
with a personal signing key - ideally the signing key that was used to
release the related source release. Unfortunately, this would mean
adding a user's signing key to the Apache GitHub
16 matches
Mail list logo
