Hi, It would be great if some documentation got added to the code you want to merge. To me, it would be enough to just quickly characterize on the class level what is the class for and what are the expectations. This is especially important for Accord API classes because now it is hard to review whether the implementation in Cassandra conforms the API requirements.
Given it is going to be a possibility for others to try Accord before the release, it would be good to create some CQL syntax documentation, something like a chapter in https://cassandra.apache.org/doc/latest/cassandra/cql/index.html but for unreleased Cassandra version or a blog post, so that the syntax is known to the users and they can quickly get into speed, hopefully reporting any problems soon. - - -- --- ----- -------- ------------- Jacek Lewandowski On Mon, 16 Jan 2023 at 17:52, Benedict <bened...@apache.org> wrote: > That’s fair, though for long term contributors probably the risk is > relatively low on that front. I guess that’s something we can perhaps raise > as part of each CEP if we envisage it taking several months of development? > > > Did we document this or is it in an email thread somewhere? > > It’s probably buried in one of the many threads we’ve had about related > topics on releases and development. We’ve definitely discussed feature > branches before, and I recall discussing a goal of merging ~quarterly. But > perhaps like most sub topics it didn’t get enough visibility, in which case > this thread I suppose can serve as a dedicated rehash and we can formalise > whatever falls out. > > In theory as Jeremiah says there’s only the normal merge criteria. But > that includes nobody saying no to a piece of work or raising concerns, and > advertising the opportunity to say no is important for that IMO. > > On 16 Jan 2023, at 16:36, J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > > > My only concern to merging (given all normal requirements are met) would > be if there was a possibility that the feature would never be finished. > Given all of the excitement and activity around accord, I do not think that > is a concern here. So I see no reason not to merge incremental progress > behind a feature flag. > > -Jeremiah > > On Jan 16, 2023, at 10:30 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > > Did we document this or is it in an email thread somewhere? > > I don't see it on the confluence wiki nor does a cursory search of > ponymail turn it up. > > What was it for something flagged experimental? > 1. Same tests pass on the branch as to the root it's merging back to > 2. 2 committers eyes on (author + reviewer or 2 reviewers, etc) > 3. Disabled by default w/flag to enable > > So really only the 3rd thing is different right? Probably ought to add an > informal step 4 which Benedict is doing here which is "hit the dev ML w/a > DISCUSS thread about the upcoming merge so it's on people's radar and they > can coordinate". > > On Mon, Jan 16, 2023, at 11:08 AM, Benedict wrote: > > My goal isn’t to ask if others believe we have the right to merge, only to > invite feedback if there are any specific concerns. Large pieces of work > like this cause headaches and concerns for other contributors, and so it’s > only polite to provide notice of our intention, since probably many haven’t > even noticed the feature branch developing. > > The relevant standard for merging a feature branch, if we want to rehash > that, is that it is feature- and bug-neutral by default, ie that a release > could be cut afterwards while maintaining our usual quality standards, and > that the feature is disabled by default, yes. It is not however > feature-complete or production read as a feature; that would prevent any > incremental merging of feature development. > > > On 16 Jan 2023, at 15:57, J. D. Jordan <jeremiah.jor...@gmail.com> > wrote: > > > > I haven’t been following the progress of the feature branch, but I > would think the requirements for merging it into master would be the same > as any other merge. > > > > A subset of those requirements being: > > Is the code to be merged in releasable quality? Is it disabled by a > feature flag by default if not? > > Do all the tests pass? > > Has there been review and +1 by two committer? > > > > If the code in the feature branch meets all of the merging criteria of > the project then I see no reason to keep it in a feature branch for ever. > > > > -Jeremiah > > > > > >> On Jan 16, 2023, at 3:21 AM, Benedict <bened...@apache.org> wrote: > >> > >> Hi Everyone, I hope you all had a lovely holiday period. > >> > >> Those who have been following along will have seen a steady drip of > progress into the cep-15-accord feature branch over the past year. We > originally discussed that feature branches would merge periodically into > trunk, and we are long overdue. With the release of 4.1, it’s time to > rectify that. > >> > >> Barring complaints, I hope to merge the current state to trunk within a > couple of weeks. This remains a work in progress, but will permit users to > experiment with the alpha version of Accord and provide feedback, as well > as phase the changes to trunk. > > > >
