Re: Rust development process and the Apache Way
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 于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-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Brackets an Adobe Project.
Hi, Kerry, I too think Apache would be a good home for Brackets. As you may know, each Apache project has a Project Management Committee (PMC) that is responsible for it. You, as a Brackets community member, are ideally placed to find a half dozen other Brackets users who should be willing to be the core of that PMC. Apache has a great incubation program that helps new projects and their PMCs find their feet in open source and grow into working in The Apache Way. With such a PMC identified, it becomes much easier to negotiate a donation of code and resources from Adobe. If this seems interesting, I can point you to some documents that explain the incubation process. A On Sat., May 1, 2021, 5:04 p.m. Kerry Voss, wrote: > I am sure that we all have heard that Adobe is no longer interested in > maintaining Brackets. I am looking at Apache to adopt the Brackets > Project and think it would be a good fit for your organization. I think > that it would be a great time for you to strike a deal with Adobe to > takeover the project and maintain it on Apache.org. I have nothing to do > with Adobe but I am a Brackets User as are many and it does have a > rather large community of people like me that use it everyday and don't > wish to see it go or be mishandled by some Organization. I thought of > you taking open office over and you have done a wonderful job of > maintaining it. If you could look into it I think it would be a good > move for you and you would be taking over an Adobe Product of great open > source value to the community. > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Brackets an Adobe Project.
I am sure that we all have heard that Adobe is no longer interested in maintaining Brackets. I am looking at Apache to adopt the Brackets Project and think it would be a good fit for your organization. I think that it would be a great time for you to strike a deal with Adobe to takeover the project and maintain it on Apache.org. I have nothing to do with Adobe but I am a Brackets User as are many and it does have a rather large community of people like me that use it everyday and don't wish to see it go or be mishandled by some Organization. I thought of you taking open office over and you have done a wonderful job of maintaining it. If you could look into it I think it would be a good move for you and you would be taking over an Adobe Product of great open source value to the community. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Rust development process and the Apache Way
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 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 > 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 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-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Rust development process and the Apache Way
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 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 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-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Rust development process and the Apache Way
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 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-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
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-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
ASF-wide community support files on GitHub
Recently, a user contributed a pull request for Accumulo to add .github/CODE_OF_CONDUCT.md I can see this being useful so that the ASF Code of Conduct is presented in the GitHub UI. However, I don't think every project needs to do this. I propose ComDev work with INFRA to create https://github.com/apache/.github repository to host such common files, as described in https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/ ; projects can, of course, override these default files. The main annoyance I think is that it wouldn't quite fit the normal repository naming convention, so it would have to be a special case. I'm proposing this here, because I think ComDev might be the most appropriate "owner" of the content of that repository. Initially, it could just include a `.github/CODE_OF_CONDUCT.md` file that contains the same content as https://www.apache.org/foundation/policies/conduct Other files, like `.github/SUPPORT.md` can be added later if there's something appropriate to put there. An example in action: https://github.com/revelc/.github/tree/main/.github Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[FINAL REMINDER] CFP for ApacheCon@Home and ApacheCon Asia Closes on 3rd May 2021
Hi All We have seen a trend where many of our CFP submissions come in during the final week and especially the last few days..and this year is no exception :-) This is a final reminder that the CFP for both ApacheCon@Home and ApacheCon Asia will be closing on Monday, May 3rd, 2021 at 8:00 AM (UTC). Please do not wait until the last minute.. If you haven't submitted your talk yet then you only have a short time left to do it. If you need some ideas or inspiration about what to submit then please take a look at my previous reminder email here https://s.apache.org/dfj9n My understanding is that there will be no extensions to the CFP so if you do not get your submission sent in time, then you will miss out. I've included the links to the CFPs again below: CFP Apachcon Asia https://acasia2021.jamhosted.net CFP ApacheCon@Home https://acah2021.jamhosted.net You can find all the details about both ApacheCons on the ApacheCon site. https://www.apachecon.com/ Looking forward to seeing your submissions! Thanks Sharan - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: ASF and Healthcare initiative
On Sat, 1 May 2021 at 08:40, Javi Roman wrote: > > Sebb, that's a good idea, the wiki space could be a beginning. > > I'm going to request (INFRA) a Wiki space for this initiative: > https://cwiki.apache.org/confluence/display/HEALTH/Home > > and a mailing list for discussing: > hea...@apache.org > > Please let me know if I have your support to request these resources from > INFRA (linking the JIRA tickets to this conversation). I suggest these resources are requested under the community.a.o project. We should not be asking for more top-level resources unless absolutely necessary. Existing TLPs such as community can use https://selfserve.apache.org/ to create mailing lists and Confluence spaces without involving Infra, who are already very busy. > -- > Javi Roman > > Twitter: @javiromanrh > GitHub: github.com/javiroman > Linkedin: es.linkedin.com/in/javiroman > Big Data Blog: dataintensive.info > > > On Fri, Apr 30, 2021 at 11:44 AM sebb wrote: > > > How about using the Wiki for collecting the information? > > > > Easier to set up and easy to maintain. > > > > If the content eventually outgrows the wiki it could be moved later > > (with redirects added). > > > > On Fri, 30 Apr 2021 at 06:22, Javi Roman wrote: > > > > > > Probably cTakes PMC could be interesting in requesting the resources to > > > INFRA: > > > > > > 1. health.apache.org > > > 2. hea...@apache.org > > > > > > So this PMC may be the clear owner (I would like to do it by myself, but > > > unfortunately I'm a PPMC of Incubator retired project). > > > > > > -- > > > Javi Roman > > > > > > On Thu, Apr 29, 2021 at 3:42 PM Bertrand Delacretaz < > > bdelacre...@apache.org> > > > wrote: > > > > > > > Hi, > > > > > > > > On Thu, Apr 29, 2021 at 3:24 PM Rich Bowen wrote: > > > > > ...I would encourage you to > > > > > talk with Infra, next, regarding the hostname, email address, and a > > VM > > > > > to run a site on. I expect that if you have a few PMC members backing > > > > > it, and don't expect Infra to provide you any services... > > > > > > > > From an oversight point of view I think it's good for an existing PMC > > > > to "own" a new website that might be created at health.apache.org. It > > > > can be any of the interested PMCs and to me the goal is just to make > > > > sure that website has a clear owner at the Foundation level. > > > > > > > > So the simplest is probably for one of those PMCs to request creation > > > > of the new website, with the understanding that they will welcome > > > > contributions from other PMCs. > > > > > > > > -Bertrand > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: ASF and Healthcare initiative
Sebb, that's a good idea, the wiki space could be a beginning. I'm going to request (INFRA) a Wiki space for this initiative: https://cwiki.apache.org/confluence/display/HEALTH/Home and a mailing list for discussing: hea...@apache.org Please let me know if I have your support to request these resources from INFRA (linking the JIRA tickets to this conversation). -- Javi Roman Twitter: @javiromanrh GitHub: github.com/javiroman Linkedin: es.linkedin.com/in/javiroman Big Data Blog: dataintensive.info On Fri, Apr 30, 2021 at 11:44 AM sebb wrote: > How about using the Wiki for collecting the information? > > Easier to set up and easy to maintain. > > If the content eventually outgrows the wiki it could be moved later > (with redirects added). > > On Fri, 30 Apr 2021 at 06:22, Javi Roman wrote: > > > > Probably cTakes PMC could be interesting in requesting the resources to > > INFRA: > > > > 1. health.apache.org > > 2. hea...@apache.org > > > > So this PMC may be the clear owner (I would like to do it by myself, but > > unfortunately I'm a PPMC of Incubator retired project). > > > > -- > > Javi Roman > > > > On Thu, Apr 29, 2021 at 3:42 PM Bertrand Delacretaz < > bdelacre...@apache.org> > > wrote: > > > > > Hi, > > > > > > On Thu, Apr 29, 2021 at 3:24 PM Rich Bowen wrote: > > > > ...I would encourage you to > > > > talk with Infra, next, regarding the hostname, email address, and a > VM > > > > to run a site on. I expect that if you have a few PMC members backing > > > > it, and don't expect Infra to provide you any services... > > > > > > From an oversight point of view I think it's good for an existing PMC > > > to "own" a new website that might be created at health.apache.org. It > > > can be any of the interested PMCs and to me the goal is just to make > > > sure that website has a clear owner at the Foundation level. > > > > > > So the simplest is probably for one of those PMCs to request creation > > > of the new website, with the understanding that they will welcome > > > contributions from other PMCs. > > > > > > -Bertrand > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
