Good point about the rebase. I would suggest that as the proposed process since it means we don't lose changes mistakenly committed to site. I would suggest that after the rebase, "git log master..site" to be run to ensure that it produces no output. So the only purpose of the rebase vs "git reset --hard origin/master" is tto catch commits that have snuck directly into the `site` branch.
-- Michael Mior [email protected] 2018-04-25 14:41 GMT-04:00 Julian Hyde <[email protected]>: > I think if you rebase “site” onto “master”, git will spot commits that are > already on “site”. > > $ git checkout site > $ git rebase -i origin master > > All being well, site should end up identical to master after the rebase. > So force-push is not scary. > > Julian > > > > On Apr 25, 2018, at 11:31 AM, Michael Mior <[email protected]> wrote: > > > > Sure, I understand. But no one can do a fast-forward merge to the site > > branch unless they know for sure that nothing in there is going to make > > changes to the site that shouldn't be deployed. And then we're back to > > whoever updates the site needing to already know what should be deployed. > > > > I'm suggesting the following: > > > > 1. During development, cherry pick *only* commits which affect the site > > from `master` to `site` > > 2. At release time, force push the `master` branch to `site`. > > Unfortunately, this means if someone does mistakenly make site changes > > directly to the `site` branch, then these will be lost. I don't see an > easy > > way of preventing this. > > > > -- > > Michael Mior > > [email protected] > > > > 2018-04-25 14:25 GMT-04:00 Julian Hyde <[email protected]>: > > > >> Well, consider the current “master” and “site” branches[1]. They were in > >> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], > which > >> had changes to the site related to product features, so “master” and > “site” > >> had to diverge. > >> > >> It isn’t always possible for “master” and “site” to be on the same path, > >> but for this release, it was until just before CALCITE-2045. > >> > >> Julian > >> > >> [1] https://github.com/apache/calcite/network < > https://github.com/apache/ > >> calcite/network> > >> > >> [2] https://github.com/apache/calcite/commit/ > >> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/ > >> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a> > >> > >> [3] https://github.com/apache/calcite/commit/ > >> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/ > >> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c> > >> > >> > >> > >>> On Apr 25, 2018, at 11:16 AM, Michael Mior <[email protected]> wrote: > >>> > >>> 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." > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
