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.
