My personal opinion about (non-fast-forward) merge commits: never do them. If site and master can be on the same line (i.e. if there is no new product-related changes to the site) then they should be.
If they need to diverge, then cherry-pick individual commits from master to site. I added some instructions at the end of https://github.com/apache/calcite/blob/master/site/README.md <https://github.com/apache/calcite/blob/master/site/README.md>. Julian > On Apr 25, 2018, at 11:06 AM, Michael Mior <[email protected]> wrote: > > Sure. Although there (at least) two ways of syncing site with master. One > being to force push master to the site branch and the other to merge the > master branch into site. I do kind of like the idea of the force push just > to avoid having the site branch be eternally filled with a bunch of merge > commits. > > One thing that didn't immediately occur to me is what happens with the > Javadoc? > > -- > Michael Mior > [email protected] > > 2018-04-25 13:30 GMT-04:00 Julian Hyde <[email protected]>: > >> A force-push to the “site” branch each release would not be a terrible >> thing. (Force-pushes are only suspect when they are to the master branch or >> a release branch.) Before the release, the release manager should make sure >> that edits on “site" have made it to “master”. Right after the release, >> they will deploy the site from the “site” branch, which almost certainly >> means syncing “site" with “master”. >> >>> On Apr 25, 2018, at 10:24 AM, Michael Mior <[email protected]> wrote: >>> >>> Sounds reasonable to me. I like that better than the current approach of >>> whoever is updating the site needing to maintain mental state on what is >>> and isn't ready to be posted. We should of course add documentation for >>> this as part of the release process. We also should make clear in the >> site >>> documentation that nothing should be committed to the site branch >> directly, >>> but only what is cherry picked from master. I might even suggest that the >>> sync which happens during release be a force push of the current master >> to >>> the site branch, but I'm not sure I like that idea. >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <[email protected]>: >>> >>>> I am adding Kevin to the committers list, and I am seeing the problem of >>>> mixed changes - recently Michael has edited the site to add two PMC >>>> members, and Shuyi has added documentation for CREATE TYPE. We want the >>>> former to appear on the site, but the latter should wait until the >> release. >>>> >>>> I propose to create a “site” git branch that cherry-picks changes that >> we >>>> wish to have appear on the site immediately. >>>> >>>> On each release, it would be in sync with master, but might start to >>>> differ when we add documentation for features. It would sync up on the >> next >>>> release. >>>> >>>> Any comments/objections? >>>> >>>> Julian >>>> >>>> >>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <[email protected]> wrote: >>>>> >>>>> You are right. Thanks a lot for the explanation, Julian. >>>>> >>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <[email protected]> >> wrote: >>>>> >>>>>> I think it’s misleading to end-users if the web site contains features >>>>>> that have not yet been released. So, we aim to re-generate the web >> site >>>>>> just after a release. (For non product-related stuff, such as >> committers >>>>>> and upcoming talks, we change the web site continuously. The person >>>>>> maintaining the web site has to be a bit careful not to publish the >>>> wrong >>>>>> stuff.) >>>>>> >>>>>> >>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <[email protected]> wrote: >>>>>>> >>>>>>> @Julian, thanks for reviewing the code. I think we need to regenerate >>>> the >>>>>>> website as well so that it contains the latest documentation on type >>>>>>> collection and type DDLs. Let me know how I can help. >>>>>>> >>>>>>> @Valli, with the latest master, you should be able to either use >> CREATE >>>>>>> TYPE statement to define your own type or define your new type in the >>>>>> JSON >>>>>>> schema. >>>>>>> >>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <[email protected]> >>>> wrote: >>>>>>> >>>>>>>> Thanks a lot for your time , Julian. Let me know if you need >> anything. >>>>>>>> >>>>>>>> shuyi >>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <[email protected]> >> wrote: >>>>>>>> >>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) >>>> but >>>>>> I >>>>>>>>> reviewed it yesterday and am currently testing, so it should be >>>>>> committed >>>>>>>>> to master shortly. >>>>>>>>> >>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <[email protected]> >> wrote: >>>>>>>>>> >>>>>>>>>> Currently, user defined type is not supported in Calcite. But it's >>>>>> WIP, >>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. >> With >>>>>>>>> this >>>>>>>>>> PR, you can either use CREATE TYPE statement to define your own >> type >>>>>> or >>>>>>>>>> define your new type in the JSON schema. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Shuyi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai < >>>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'. For >>>>>>>>>>> example, select >>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is >>>> showing, >>>>>>>>>>> Unknown data type name 'TEXT'. >>>>>>>>>>> >>>>>>>>>>> How can I make calcite to parse the above query successfully >> having >>>>>>>>>>> user-defined data type 'text'? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks in advance >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> "So you have to trust that the dots will somehow connect in your >>>>>>>>> future." >>>>>>>>> >>>>>>>>> -- >>>>>>>> "So you have to trust that the dots will somehow connect in your >>>>>> future." >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> "So you have to trust that the dots will somehow connect in your >>>> future." >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> "So you have to trust that the dots will somehow connect in your >> future." >>>> >>>> >> >>
