> > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. >
Yes this is my read as well. If we want to announce anything at summit and have a wider audience getting involved in using it, then we need to make a “formal” preview release available, aka one that has been voted on and approved by the PMC. There is nothing stopping us from building and voting on a release that comes from a feature branch, it just needs to go through the normal artifact build and verification that any release goes through. So as Mick asked earlier in the thread: > > Is anyone up for looking into adding a "preview" qualifier to our release > process? > > > I'm in favor of this. If we cut preview snapshots from trunk and all > feature branches periodically (nightly? weekly?), preferably as docker > images, this satisfies the desire to get these features into the hands of > the dev and user community to test them out and provide feedback to the dev > process while also allowing us to keep a high bar for merge to trunk. > > I am also in favor of this, and if we can make it work there is nothing stopping us from having someone use the capability to make a preview release that can go to a formal vote. My view is that we wait and see what the CI looks like at that time. > I also agree we should see what CI looks like at the time and make the “go”/"no go" on merge decision based on the state then. But I think we need to have a plan for what happens if we end up with “no go”. We don’t want to be scrambling at the last minute in that case. Again “no go” is not my preferred outcome, but I want to make sure we have plans in place should it occur. -Jeremiah On Nov 2, 2023 at 9:16:54 AM, Benedict <bened...@apache.org> wrote: > My view is that we wait and see what the CI looks like at that time. > > > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. > > > > > On 2 Nov 2023, at 13:27, Josh McKenzie <jmcken...@apache.org> wrote: > > > > I’m not sure we need any additional mechanisms beyond DISCUSS threads, > polls and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if > you want to knowingly go against it, or want to modify or clarify what’s > meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve > to broadcast some formulation of the norm. > > 100% agree on all counts. Hopefully this discussion is useful for other > folks as well. > > So - with the clarification that our agreement on green CI represents a > polled majority consensus of the folks participating on the discussion at > the time but not some kind of hard unbendable obligation, is this something > we want to consider relaxing for TCM and Accord? > > This thread ran long (and got detoured - mea culpa) - the tradeoffs seem > like: > > 1. We merge them without green CI and cut a cassandra-5.1 branch so we > can release an alpha-1 snapshot from that branch. This likely leaves > cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord > devs can be expected to be pulled into fixing core issues / finalizing the > features and the burden for test stabilization "leaking out" across others > in the community who don't have context on their breakage (see: > CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for > cassandra-5.0 QA stabilization). > 2. Push for green CI on Accord / TCM before merge and alpha > availability, almost certainly delaying their availability to the > community. > 3. Cut a preview / snapshot release from the accord feature branch, > made available to the dev community. We could automate creation / update of > docker images with snapshot releases of all HEAD for trunk and feature > branches. > 4. Some other approach I'm not thinking of / missed > > So as Mick asked earlier in the thread: > > Is anyone up for looking into adding a "preview" qualifier to our release > process? > > > I'm in favor of this. If we cut preview snapshots from trunk and all > feature branches periodically (nightly? weekly?), preferably as docker > images, this satisfies the desire to get these features into the hands of > the dev and user community to test them out and provide feedback to the dev > process while also allowing us to keep a high bar for merge to trunk. > > Referencing the ASF Release Policy: > https://www.apache.org/legal/release-policy.html#release-definition, this > is consistent with the guidance: > > During the process of developing software and preparing a release, various > packages are made available to the development community for testing > purposes. Projects MUST direct outsiders towards official releases rather > than raw source repositories, nightly builds, snapshots, release > candidates, or any other similar packages. Projects SHOULD make available > developer resources to support individuals actively participating in > development or following the dev list and thus aware of the conditions > placed on unreleased materials. > > We direct people to the official downloads on the website and add a > section below that references the latest snapshot releases for CEP-approved > feature branch work in progress + trunk. > > Generically, a release is anything that is published beyond the group that > owns it. For an Apache project, that means any publication outside the > development community, defined as individuals actively participating in > development or following the dev list. > > I think so long as we're clear about them being preview / snapshot > releases of in-development work where we're looking for feedback on the dev > process, as well as clearly directing people to the dev ML and > #cassandra-dev on slack, this would be a pretty big win for the project. > > So - that's my bid. What do others think? > > >
