I don't see how the sync with the master branch could be a fast-forward merge. This isn't possible if commits just affecting the site have been cherry picked since the last sync.
-- Michael Mior [email protected] 2018-04-25 14:13 GMT-04:00 Julian Hyde <[email protected]>: > 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." > >>>> > >>>> > >> > >> > >
