Hi - > On Oct 5, 2020, at 1:10 PM, Nikita Ivanov <[email protected]> wrote: > > Dave, > So, if the project wants to do a nightly builds it cannot even mention > their existence on the project's website? How would developers even know > they exist to ask about them in the first place? I'm not arguing here - but > merely asking about the right approach here. What if website has a clear > disclaimer that these artifacts are only for the project's dev community > and not official ASF releases? > > GridGain/DataBricks/Confluent/DataStax went another way of doing their 100% > own builds off of the Apache counterparts (which I don't think this project > is ready for).
These commercial entities must follow branding requirements. The relevant PMC Members as individuals must enforce branding with their employers. Project community members earn merit in the project based on their work in the community and not on their work for their employer. If they leave their job they remain members of the project community. Apache PMCs must beware of taking advantage of a vendor’s offer. Here is an example involving Confluent and Kafka. Confluent hosts their own set of community extensions to Kafka. A couple of years ago they relicensed their contributions to an “Open Core” license going away from OpenSource. A project should be getting developers involved in project development on the dev mailing list. Having developers ask for the CI build on the list is a good thing. This assure that their contributions can be made more easily on the list rather than captured by a vendor. By listing the vendors and not the projects you show how insidious this capture really is. This may be an argument for changing the Apache Policy about “advertising CI builds”. Regards, Dave > > Thanks, > -- > Nikita Ivanov > > > > On Mon, Oct 5, 2020 at 12:50 PM Dave Fisher <[email protected]> wrote: > >> Hi - >> >>> On Oct 4, 2020, at 5:52 PM, Nikita Ivanov <[email protected]> wrote: >>> >>> NLPCraft-ers, >>> I've looked at the velocity of the development on the project and the >>> frequency of the releases and it appears to me that they don't sync up >> very >>> well. The project is still very young and the pace of >>> changes/fixes/improvements greatly outpaces the pace of official ASF >>> releases. However, it's unclear if master branch (or other branch) >>> is stable and can be used for play-around... >>> >>> As with many other ASF projects I propose to consider doing >> ASF-unofficial >>> nightly or (less frequent) community builds and make them available on >> the >>> website. >> >> The project can make snapshots from CI available, but not from the website. >> >> http://www.apache.org/legal/release-policy.html#publication >> http://www.apache.org/legal/release-policy.html#host-rc >> >> The location may be given to community members on the mailing list when >> they ask. >> >>> This will allow many users to simply try some of the experimental >>> features or provide quick fixes/feedback when necessary without a need >> for >>> the NLPCraft team to cut an official ASF release and go through the >> process >>> every time for every small fix or feature iteration. We will, obviously, >>> continue to release official ASF releases once we accumulate enough >> "meat" >>> for such a release. >>> >>> At Apache Ignite we've decided to do Community Edition (built and hosted >> by >>> GridGain Systems) for pretty much exactly these reasons. >> >> These can be problematic. >> >> https://infra.apache.org/release-distribution.html#unreleased >> >> Community Editions that are called Apache NLPCraft (incubating) must be >> based on Released Source Code. >> >> GridGain community edition is not Apache Ignite, it’s not the same. I’m >> unclear what is going on here, but that is an issue for the Ignite PMC. >> https://www.gridgain.com/products/software/community-edition >> >>> >>> Thoughts, comments? >> >> Regards, >> Dave >> >> >>> -- >>> Nikita Ivanov >> >>
