[RESULT][VOTE] Release Apache Weex (Incubating) 0.26.0-RC2
Hi, community The vote of release Apache Weex (Incubating) 0.26.0-RC2 has passed with three +1 votes binding vote: - Myrle Krantz - Greg Stein - Justin Mclean Vote thread: https://lists.apache.org/thread.html/afde0ced9b4441e59cb582e99187ed56d4cb5c8f2c228e002418af21@%3Cgeneral.incubator.apache.org%3E Thank you to the above IPMC members for taking time to review and provide feedback of this release. Thanks again. Next, I will proceed with the official release of 0.26.0. Best Regards.
Re: New disclaimer text
Hi, I’m also a PPMC member (Apache Flagon). It seems the Incubator is at an inflection point—been tracking how different threads on general@ are capitulating on issues of identity and process. Gian’s points are SPOT on, but so are Justin’s. I have some reconciliatory thoughts and suggestions, which I’m embedding in line: > On Jul 10, 2019, at 5:44 PM, Justin Mclean wrote: > > Hi, > >> Speaking as a member of a currently-incubating project (Apache Druid) where >> we have always strived to do releases with no known licensing issues, the >> text sounds needlessly scary to downstream consumers. > And that may be the problem with a one solution fits all process. It has been > suggested before we let podlings choose which release process they want. > However that may get too complex and make voting on releases inconsistent. +1 on both points. The value we (podlings) take out of the Incubator is mentorship and scaffolding in adopting the Apache Way. In doing so, the “Way”, its processes, and the policies that shape those processes are meant to improve our offerings (code), our adoptability, and grow a sustainable community. Adding an additional disclaimer that we may have known issues adds additional barriers to adoption and community growth. An Incubator by definition takes on risk—infrastructure, time, and opportunity, sunk, and operational costs—to help nurture its participants. That risk is directly yoked to the participants’ value gains from participating. Placing additional barriers to growth and adoption to eliminate the ASF’s risk breaks the incubator model altogether. > >> IMO this disclaims too much, and would chill adoption of incubating >> software by people that care about having clean licensing. PPMCs should be >> able to say "we believe this release is clean and have vetted it using a >> normal Apache vetting process" or maybe even "we have vetted this release >> and it is clean other than the following list of known issues". If they >> can't say one of those two statements, then maybe it's not time to do their >> first release yet. > > The idea is to allow podlings to make releases that may not comply with > policy. Have a hard switch from your releases doesn’t comply to everything > must comply is too difficult for some podlings. +1 on both point and counterpoint. This disclaims too much and there needs to be compliance to policy. The risk the Incubator needs to take is that 100% compliance is an eventual, but measurable goal. Yet, the Incubator needs a means to manage risk. A better model than the disclaimer: progressively incentivize compliance with metrics. Here’s one way for the ASF Incubator: Apache’s key marketing point is the Apache Way. Break down critical processes, determine key performance indicators against those processes, and centrally track metrics (license compliance, community participation, release compliance, notice, keys, whatever, whatever). Then build some Apache-branded badges that expose those metrics publicly so that all your podlings can stick them on their GitHub READMEs, same way as we have for CI, test coverage, etc., etc. Doing something like this, the Incubator is using the brand to incentivize organic compliance and manage risk. Implicit in this usage of the Apache brand is communication that podling projects are not fully endorsed by Apache, but the project being looked after by a trusted organization. Podlings have clear metrics that they can communicate and take actions to move the needle on. Podlings have a way to discriminate themselves from other open-source projects and from other podlings by showing positive values on their badges. This whole model provides a discriminator for all podlings in that other open-source projects don’t have the infrastructure to communicate these metrics; these badges’ existence engenders trust in the ASF & Incubator brand(s) and skepticism about non-Apache projects. Podlings who work to budge metrics can communicate to consumers and potential community members and continually brings them in line with Apache policy—the value they get from the incubator is now directly proportional to compliance (Incubator risk reduction). The Incubator also gets a better way to track incubation status, direct special attention to podlings that are bottoming out (before removal) and podlings that are showing progressive improvement. This method (or similar) tells the public how much trust Apache has in a particular podling. The additional disclaimer communicates that Apache has little trust in its podlings, at large. Maybe this is too much technically (I doubt that), maybe this isn’t the best or only way to do this, but the key theme here is: measurable, progressive improvement. That should be sufficient to stay in the Incubator and necessary to graduate. Importantly, “progressive” means that metrics are updated regularly and not just at the time of release... > >> And yeah, as
Re: Board report submitted / missing report sign-offs
Hi, > Signed off datasketches. Thanks for that. Justin
Re: Board report submitted / missing report sign-offs
Signed off datasketches. Kenn On Wed, Jul 10, 2019 at 3:32 PM Justin Mclean wrote: > Hi, > > I’ve submitted the incubator board report for this month. > > These podling reports are still missing sign off: > - BatchEE > - DataSketches > - DLab > > They will be asked to report next month if they don’t get signed off. To > sign off these reports please do so in whimsey [1] > > I'm a little concerned by DLab as all of it mentors seem to have gone > missing and this will be the third time they miss a report being submitted > / signed-off. > > Thanks, > Justin > > > 1. https://whimsy.apache.org/board/agenda/2019-07-17/Incubator > - > To unsubscribe, e-mail: private-unsubscr...@datasketches.apache.org > For additional commands, e-mail: private-h...@datasketches.apache.org > >
Board report submitted / missing report sign-offs
Hi, I’ve submitted the incubator board report for this month. These podling reports are still missing sign off: - BatchEE - DataSketches - DLab They will be asked to report next month if they don’t get signed off. To sign off these reports please do so in whimsey [1] I'm a little concerned by DLab as all of it mentors seem to have gone missing and this will be the third time they miss a report being submitted / signed-off. Thanks, Justin 1. https://whimsy.apache.org/board/agenda/2019-07-17/Incubator - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New disclaimer text
Hi, > Speaking as a member of a currently-incubating project (Apache Druid) where > we have always strived to do releases with no known licensing issues, the > text sounds needlessly scary to downstream consumers. And that may be the problem with a one solution fits all process. It has been suggested before we let podlings choose which release process they want. However that may get too complex and make voting on releases inconsistent. > IMO this disclaims too much, and would chill adoption of incubating > software by people that care about having clean licensing. PPMCs should be > able to say "we believe this release is clean and have vetted it using a > normal Apache vetting process" or maybe even "we have vetted this release > and it is clean other than the following list of known issues". If they > can't say one of those two statements, then maybe it's not time to do their > first release yet. The idea is to allow podlings to make releases that may not comply with policy. Have a hard switch from your releases doesn’t comply to everything must comply is too difficult for some podlings. > And yeah, as a few others have mentioned, I believe that a more streamlined > voting process That I think is a different issue, ands may be best to start another thread on that. The main issue here is that IPMC members votes are binding, and not all mentors (who are IPMC members) vote on releases, so podlings need votes from the wider IPMC members to make releases (in about 90%+ of cases). There been a few ideas on how to improve this, including one approved method (but no podlings have take that up yet). Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New disclaimer text
Hi, > What is the requirement for this disclaimer text change? > Is this coming from Legal? Or is this Incubator policy? The incubator wold like to make it easies for podlings to make releases, allowing realises with issues in them is a way of doing this. The legal committee has been involved in the discussions and has had input on the text. > Has this been decided on already or is this text suggestion to be used > for a decision? No it not been decided it , this is what this conversation is aoout. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache MXNet (incubating) version 1.5.0.rc2
Hi Justin, Not yet, I have reached out to them. Thanks! Best Regards Lai On Wed, Jul 10, 2019 at 2:55 AM Justin Mclean wrote: > Hi, > > Did you mentors or any other IPMC members vote on this release? > > Thanks, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: New disclaimer text
My thought is that having a scary incubator warning text is the price to be paid for having an incubator release process that could allow releases with problems. The best solution to that is to graduate and get rid of the warning entirely. On Wed, Jul 10, 2019 at 9:50 AM Gian Merlino wrote: > Speaking as a member of a currently-incubating project (Apache Druid) where > we have always strived to do releases with no known licensing issues, the > text sounds needlessly scary to downstream consumers. Especially this part: > > > If you are planning to incorporate this work into your > > product/project, please be aware that you will need to conduct a > > thorough licensing review to determine the overall implications of > > including this work. > > IMO this disclaims too much, and would chill adoption of incubating > software by people that care about having clean licensing. PPMCs should be > able to say "we believe this release is clean and have vetted it using a > normal Apache vetting process" or maybe even "we have vetted this release > and it is clean other than the following list of known issues". If they > can't say one of those two statements, then maybe it's not time to do their > first release yet. > > And yeah, as a few others have mentioned, I believe that a more streamlined > voting process would make PPMCs more likely to adopt an attitude of doing > releases as cleanly as possible. I think mentors could play a valuable part > in streamlining the process, since they have binding votes from both the > PPMC and IPMC perspective, and are in theory plugged in to both > communities. > > On Wed, Jul 10, 2019 at 7:44 AM Jan Piotrowski > wrote: > > > What is the requirement for this disclaimer text change? > > Is this coming from Legal? Or is this Incubator policy? > > Has this been decided on already or is this text suggestion to be used > > for a decision? > > > > J > > > > Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker >: > > > > > > Since this is sort of a post-release set of info, I think it’d make > sense > > > to have either a page specific to each version, or at least a section > per > > > version all on a single page (similar to a security issues page might > be > > or > > > a change log in general). > > > > > > On Tue, Jul 9, 2019 at 21:24, Justin Mclean > > > wrote: > > > > > > > Hi, > > > > > > > > The issue with having a detached disclaimer is that it can change and > > get > > > > out of sync with what was actually in a released version. > > > > > > > > However one possible compromise would be to list known issues in the > > > > disclaimer and list any other issues found by the IPMC in the release > > > > announcements and on the release page next to the download links. The > > > > DISCLAIMER in version control can also be updated and always reflect > > the > > > > current set of released issues are. What do other people think about > > this? > > > > > > > > Thanks, > > > > Justin > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- > > > Matt Sicker > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: New disclaimer text
Speaking as a member of a currently-incubating project (Apache Druid) where we have always strived to do releases with no known licensing issues, the text sounds needlessly scary to downstream consumers. Especially this part: > If you are planning to incorporate this work into your > product/project, please be aware that you will need to conduct a > thorough licensing review to determine the overall implications of > including this work. IMO this disclaims too much, and would chill adoption of incubating software by people that care about having clean licensing. PPMCs should be able to say "we believe this release is clean and have vetted it using a normal Apache vetting process" or maybe even "we have vetted this release and it is clean other than the following list of known issues". If they can't say one of those two statements, then maybe it's not time to do their first release yet. And yeah, as a few others have mentioned, I believe that a more streamlined voting process would make PPMCs more likely to adopt an attitude of doing releases as cleanly as possible. I think mentors could play a valuable part in streamlining the process, since they have binding votes from both the PPMC and IPMC perspective, and are in theory plugged in to both communities. On Wed, Jul 10, 2019 at 7:44 AM Jan Piotrowski wrote: > What is the requirement for this disclaimer text change? > Is this coming from Legal? Or is this Incubator policy? > Has this been decided on already or is this text suggestion to be used > for a decision? > > J > > Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker : > > > > Since this is sort of a post-release set of info, I think it’d make sense > > to have either a page specific to each version, or at least a section per > > version all on a single page (similar to a security issues page might be > or > > a change log in general). > > > > On Tue, Jul 9, 2019 at 21:24, Justin Mclean > > wrote: > > > > > Hi, > > > > > > The issue with having a detached disclaimer is that it can change and > get > > > out of sync with what was actually in a released version. > > > > > > However one possible compromise would be to list known issues in the > > > disclaimer and list any other issues found by the IPMC in the release > > > announcements and on the release page next to the download links. The > > > DISCLAIMER in version control can also be updated and always reflect > the > > > current set of released issues are. What do other people think about > this? > > > > > > Thanks, > > > Justin > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > -- > > Matt Sicker > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: New disclaimer text
What is the requirement for this disclaimer text change? Is this coming from Legal? Or is this Incubator policy? Has this been decided on already or is this text suggestion to be used for a decision? J Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker : > > Since this is sort of a post-release set of info, I think it’d make sense > to have either a page specific to each version, or at least a section per > version all on a single page (similar to a security issues page might be or > a change log in general). > > On Tue, Jul 9, 2019 at 21:24, Justin Mclean > wrote: > > > Hi, > > > > The issue with having a detached disclaimer is that it can change and get > > out of sync with what was actually in a released version. > > > > However one possible compromise would be to list known issues in the > > disclaimer and list any other issues found by the IPMC in the release > > announcements and on the release page next to the download links. The > > DISCLAIMER in version control can also be updated and always reflect the > > current set of released issues are. What do other people think about this? > > > > Thanks, > > Justin > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- > Matt Sicker - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New disclaimer text
Since this is sort of a post-release set of info, I think it’d make sense to have either a page specific to each version, or at least a section per version all on a single page (similar to a security issues page might be or a change log in general). On Tue, Jul 9, 2019 at 21:24, Justin Mclean wrote: > Hi, > > The issue with having a detached disclaimer is that it can change and get > out of sync with what was actually in a released version. > > However one possible compromise would be to list known issues in the > disclaimer and list any other issues found by the IPMC in the release > announcements and on the release page next to the download links. The > DISCLAIMER in version control can also be updated and always reflect the > current set of released issues are. What do other people think about this? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [VOTE] Release Apache MXNet (incubating) version 1.5.0.rc2
Hi, Did you mentors or any other IPMC members vote on this release? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache MXNet (incubating) version 1.5.0.rc2
Dear community, This is a call for a releasing Apache MXNet (incubating) 1.5.0, release candidate 2. Apache MXNet (incubating) community has voted and approved the release. Vote thread: https://lists.apache.org/thread.html/50fe473a3e03c891caccb8cae8e5195bb740a4758f7688790dff70df@%3Cdev.mxnet.apache.org%3E Result thread: https://lists.apache.org/thread.html/641cf0fddce623ff352ba9c7655938c0d16337bae4a8d290956ea130@%3Cdev.mxnet.apache.org%3E The source tarball, including signatures, digests, etc. can be found at: https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.5.0.rc2/ The tag to be voted upon is 1.5.0.rc2: https://github.com/apache/incubator-mxnet/releases/tag/1.5.0.rc2 The release hash is 75a9e18: https://github.com/apache/incubator-mxnet/commit/75a9e187d00a8b7ebc71412a02ed0e3ae489d91f Release artifacts are signed with the following key, KEYS file available: https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS For information about the contents of this release, see: https://cwiki.apache.org/confluence/display/MXNET/1.5.0+Release+Notes The vote will be open for 72 hours. [ ] +1 release this package as ... [ ] +0 no opinion [ ] -1 do not release this package because... Best Regards Lai
Re: [VOTE] Release Apache Daffodil (incubating) 2.4.0-rc1
Hello, On Mon, 8 Jul 2019 at 13:18, Steve Lawrence wrote: > Please review and vote. The vote will be open for at least 72 hours > (Thursday, 11 July 2019, 8am EST). > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > +1 (binding). I checked; name, sig and hashes, notice, license, source headers, compiles from source. Cheers, Dave
