You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Julian Hyde <jh...@apache.org> on 2021/05/01 19:15:10 UTC
Rust development process and the Apache Way
Does anyone have any resources/suggestions for making the Apache
release process work smoothly for a community whose culture expects
very frequent releases?
Some background. I am an ASF member and PMC member of Arrow. I am not
very active in development, but am doing my best to oversee the
project to steer its various sub-communities towards the Apache Way.
Arrow is a thriving project, by any measure. It has implementations in
several languages, and many contributors will tend to contribute in
just one language, and tend to follow the norms of that language. In
particular, Rust developers expect regular releases (a cadence of one
per week is not uncommon). They also build directly from GitHub (they
don't use a source distribution, or rely on pre-compiled artifacts in
a package repository).
The Arrow-Rust developers are currently discussing how they might
bring some of that Rust process into Arrow [1].
So, two problems arise:
* My understanding is that an Apache release is a source release. It
requires a release manager to build and sign a source distribution,
and at least three people need to download and verify that source
distribution. That is an onerous process to perform every week.
* Suppose we were to make source releases less frequently (say once a
month) but more frequently (say weekly) bless minor versions by
tagging them in GitHub. We would effectively be encouraging downstream
projects to rely on unreleased code, and my understanding is that that
is contrary to Apache release policy.
My questions:
1. Are there any languages other than Rust that have a similar process
of building directly from GitHub?
2. Are there any projects (in Rust or other languages) that have
successfully solved the problem of frequent releases?
Julian
[1] https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Rust development process and the Apache Way
Posted by Julian Hyde <jh...@apache.org>.
I wanted to thank everyone for their detailed & thoughtful replies in this thread. The Arrow-Rust community feel that they can streamline the release process to do a source release every two weeks or so, similar to the processes for SkyWalking and Airflow mentioned in the thread.
Julian
On 2021/05/02 09:00:05, Sheng Wu <wu...@gmail.com> wrote:
> Hi Jarek
>
> SkyWalking and Airflow communities always share some similar patterns due
> to our modulization pattern for building systems.
> I think your way should be good from the foundation perspective.
> Meaningwhile in SkyWalking, we rely on auto e2e/unit tests a lot rather
> than manual testing.
> SkyWalking's backend/UI/javaagent with protocols release every 1-1.5
> months, and all PMC would be involved in.
> But other agents and tools are on their own, and which of them have more
> than 3 PMC members, so, after all, we could avoid overheating of voting by
> this way.
>
> Arrow community friends, you could choose which ways you prefer and want to
> do an experiment.
>
> After all, from my understanding, manual testing and over PMC testing are
> not restricted rules for a release.
> PMC approved with compilable and no(or minimal) LICENSE issues are
> expected by the foundation.
> Software always has bugs, the robustness of your release could be
> determined with time, and this is on PMC's call.
>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
>
> Jarek Potiuk <ja...@potiuk.com> 于2021年5月2日周日 下午4:26写道：
>
> > Hi Sheng,
> >
> > We had a similar discussion recently in Apache Airflow, and I think there
> > are ways you can still follow the Apache Way spirit, follow the
> > voting process and keep the community involved. And I personally think
> > involving your community in the release process is the true embodiment of
> > the "community-over-code".
> >
> > In Airflow we used to have one release every few months, but as of Airflow
> > 2.0 we split it into 60+ independent packages (Core Airflow + 60+
> > providers - independent add-ons for Airflow). We also recently started to
> > release a "Python API client" and very soon we will release Helm Chart.
> > Those are all independent releases.
> >
> > Our release process is now that Core Airflow is released every ~ 2 months
> > and the 60+ providers are released with monthly cadence. Roughly every
> > month there are significant "non-doc" changes in 20-30 packages or so so
> > this means that every month we have 20-30 packages to vote on.
> >
> > And yeah, having 30+ voting threads a month would be impossible to handle.
> >
> > So we figured something else.
> >
> > We had a rather heated discussion on how to do it and experimented a bit
> > with it but the very important topic that was raised was the "manual
> > testing" part. We have a very comprehensive, automated testing process -
> > that not only run the tests, but also builds the packages, installs them on
> > top of released Airflow versions, checks if all the modules are importing
> > cleanly and even verify if the automated discovery of those add-ons
> > provides expected results after they are installed. However some of the
> > members of the community (rightfully) thought it is not enough. There needs
> > to be a human factor involved, and it's rather difficult to have one or
> > even few people testing 20-30 different packages every month. And involving
> > the community is the solution.
> >
> > This is what we do now (we are already doing it for the 4th time):
> >
> > 1) we release all the 20-30 packages with a single voting thread. We accept
> > the situation that if someone raises an issue with a specific package, it
> > can be dropped from the release without invalidating the whole voting (this
> > is at the discretion of the release manager who has the ultimate power
> > there - and it's perfectly ok IMHO with ASF rules).
> > 2) the release manager not only announces the release but also prepares an
> > Issue in GitHub where contributors who contributed the fixes are
> > `@mentioned` and asked to test the package being released - for every
> > provider "package" there is a list of people who 'contributed' to it (this
> > is not yet fully automated but can be). Also in some cases the release
> > manager decides that change is very simple and needs no testing other than
> > installing the new package.
> > 3) we ask those contributors for help and verify of their fixes/new feature
> > in the RC of the provider they contributed to and keep track via comments /
> > updating github issue
> > 4) the PMCs nor release manager does not have to test all those providers -
> > if the contributors confirm that the new RC works, we trust it.
> > 5) PMC member's main role is to verify if the packages are
> > signed/checksummed properly, if the sources have all the licences (all that
> > is mostly semi-automated) and to be aware of the testing status.
> > 6) The release manager is mostly responsible for the "mechanics" of the
> > release, reminders etc. but with single issue/voting thread it is
> > manageable even if you release 20-30 packages
> >
> > This worked already 3 times, and we have just started to run another Voting
> > thread for the "May" release wave:
> >
> > The voting thread:
> >
> > https://lists.apache.org/thread.html/rb3fb597796a5b1bf83f97879e6783049dc8f2496b594bc5f3641eee3%40%3Cdev.airflow.apache.org%3E
> > , the GitHub Issue: https://github.com/apache/airflow/issues/15623
> >
> > The previous GH issues for releases are:
> > https://github.com/apache/airflow/issues/15241,
> > https://github.com/apache/airflow/issues/14670,
> > https://github.com/apache/airflow/issues/14511
> >
> > Most of the 20-30+ package preparation process is semi-automated. It takes
> > little time for the release manager to prepare and follow up the voting.
> > This is not much (I was acting as one so far and it is rather easy and
> > takes very little time).
> >
> > This approach involves the community and makes people who made the
> > fixes/added features become also stakeholders of the release. They are
> > involved, responsive and usually happy to help and test their changes
> > (knowing that we are just about to release them).
> >
> > And I always thank them for their help.
> >
> > J.
> >
> >
> >
> > On Sun, May 2, 2021 at 2:55 AM Sheng Wu <wu...@gmail.com> wrote:
> >
> > > Hi Julian
> > >
> > > I think a higher frequency release is not an issue.
> > > You just need to have enough PMC members to vote.
> > > Compiling, LICENSE, sign checks are the key, instead, the feature tests
> > and
> > > whether you are releasing a stable release, that is PMC's call.
> > > The minimal time requirement is only 3 days to make global people having
> > a
> > > chance to check the release.
> > > This should not stop the community to do a weekly release.
> > >
> > > SkyWalking doesn't do a weekly release every month, but due to 10+
> > > subprojects, it is common we do 1-2 releases weekly.
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > >
> > > Julian Hyde <jh...@apache.org> 于2021年5月2日周日 上午3:15写道：
> > >
> > > > Does anyone have any resources/suggestions for making the Apache
> > > > release process work smoothly for a community whose culture expects
> > > > very frequent releases?
> > > >
> > > > Some background. I am an ASF member and PMC member of Arrow. I am not
> > > > very active in development, but am doing my best to oversee the
> > > > project to steer its various sub-communities towards the Apache Way.
> > > >
> > > > Arrow is a thriving project, by any measure. It has implementations in
> > > > several languages, and many contributors will tend to contribute in
> > > > just one language, and tend to follow the norms of that language. In
> > > > particular, Rust developers expect regular releases (a cadence of one
> > > > per week is not uncommon). They also build directly from GitHub (they
> > > > don't use a source distribution, or rely on pre-compiled artifacts in
> > > > a package repository).
> > > >
> > > > The Arrow-Rust developers are currently discussing how they might
> > > > bring some of that Rust process into Arrow [1].
> > > >
> > > > So, two problems arise:
> > > > * My understanding is that an Apache release is a source release. It
> > > > requires a release manager to build and sign a source distribution,
> > > > and at least three people need to download and verify that source
> > > > distribution. That is an onerous process to perform every week.
> > > > * Suppose we were to make source releases less frequently (say once a
> > > > month) but more frequently (say weekly) bless minor versions by
> > > > tagging them in GitHub. We would effectively be encouraging downstream
> > > > projects to rely on unreleased code, and my understanding is that that
> > > > is contrary to Apache release policy.
> > > >
> > > > My questions:
> > > > 1. Are there any languages other than Rust that have a similar process
> > > > of building directly from GitHub?
> > > > 2. Are there any projects (in Rust or other languages) that have
> > > > successfully solved the problem of frequent releases?
> > > >
> > > > Julian
> > > >
> > > > [1]
> > > >
> > >
> > https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > > For additional commands, e-mail: dev-help@community.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > +48 660 796 129
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Rust development process and the Apache Way
Posted by Sheng Wu <wu...@gmail.com>.
Hi Jarek
SkyWalking and Airflow communities always share some similar patterns due
to our modulization pattern for building systems.
I think your way should be good from the foundation perspective.
Meaningwhile in SkyWalking, we rely on auto e2e/unit tests a lot rather
than manual testing.
SkyWalking's backend/UI/javaagent with protocols release every 1-1.5
months, and all PMC would be involved in.
But other agents and tools are on their own, and which of them have more
than 3 PMC members, so, after all, we could avoid overheating of voting by
this way.
Arrow community friends, you could choose which ways you prefer and want to
do an experiment.
After all, from my understanding, manual testing and over PMC testing are
not restricted rules for a release.
PMC approved with compilable and no(or minimal) LICENSE issues are
expected by the foundation.
Software always has bugs, the robustness of your release could be
determined with time, and this is on PMC's call.
Sheng Wu 吴晟
Twitter, wusheng1108
Jarek Potiuk <ja...@potiuk.com> 于2021年5月2日周日 下午4:26写道：
> Hi Sheng,
>
> We had a similar discussion recently in Apache Airflow, and I think there
> are ways you can still follow the Apache Way spirit, follow the
> voting process and keep the community involved. And I personally think
> involving your community in the release process is the true embodiment of
> the "community-over-code".
>
> In Airflow we used to have one release every few months, but as of Airflow
> 2.0 we split it into 60+ independent packages (Core Airflow + 60+
> providers - independent add-ons for Airflow). We also recently started to
> release a "Python API client" and very soon we will release Helm Chart.
> Those are all independent releases.
>
> Our release process is now that Core Airflow is released every ~ 2 months
> and the 60+ providers are released with monthly cadence. Roughly every
> month there are significant "non-doc" changes in 20-30 packages or so so
> this means that every month we have 20-30 packages to vote on.
>
> And yeah, having 30+ voting threads a month would be impossible to handle.
>
> So we figured something else.
>
> We had a rather heated discussion on how to do it and experimented a bit
> with it but the very important topic that was raised was the "manual
> testing" part. We have a very comprehensive, automated testing process -
> that not only run the tests, but also builds the packages, installs them on
> top of released Airflow versions, checks if all the modules are importing
> cleanly and even verify if the automated discovery of those add-ons
> provides expected results after they are installed. However some of the
> members of the community (rightfully) thought it is not enough. There needs
> to be a human factor involved, and it's rather difficult to have one or
> even few people testing 20-30 different packages every month. And involving
> the community is the solution.
>
> This is what we do now (we are already doing it for the 4th time):
>
> 1) we release all the 20-30 packages with a single voting thread. We accept
> the situation that if someone raises an issue with a specific package, it
> can be dropped from the release without invalidating the whole voting (this
> is at the discretion of the release manager who has the ultimate power
> there - and it's perfectly ok IMHO with ASF rules).
> 2) the release manager not only announces the release but also prepares an
> Issue in GitHub where contributors who contributed the fixes are
> `@mentioned` and asked to test the package being released - for every
> provider "package" there is a list of people who 'contributed' to it (this
> is not yet fully automated but can be). Also in some cases the release
> manager decides that change is very simple and needs no testing other than
> installing the new package.
> 3) we ask those contributors for help and verify of their fixes/new feature
> in the RC of the provider they contributed to and keep track via comments /
> updating github issue
> 4) the PMCs nor release manager does not have to test all those providers -
> if the contributors confirm that the new RC works, we trust it.
> 5) PMC member's main role is to verify if the packages are
> signed/checksummed properly, if the sources have all the licences (all that
> is mostly semi-automated) and to be aware of the testing status.
> 6) The release manager is mostly responsible for the "mechanics" of the
> release, reminders etc. but with single issue/voting thread it is
> manageable even if you release 20-30 packages
>
> This worked already 3 times, and we have just started to run another Voting
> thread for the "May" release wave:
>
> The voting thread:
>
> https://lists.apache.org/thread.html/rb3fb597796a5b1bf83f97879e6783049dc8f2496b594bc5f3641eee3%40%3Cdev.airflow.apache.org%3E
> , the GitHub Issue: https://github.com/apache/airflow/issues/15623
>
> The previous GH issues for releases are:
> https://github.com/apache/airflow/issues/15241,
> https://github.com/apache/airflow/issues/14670,
> https://github.com/apache/airflow/issues/14511
>
> Most of the 20-30+ package preparation process is semi-automated. It takes
> little time for the release manager to prepare and follow up the voting.
> This is not much (I was acting as one so far and it is rather easy and
> takes very little time).
>
> This approach involves the community and makes people who made the
> fixes/added features become also stakeholders of the release. They are
> involved, responsive and usually happy to help and test their changes
> (knowing that we are just about to release them).
>
> And I always thank them for their help.
>
> J.
>
>
>
> On Sun, May 2, 2021 at 2:55 AM Sheng Wu <wu...@gmail.com> wrote:
>
> > Hi Julian
> >
> > I think a higher frequency release is not an issue.
> > You just need to have enough PMC members to vote.
> > Compiling, LICENSE, sign checks are the key, instead, the feature tests
> and
> > whether you are releasing a stable release, that is PMC's call.
> > The minimal time requirement is only 3 days to make global people having
> a
> > chance to check the release.
> > This should not stop the community to do a weekly release.
> >
> > SkyWalking doesn't do a weekly release every month, but due to 10+
> > subprojects, it is common we do 1-2 releases weekly.
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> >
> > Julian Hyde <jh...@apache.org> 于2021年5月2日周日 上午3:15写道：
> >
> > > Does anyone have any resources/suggestions for making the Apache
> > > release process work smoothly for a community whose culture expects
> > > very frequent releases?
> > >
> > > Some background. I am an ASF member and PMC member of Arrow. I am not
> > > very active in development, but am doing my best to oversee the
> > > project to steer its various sub-communities towards the Apache Way.
> > >
> > > Arrow is a thriving project, by any measure. It has implementations in
> > > several languages, and many contributors will tend to contribute in
> > > just one language, and tend to follow the norms of that language. In
> > > particular, Rust developers expect regular releases (a cadence of one
> > > per week is not uncommon). They also build directly from GitHub (they
> > > don't use a source distribution, or rely on pre-compiled artifacts in
> > > a package repository).
> > >
> > > The Arrow-Rust developers are currently discussing how they might
> > > bring some of that Rust process into Arrow [1].
> > >
> > > So, two problems arise:
> > > * My understanding is that an Apache release is a source release. It
> > > requires a release manager to build and sign a source distribution,
> > > and at least three people need to download and verify that source
> > > distribution. That is an onerous process to perform every week.
> > > * Suppose we were to make source releases less frequently (say once a
> > > month) but more frequently (say weekly) bless minor versions by
> > > tagging them in GitHub. We would effectively be encouraging downstream
> > > projects to rely on unreleased code, and my understanding is that that
> > > is contrary to Apache release policy.
> > >
> > > My questions:
> > > 1. Are there any languages other than Rust that have a similar process
> > > of building directly from GitHub?
> > > 2. Are there any projects (in Rust or other languages) that have
> > > successfully solved the problem of frequent releases?
> > >
> > > Julian
> > >
> > > [1]
> > >
> >
> https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> > >
> >
>
>
> --
> +48 660 796 129
>
Re: Rust development process and the Apache Way
Posted by Jarek Potiuk <ja...@potiuk.com>.
Hi Sheng,
We had a similar discussion recently in Apache Airflow, and I think there
are ways you can still follow the Apache Way spirit, follow the
voting process and keep the community involved. And I personally think
involving your community in the release process is the true embodiment of
the "community-over-code".
In Airflow we used to have one release every few months, but as of Airflow
2.0 we split it into 60+ independent packages (Core Airflow + 60+
providers - independent add-ons for Airflow). We also recently started to
release a "Python API client" and very soon we will release Helm Chart.
Those are all independent releases.
Our release process is now that Core Airflow is released every ~ 2 months
and the 60+ providers are released with monthly cadence. Roughly every
month there are significant "non-doc" changes in 20-30 packages or so so
this means that every month we have 20-30 packages to vote on.
And yeah, having 30+ voting threads a month would be impossible to handle.
So we figured something else.
We had a rather heated discussion on how to do it and experimented a bit
with it but the very important topic that was raised was the "manual
testing" part. We have a very comprehensive, automated testing process -
that not only run the tests, but also builds the packages, installs them on
top of released Airflow versions, checks if all the modules are importing
cleanly and even verify if the automated discovery of those add-ons
provides expected results after they are installed. However some of the
members of the community (rightfully) thought it is not enough. There needs
to be a human factor involved, and it's rather difficult to have one or
even few people testing 20-30 different packages every month. And involving
the community is the solution.
This is what we do now (we are already doing it for the 4th time):
1) we release all the 20-30 packages with a single voting thread. We accept
the situation that if someone raises an issue with a specific package, it
can be dropped from the release without invalidating the whole voting (this
is at the discretion of the release manager who has the ultimate power
there - and it's perfectly ok IMHO with ASF rules).
2) the release manager not only announces the release but also prepares an
Issue in GitHub where contributors who contributed the fixes are
`@mentioned` and asked to test the package being released - for every
provider "package" there is a list of people who 'contributed' to it (this
is not yet fully automated but can be). Also in some cases the release
manager decides that change is very simple and needs no testing other than
installing the new package.
3) we ask those contributors for help and verify of their fixes/new feature
in the RC of the provider they contributed to and keep track via comments /
updating github issue
4) the PMCs nor release manager does not have to test all those providers -
if the contributors confirm that the new RC works, we trust it.
5) PMC member's main role is to verify if the packages are
signed/checksummed properly, if the sources have all the licences (all that
is mostly semi-automated) and to be aware of the testing status.
6) The release manager is mostly responsible for the "mechanics" of the
release, reminders etc. but with single issue/voting thread it is
manageable even if you release 20-30 packages
This worked already 3 times, and we have just started to run another Voting
thread for the "May" release wave:
The voting thread:
https://lists.apache.org/thread.html/rb3fb597796a5b1bf83f97879e6783049dc8f2496b594bc5f3641eee3%40%3Cdev.airflow.apache.org%3E
, the GitHub Issue: https://github.com/apache/airflow/issues/15623
The previous GH issues for releases are:
https://github.com/apache/airflow/issues/15241,
https://github.com/apache/airflow/issues/14670,
https://github.com/apache/airflow/issues/14511
Most of the 20-30+ package preparation process is semi-automated. It takes
little time for the release manager to prepare and follow up the voting.
This is not much (I was acting as one so far and it is rather easy and
takes very little time).
This approach involves the community and makes people who made the
fixes/added features become also stakeholders of the release. They are
involved, responsive and usually happy to help and test their changes
(knowing that we are just about to release them).
And I always thank them for their help.
J.
On Sun, May 2, 2021 at 2:55 AM Sheng Wu <wu...@gmail.com> wrote:
> Hi Julian
>
> I think a higher frequency release is not an issue.
> You just need to have enough PMC members to vote.
> Compiling, LICENSE, sign checks are the key, instead, the feature tests and
> whether you are releasing a stable release, that is PMC's call.
> The minimal time requirement is only 3 days to make global people having a
> chance to check the release.
> This should not stop the community to do a weekly release.
>
> SkyWalking doesn't do a weekly release every month, but due to 10+
> subprojects, it is common we do 1-2 releases weekly.
>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
>
> Julian Hyde <jh...@apache.org> 于2021年5月2日周日 上午3:15写道：
>
> > Does anyone have any resources/suggestions for making the Apache
> > release process work smoothly for a community whose culture expects
> > very frequent releases?
> >
> > Some background. I am an ASF member and PMC member of Arrow. I am not
> > very active in development, but am doing my best to oversee the
> > project to steer its various sub-communities towards the Apache Way.
> >
> > Arrow is a thriving project, by any measure. It has implementations in
> > several languages, and many contributors will tend to contribute in
> > just one language, and tend to follow the norms of that language. In
> > particular, Rust developers expect regular releases (a cadence of one
> > per week is not uncommon). They also build directly from GitHub (they
> > don't use a source distribution, or rely on pre-compiled artifacts in
> > a package repository).
> >
> > The Arrow-Rust developers are currently discussing how they might
> > bring some of that Rust process into Arrow [1].
> >
> > So, two problems arise:
> > * My understanding is that an Apache release is a source release. It
> > requires a release manager to build and sign a source distribution,
> > and at least three people need to download and verify that source
> > distribution. That is an onerous process to perform every week.
> > * Suppose we were to make source releases less frequently (say once a
> > month) but more frequently (say weekly) bless minor versions by
> > tagging them in GitHub. We would effectively be encouraging downstream
> > projects to rely on unreleased code, and my understanding is that that
> > is contrary to Apache release policy.
> >
> > My questions:
> > 1. Are there any languages other than Rust that have a similar process
> > of building directly from GitHub?
> > 2. Are there any projects (in Rust or other languages) that have
> > successfully solved the problem of frequent releases?
> >
> > Julian
> >
> > [1]
> >
> https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
>
--
+48 660 796 129
Re: Rust development process and the Apache Way
Posted by Sheng Wu <wu...@gmail.com>.
Hi Julian
I think a higher frequency release is not an issue.
You just need to have enough PMC members to vote.
Compiling, LICENSE, sign checks are the key, instead, the feature tests and
whether you are releasing a stable release, that is PMC's call.
The minimal time requirement is only 3 days to make global people having a
chance to check the release.
This should not stop the community to do a weekly release.
SkyWalking doesn't do a weekly release every month, but due to 10+
subprojects, it is common we do 1-2 releases weekly.
Sheng Wu 吴晟
Twitter, wusheng1108
Julian Hyde <jh...@apache.org> 于2021年5月2日周日 上午3:15写道：
> Does anyone have any resources/suggestions for making the Apache
> release process work smoothly for a community whose culture expects
> very frequent releases?
>
> Some background. I am an ASF member and PMC member of Arrow. I am not
> very active in development, but am doing my best to oversee the
> project to steer its various sub-communities towards the Apache Way.
>
> Arrow is a thriving project, by any measure. It has implementations in
> several languages, and many contributors will tend to contribute in
> just one language, and tend to follow the norms of that language. In
> particular, Rust developers expect regular releases (a cadence of one
> per week is not uncommon). They also build directly from GitHub (they
> don't use a source distribution, or rely on pre-compiled artifacts in
> a package repository).
>
> The Arrow-Rust developers are currently discussing how they might
> bring some of that Rust process into Arrow [1].
>
> So, two problems arise:
> * My understanding is that an Apache release is a source release. It
> requires a release manager to build and sign a source distribution,
> and at least three people need to download and verify that source
> distribution. That is an onerous process to perform every week.
> * Suppose we were to make source releases less frequently (say once a
> month) but more frequently (say weekly) bless minor versions by
> tagging them in GitHub. We would effectively be encouraging downstream
> projects to rely on unreleased code, and my understanding is that that
> is contrary to Apache release policy.
>
> My questions:
> 1. Are there any languages other than Rust that have a similar process
> of building directly from GitHub?
> 2. Are there any projects (in Rust or other languages) that have
> successfully solved the problem of frequent releases?
>
> Julian
>
> [1]
> https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Rust development process and the Apache Way
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
It is community over code in Apache. By having people, beyond tests, verify
your releases, you build a community rather than a bunch of releases. The
releases of your prohect are not the primary point here. It’s about
building a community which means having at least three people to verify
your releases.
Gj
On Sat, 1 May 2021 at 21:33, Julian Hyde <jh...@apache.org> wrote:
> The Arrow-Rust modules are much smaller than NetBeans. They are
> libraries and can be continuously verified by automated tests, and
> therefore, from a software quality standpoint, it is possible to
> release at any time. But, to this point, the release cadence has been
> artificially slowed to about 3 months because of the need to
> synchronize with the rest of Arrow, and the effort required to vote on
> a release.
>
> On Sat, May 1, 2021 at 12:26 PM Geertjan Wielenga
> <ge...@googlemail.com.invalid> wrote:
> >
> > Speaking as PMC of Apache NetBeans, we have a new release every quarter.
> > That’s about as much as one can do for a large project. If you find the
> > requirement to have three people to verify your releases onerous, are you
> > saying that so far less than three people have been verifying your
> releases
> > thus far? Two? Or one? Sounds a bit dubious to me..
> >
> > Gj
> >
> >
> > On Sat, 1 May 2021 at 21:15, Julian Hyde <jh...@apache.org> wrote:
> >
> > > Does anyone have any resources/suggestions for making the Apache
> > > release process work smoothly for a community whose culture expects
> > > very frequent releases?
> > >
> > > Some background. I am an ASF member and PMC member of Arrow. I am not
> > > very active in development, but am doing my best to oversee the
> > > project to steer its various sub-communities towards the Apache Way.
> > >
> > > Arrow is a thriving project, by any measure. It has implementations in
> > > several languages, and many contributors will tend to contribute in
> > > just one language, and tend to follow the norms of that language. In
> > > particular, Rust developers expect regular releases (a cadence of one
> > > per week is not uncommon). They also build directly from GitHub (they
> > > don't use a source distribution, or rely on pre-compiled artifacts in
> > > a package repository).
> > >
> > > The Arrow-Rust developers are currently discussing how they might
> > > bring some of that Rust process into Arrow [1].
> > >
> > > So, two problems arise:
> > > * My understanding is that an Apache release is a source release. It
> > > requires a release manager to build and sign a source distribution,
> > > and at least three people need to download and verify that source
> > > distribution. That is an onerous process to perform every week.
> > > * Suppose we were to make source releases less frequently (say once a
> > > month) but more frequently (say weekly) bless minor versions by
> > > tagging them in GitHub. We would effectively be encouraging downstream
> > > projects to rely on unreleased code, and my understanding is that that
> > > is contrary to Apache release policy.
> > >
> > > My questions:
> > > 1. Are there any languages other than Rust that have a similar process
> > > of building directly from GitHub?
> > > 2. Are there any projects (in Rust or other languages) that have
> > > successfully solved the problem of frequent releases?
> > >
> > > Julian
> > >
> > > [1]
> > >
> https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Rust development process and the Apache Way
Posted by Julian Hyde <jh...@apache.org>.
The Arrow-Rust modules are much smaller than NetBeans. They are
libraries and can be continuously verified by automated tests, and
therefore, from a software quality standpoint, it is possible to
release at any time. But, to this point, the release cadence has been
artificially slowed to about 3 months because of the need to
synchronize with the rest of Arrow, and the effort required to vote on
a release.
On Sat, May 1, 2021 at 12:26 PM Geertjan Wielenga
<ge...@googlemail.com.invalid> wrote:
>
> Speaking as PMC of Apache NetBeans, we have a new release every quarter.
> That’s about as much as one can do for a large project. If you find the
> requirement to have three people to verify your releases onerous, are you
> saying that so far less than three people have been verifying your releases
> thus far? Two? Or one? Sounds a bit dubious to me..
>
> Gj
>
>
> On Sat, 1 May 2021 at 21:15, Julian Hyde <jh...@apache.org> wrote:
>
> > Does anyone have any resources/suggestions for making the Apache
> > release process work smoothly for a community whose culture expects
> > very frequent releases?
> >
> > Some background. I am an ASF member and PMC member of Arrow. I am not
> > very active in development, but am doing my best to oversee the
> > project to steer its various sub-communities towards the Apache Way.
> >
> > Arrow is a thriving project, by any measure. It has implementations in
> > several languages, and many contributors will tend to contribute in
> > just one language, and tend to follow the norms of that language. In
> > particular, Rust developers expect regular releases (a cadence of one
> > per week is not uncommon). They also build directly from GitHub (they
> > don't use a source distribution, or rely on pre-compiled artifacts in
> > a package repository).
> >
> > The Arrow-Rust developers are currently discussing how they might
> > bring some of that Rust process into Arrow [1].
> >
> > So, two problems arise:
> > * My understanding is that an Apache release is a source release. It
> > requires a release manager to build and sign a source distribution,
> > and at least three people need to download and verify that source
> > distribution. That is an onerous process to perform every week.
> > * Suppose we were to make source releases less frequently (say once a
> > month) but more frequently (say weekly) bless minor versions by
> > tagging them in GitHub. We would effectively be encouraging downstream
> > projects to rely on unreleased code, and my understanding is that that
> > is contrary to Apache release policy.
> >
> > My questions:
> > 1. Are there any languages other than Rust that have a similar process
> > of building directly from GitHub?
> > 2. Are there any projects (in Rust or other languages) that have
> > successfully solved the problem of frequent releases?
> >
> > Julian
> >
> > [1]
> > https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Rust development process and the Apache Way
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
Speaking as PMC of Apache NetBeans, we have a new release every quarter.
That’s about as much as one can do for a large project. If you find the
requirement to have three people to verify your releases onerous, are you
saying that so far less than three people have been verifying your releases
thus far? Two? Or one? Sounds a bit dubious to me..
Gj
On Sat, 1 May 2021 at 21:15, Julian Hyde <jh...@apache.org> wrote:
> Does anyone have any resources/suggestions for making the Apache
> release process work smoothly for a community whose culture expects
> very frequent releases?
>
> Some background. I am an ASF member and PMC member of Arrow. I am not
> very active in development, but am doing my best to oversee the
> project to steer its various sub-communities towards the Apache Way.
>
> Arrow is a thriving project, by any measure. It has implementations in
> several languages, and many contributors will tend to contribute in
> just one language, and tend to follow the norms of that language. In
> particular, Rust developers expect regular releases (a cadence of one
> per week is not uncommon). They also build directly from GitHub (they
> don't use a source distribution, or rely on pre-compiled artifacts in
> a package repository).
>
> The Arrow-Rust developers are currently discussing how they might
> bring some of that Rust process into Arrow [1].
>
> So, two problems arise:
> * My understanding is that an Apache release is a source release. It
> requires a release manager to build and sign a source distribution,
> and at least three people need to download and verify that source
> distribution. That is an onerous process to perform every week.
> * Suppose we were to make source releases less frequently (say once a
> month) but more frequently (say weekly) bless minor versions by
> tagging them in GitHub. We would effectively be encouraging downstream
> projects to rely on unreleased code, and my understanding is that that
> is contrary to Apache release policy.
>
> My questions:
> 1. Are there any languages other than Rust that have a similar process
> of building directly from GitHub?
> 2. Are there any projects (in Rust or other languages) that have
> successfully solved the problem of frequent releases?
>
> Julian
>
> [1]
> https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>