Re: Merging CEP-15 to trunk

[Benedict]

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.