his automatically by creating a cloned
> > > Git repository for test.
> > >
> > > It's better that we have a Web site to show generated pages.
> > > We can create
> > > https://github.com/apache/arrow-site/tree/asf-site/nightly
> > > and use it
site for this? (arrow-nightly.ursalabs.org?)
> >
> > dev/release/post-04-rubygems.sh:
> >
> > We may be able to use GitHub Package Registry[2] to upload
> > RubyGems. We can use "pre-release" package feature of
> > https://rubygems.org/ but it's not s
e to use GitHub Package Registry[2] to upload
> RubyGems. We can use "pre-release" package feature of
> https://rubygems.org/ but it's not suitable for
> nightly. It's for RC or beta release.
>
> [2] https://github.blog/2019-05-10-introducing-github-package-registry/
>
.sh:
We may be able to use GitHub Package Registry[2] to upload
NuGet packages.
dev/release/post-07-rust.sh:
I don't have any idea. But it must be ran
automatically. It's always failed. I needed to run each
command manually.
dev/release/post-08-remove-rc.sh:
We'll be able to skip th
The PMC member and their GPG keys need to be in the loop at some
point. The release artifacts can be produced by some kind of CI/CD
system so long as the PMC member has confidence in the security of
those artifacts before signing them. For example, we build the
official binary packages on public CI
To what extent would it be possible to automate the release process via
CICD?
On Wed, Jul 31, 2019 at 9:19 AM Wes McKinney wrote:
> I think one thing that would help would be improving the
> reproducibility of the source release process. The RM has to have
> their machine configured in a particu
I think one thing that would help would be improving the
reproducibility of the source release process. The RM has to have
their machine configured in a particular way for it to work.
Before anyone says "Docker" it isn't an easy solution because the
release scripts need to be able to create git co
I just wanted to bump this thread. Kou and Krisztián as the last two
release managers is there any specific infrastructure that you think might
have helped?
Thanks,
Micah
On Wed, Jul 17, 2019 at 11:29 PM Micah Kornfield
wrote:
> I'd can help as well, but not exactly sure where to start. It se
I'd can help as well, but not exactly sure where to start. It seems like
there are already some JIRAs opened [1]
for improving the release? Could someone more familiar with the process
pick out the highest priority ones? Do more need to be opened?
Thanks,
Micah
[1]
https://issues.apache.org/jir
To be effective at improving the life of release managers, the nightly
release process really should use as close as possible to the same
scripts that the RM uses to produce the release. Otherwise we could
have a situation where the nightlies succeed but there is some problem
that either fails an R
I would like to volunteer to help with Java and Rust release process work,
especially nightly releases.
Although I'm not that familiar with the Java implementation of Arrow, I
have been using Java and Maven for a very long time.
Do we envisage a single nightly release process that releases all la
On Sun, Jul 7, 2019 at 7:40 PM Sutou Kouhei wrote:
>
> Hi,
>
> > in future releases we should
> > institute a minimum 24-hour "quiet period" after any community
> > feedback on a release candidate to allow issues to be examined
> > further.
>
> I agree with this. I'll do so when I do a release man
Hi,
> in future releases we should
> institute a minimum 24-hour "quiet period" after any community
> feedback on a release candidate to allow issues to be examined
> further.
I agree with this. I'll do so when I do a release manager in
the future.
> To be able to release more often, two things
13 matches
Mail list logo
