You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Ruben Q L <ru...@gmail.com> on 2020/10/06 20:08:29 UTC

[HELP] Publishing site after release 1.26.0

Hi all,

I have to publish the site after the release 1.26.0, it is the first time
that I do such a thing, and I don't want to mess things up (especially
since I am not a git expert).

I do not understand the current situation between 'master' and 'site'
branches. It looks like they have diverged: 'site' branch is currently "2
commits ahead, 99 commits behind master" [1], is this normal or expected?
The ahead commits seem to be:
-
https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
-
https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84

The second one is an interesting case, it seems that the exact same change
was also committed to master (as a different commit):
-
https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
I guess this was a cherry-pick? Is this normal? In that case, why the other
one was not applied to master?

My question is, how should I proceed? Shall I merge master into site? site
into master? both? I have tried both locally, and they cannot be
fast-forwarded (merge --ff-only).

Then, which branch should I use to re-build the site and re-generate the
javadoc before pushing it into the calcite-site repo? Master? Site? Either
of them once they are aligned?

Thanks,
Ruben

[1] https://github.com/apache/calcite/tree/site

Re: [HELP] Publishing site after release 1.26.0

Posted by Stamatis Zampetakis <za...@gmail.com>.
Hi Ruben,

After the release the master and site branch should be aligned so I think
it is safe to force push master onto site.
It is not the first time that this happens and if I remember well we did
the same thing.

Normally, we always build and deploy from the site branch. More details
about the workflow can be found in [1].

Best,
Stamatis

[1]
https://lists.apache.org/thread.html/0d9829f7e32f51bc03fc350fe7c782c03dedb2ecca90e983917abf53%40%3Cdev.calcite.apache.org%3E

On Tue, Oct 6, 2020 at 10:10 PM Ruben Q L <ru...@gmail.com> wrote:

> Hi all,
>
> I have to publish the site after the release 1.26.0, it is the first time
> that I do such a thing, and I don't want to mess things up (especially
> since I am not a git expert).
>
> I do not understand the current situation between 'master' and 'site'
> branches. It looks like they have diverged: 'site' branch is currently "2
> commits ahead, 99 commits behind master" [1], is this normal or expected?
> The ahead commits seem to be:
> -
>
> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
> -
>
> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
>
> The second one is an interesting case, it seems that the exact same change
> was also committed to master (as a different commit):
> -
>
> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
> I guess this was a cherry-pick? Is this normal? In that case, why the other
> one was not applied to master?
>
> My question is, how should I proceed? Shall I merge master into site? site
> into master? both? I have tried both locally, and they cannot be
> fast-forwarded (merge --ff-only).
>
> Then, which branch should I use to re-build the site and re-generate the
> javadoc before pushing it into the calcite-site repo? Master? Site? Either
> of them once they are aligned?
>
> Thanks,
> Ruben
>
> [1] https://github.com/apache/calcite/tree/site
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Thank you very much Stamatis!

Best,
Ruben


On Wed, Oct 7, 2020 at 8:15 PM Stamatis Zampetakis <za...@gmail.com>
wrote:

> I pushed the javadoc, it should be fine now.
>
> Thanks for pushing this release forward Ruben!
>
> Best,
> Stamatis
>
> On Wed, Oct 7, 2020 at 8:58 PM Stamatis Zampetakis <za...@gmail.com>
> wrote:
>
> > I am building the javadoc right now, if everything goes well I will
> commit
> > the changes to the site repo.
> >
> > Best,
> > Stamatis
> >
> > On Wed, Oct 7, 2020 at 6:18 PM Ruben Q L <ru...@gmail.com> wrote:
> >
> >> Hi again,
> >>
> >> I am sorry, but I am unable to generate the javadoc on my local
> workspace.
> >> I have tried several times, it runs for around 1 hour and it finally
> >> fails:
> >>
> >> $ docker-compose run generate-javadoc
> >>
> >> ...
> >>
> >>
> >> *> Task :javadocAggregate* FAILED
> >>
> >>
> >> FAILURE: Build failed with an exception.
> >>
> >>
> >> * What went wrong:
> >>
> >> Execution failed for task ':javadocAggregate'.
> >>
> >> > Javadoc generation failed. Generated Javadoc options file (useful for
> >> troubleshooting):
> >> '/usr/src/calcite/build/tmp/javadocAggregate/javadoc.options'
> >>
> >>
> >> * Try:
> >>
> >> Run with *--stacktrace* option to get the stack trace. Run with *--info*
> >> or
> >> *--debug* option to get more log output. Run with *--scan* to get full
> >> insights.
> >>
> >>
> >> * Get more help at *https://help.gradle.org <https://help.gradle.org>*
> >>
> >>
> >> Deprecated Gradle features were used in this build, making it
> incompatible
> >> with Gradle 7.0.
> >>
> >> Use '--warning-mode all' to show the individual deprecation warnings.
> >>
> >> See
> >>
> >>
> https://docs.gradle.org/6.6/userguide/command_line_interface.html#sec:command_line_warnings
> >>
> >>
> >> *BUILD FAILED* in 54m 5s
> >>
> >> I can see in the site/target subfolder many files that have been
> created /
> >> modified. But I am afraid of committing and pushing these changes, since
> >> the command fails. I will continue investigating.
> >> In the meantime, to avoid having the javadoc out of date much longer on
> >> our
> >> web, could someone please fetch the 'site' branch (fyi I had to force
> push
> >> on it to leave it in the appropriate status), generate the javadoc and
> >> publish it?
> >>
> >> Thanks,
> >> Ruben
> >>
> >>
> >> On Wed, Oct 7, 2020 at 2:53 PM Ruben Q L <ru...@gmail.com> wrote:
> >>
> >> > Sorry, my bad, I was using my "normal" github password, instead of a
> >> > Personal Access Token.
> >> > I have just pushed the web site.
> >> >
> >> > Working on the javadoc....
> >> >
> >> >
> >> > On Wed, Oct 7, 2020 at 12:40 PM Ruben Q L <ru...@gmail.com> wrote:
> >> >
> >> >>
> >> >> It seems I cannot push into calcite-site repo (
> >> >> https://github.com/apache/calcite-site.git/)
> >> >> Am I missing something?
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:
> >> >>
> >> >>> Stamatis, Francis, thank you very much for the feedback.
> >> >>> I will work on that.
> >> >>>
> >> >>> Ruben
> >> >>>
> >> >>>
> >> >>> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <
> >> francischuang@apache.org>
> >> >>> wrote:
> >> >>>
> >> >>>> Hi Ruben,
> >> >>>>
> >> >>>> Thanks for getting the released rolled out.
> >> >>>>
> >> >>>> In general, when making changes to the website:
> >> >>>> - Master is the source of truth.
> >> >>>> - Commit to Master first.
> >> >>>> - Cherry pick into Site.
> >> >>>> - Build Site and publish.
> >> >>>>
> >> >>>> If a commit is on site, but not on master, then the person making
> the
> >> >>>> change made a small mistake and you should make sure the commit is
> >> >>>> cherry-picked into master.
> >> >>>>
> >> >>>> After a release, we need to make Site equal Master since Master is
> >> the
> >> >>>> source of truth.
> >> >>>>
> >> >>>> I believe you run "git reset --hard master" on Site to force it to
> >> >>>> equal
> >> >>>> master. Note that this completely overwrites site with all the
> >> commits
> >> >>>> from Master and drops commits that were in Site but not in Master.
> >> >>>> Therefore it is important to make sure any commits that were on
> Site
> >> >>>> but
> >> >>>> not on Master are "fixed" by making sure they are on Master first.
> >> >>>>
> >> >>>> Once that's done, just publish the site following the instructions
> in
> >> >>>> site/README.md
> >> >>>>
> >> >>>> Hope that helps!
> >> >>>>
> >> >>>> Francis
> >> >>>>
> >> >>>> On 7/10/2020 7:08 am, Ruben Q L wrote:
> >> >>>> > Hi all,
> >> >>>> >
> >> >>>> > I have to publish the site after the release 1.26.0, it is the
> >> first
> >> >>>> time
> >> >>>> > that I do such a thing, and I don't want to mess things up
> >> (especially
> >> >>>> > since I am not a git expert).
> >> >>>> >
> >> >>>> > I do not understand the current situation between 'master' and
> >> 'site'
> >> >>>> > branches. It looks like they have diverged: 'site' branch is
> >> >>>> currently "2
> >> >>>> > commits ahead, 99 commits behind master" [1], is this normal or
> >> >>>> expected?
> >> >>>> > The ahead commits seem to be:
> >> >>>> > -
> >> >>>> >
> >> >>>>
> >>
> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
> >> >>>> > -
> >> >>>> >
> >> >>>>
> >>
> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
> >> >>>> >
> >> >>>> > The second one is an interesting case, it seems that the exact
> same
> >> >>>> change
> >> >>>> > was also committed to master (as a different commit):
> >> >>>> > -
> >> >>>> >
> >> >>>>
> >>
> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
> >> >>>> > I guess this was a cherry-pick? Is this normal? In that case, why
> >> the
> >> >>>> other
> >> >>>> > one was not applied to master?
> >> >>>> >
> >> >>>> > My question is, how should I proceed? Shall I merge master into
> >> site?
> >> >>>> site
> >> >>>> > into master? both? I have tried both locally, and they cannot be
> >> >>>> > fast-forwarded (merge --ff-only).
> >> >>>> >
> >> >>>> > Then, which branch should I use to re-build the site and
> >> re-generate
> >> >>>> the
> >> >>>> > javadoc before pushing it into the calcite-site repo? Master?
> Site?
> >> >>>> Either
> >> >>>> > of them once they are aligned?
> >> >>>> >
> >> >>>> > Thanks,
> >> >>>> > Ruben
> >> >>>> >
> >> >>>> > [1] https://github.com/apache/calcite/tree/site
> >> >>>> >
> >> >>>>
> >> >>>
> >>
> >
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Stamatis Zampetakis <za...@gmail.com>.
I pushed the javadoc, it should be fine now.

Thanks for pushing this release forward Ruben!

Best,
Stamatis

On Wed, Oct 7, 2020 at 8:58 PM Stamatis Zampetakis <za...@gmail.com>
wrote:

> I am building the javadoc right now, if everything goes well I will commit
> the changes to the site repo.
>
> Best,
> Stamatis
>
> On Wed, Oct 7, 2020 at 6:18 PM Ruben Q L <ru...@gmail.com> wrote:
>
>> Hi again,
>>
>> I am sorry, but I am unable to generate the javadoc on my local workspace.
>> I have tried several times, it runs for around 1 hour and it finally
>> fails:
>>
>> $ docker-compose run generate-javadoc
>>
>> ...
>>
>>
>> *> Task :javadocAggregate* FAILED
>>
>>
>> FAILURE: Build failed with an exception.
>>
>>
>> * What went wrong:
>>
>> Execution failed for task ':javadocAggregate'.
>>
>> > Javadoc generation failed. Generated Javadoc options file (useful for
>> troubleshooting):
>> '/usr/src/calcite/build/tmp/javadocAggregate/javadoc.options'
>>
>>
>> * Try:
>>
>> Run with *--stacktrace* option to get the stack trace. Run with *--info*
>> or
>> *--debug* option to get more log output. Run with *--scan* to get full
>> insights.
>>
>>
>> * Get more help at *https://help.gradle.org <https://help.gradle.org>*
>>
>>
>> Deprecated Gradle features were used in this build, making it incompatible
>> with Gradle 7.0.
>>
>> Use '--warning-mode all' to show the individual deprecation warnings.
>>
>> See
>>
>> https://docs.gradle.org/6.6/userguide/command_line_interface.html#sec:command_line_warnings
>>
>>
>> *BUILD FAILED* in 54m 5s
>>
>> I can see in the site/target subfolder many files that have been created /
>> modified. But I am afraid of committing and pushing these changes, since
>> the command fails. I will continue investigating.
>> In the meantime, to avoid having the javadoc out of date much longer on
>> our
>> web, could someone please fetch the 'site' branch (fyi I had to force push
>> on it to leave it in the appropriate status), generate the javadoc and
>> publish it?
>>
>> Thanks,
>> Ruben
>>
>>
>> On Wed, Oct 7, 2020 at 2:53 PM Ruben Q L <ru...@gmail.com> wrote:
>>
>> > Sorry, my bad, I was using my "normal" github password, instead of a
>> > Personal Access Token.
>> > I have just pushed the web site.
>> >
>> > Working on the javadoc....
>> >
>> >
>> > On Wed, Oct 7, 2020 at 12:40 PM Ruben Q L <ru...@gmail.com> wrote:
>> >
>> >>
>> >> It seems I cannot push into calcite-site repo (
>> >> https://github.com/apache/calcite-site.git/)
>> >> Am I missing something?
>> >>
>> >>
>> >>
>> >> On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:
>> >>
>> >>> Stamatis, Francis, thank you very much for the feedback.
>> >>> I will work on that.
>> >>>
>> >>> Ruben
>> >>>
>> >>>
>> >>> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <
>> francischuang@apache.org>
>> >>> wrote:
>> >>>
>> >>>> Hi Ruben,
>> >>>>
>> >>>> Thanks for getting the released rolled out.
>> >>>>
>> >>>> In general, when making changes to the website:
>> >>>> - Master is the source of truth.
>> >>>> - Commit to Master first.
>> >>>> - Cherry pick into Site.
>> >>>> - Build Site and publish.
>> >>>>
>> >>>> If a commit is on site, but not on master, then the person making the
>> >>>> change made a small mistake and you should make sure the commit is
>> >>>> cherry-picked into master.
>> >>>>
>> >>>> After a release, we need to make Site equal Master since Master is
>> the
>> >>>> source of truth.
>> >>>>
>> >>>> I believe you run "git reset --hard master" on Site to force it to
>> >>>> equal
>> >>>> master. Note that this completely overwrites site with all the
>> commits
>> >>>> from Master and drops commits that were in Site but not in Master.
>> >>>> Therefore it is important to make sure any commits that were on Site
>> >>>> but
>> >>>> not on Master are "fixed" by making sure they are on Master first.
>> >>>>
>> >>>> Once that's done, just publish the site following the instructions in
>> >>>> site/README.md
>> >>>>
>> >>>> Hope that helps!
>> >>>>
>> >>>> Francis
>> >>>>
>> >>>> On 7/10/2020 7:08 am, Ruben Q L wrote:
>> >>>> > Hi all,
>> >>>> >
>> >>>> > I have to publish the site after the release 1.26.0, it is the
>> first
>> >>>> time
>> >>>> > that I do such a thing, and I don't want to mess things up
>> (especially
>> >>>> > since I am not a git expert).
>> >>>> >
>> >>>> > I do not understand the current situation between 'master' and
>> 'site'
>> >>>> > branches. It looks like they have diverged: 'site' branch is
>> >>>> currently "2
>> >>>> > commits ahead, 99 commits behind master" [1], is this normal or
>> >>>> expected?
>> >>>> > The ahead commits seem to be:
>> >>>> > -
>> >>>> >
>> >>>>
>> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
>> >>>> > -
>> >>>> >
>> >>>>
>> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
>> >>>> >
>> >>>> > The second one is an interesting case, it seems that the exact same
>> >>>> change
>> >>>> > was also committed to master (as a different commit):
>> >>>> > -
>> >>>> >
>> >>>>
>> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
>> >>>> > I guess this was a cherry-pick? Is this normal? In that case, why
>> the
>> >>>> other
>> >>>> > one was not applied to master?
>> >>>> >
>> >>>> > My question is, how should I proceed? Shall I merge master into
>> site?
>> >>>> site
>> >>>> > into master? both? I have tried both locally, and they cannot be
>> >>>> > fast-forwarded (merge --ff-only).
>> >>>> >
>> >>>> > Then, which branch should I use to re-build the site and
>> re-generate
>> >>>> the
>> >>>> > javadoc before pushing it into the calcite-site repo? Master? Site?
>> >>>> Either
>> >>>> > of them once they are aligned?
>> >>>> >
>> >>>> > Thanks,
>> >>>> > Ruben
>> >>>> >
>> >>>> > [1] https://github.com/apache/calcite/tree/site
>> >>>> >
>> >>>>
>> >>>
>>
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Stamatis Zampetakis <za...@gmail.com>.
I am building the javadoc right now, if everything goes well I will commit
the changes to the site repo.

Best,
Stamatis

On Wed, Oct 7, 2020 at 6:18 PM Ruben Q L <ru...@gmail.com> wrote:

> Hi again,
>
> I am sorry, but I am unable to generate the javadoc on my local workspace.
> I have tried several times, it runs for around 1 hour and it finally fails:
>
> $ docker-compose run generate-javadoc
>
> ...
>
>
> *> Task :javadocAggregate* FAILED
>
>
> FAILURE: Build failed with an exception.
>
>
> * What went wrong:
>
> Execution failed for task ':javadocAggregate'.
>
> > Javadoc generation failed. Generated Javadoc options file (useful for
> troubleshooting):
> '/usr/src/calcite/build/tmp/javadocAggregate/javadoc.options'
>
>
> * Try:
>
> Run with *--stacktrace* option to get the stack trace. Run with *--info* or
> *--debug* option to get more log output. Run with *--scan* to get full
> insights.
>
>
> * Get more help at *https://help.gradle.org <https://help.gradle.org>*
>
>
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 7.0.
>
> Use '--warning-mode all' to show the individual deprecation warnings.
>
> See
>
> https://docs.gradle.org/6.6/userguide/command_line_interface.html#sec:command_line_warnings
>
>
> *BUILD FAILED* in 54m 5s
>
> I can see in the site/target subfolder many files that have been created /
> modified. But I am afraid of committing and pushing these changes, since
> the command fails. I will continue investigating.
> In the meantime, to avoid having the javadoc out of date much longer on our
> web, could someone please fetch the 'site' branch (fyi I had to force push
> on it to leave it in the appropriate status), generate the javadoc and
> publish it?
>
> Thanks,
> Ruben
>
>
> On Wed, Oct 7, 2020 at 2:53 PM Ruben Q L <ru...@gmail.com> wrote:
>
> > Sorry, my bad, I was using my "normal" github password, instead of a
> > Personal Access Token.
> > I have just pushed the web site.
> >
> > Working on the javadoc....
> >
> >
> > On Wed, Oct 7, 2020 at 12:40 PM Ruben Q L <ru...@gmail.com> wrote:
> >
> >>
> >> It seems I cannot push into calcite-site repo (
> >> https://github.com/apache/calcite-site.git/)
> >> Am I missing something?
> >>
> >>
> >>
> >> On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:
> >>
> >>> Stamatis, Francis, thank you very much for the feedback.
> >>> I will work on that.
> >>>
> >>> Ruben
> >>>
> >>>
> >>> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <
> francischuang@apache.org>
> >>> wrote:
> >>>
> >>>> Hi Ruben,
> >>>>
> >>>> Thanks for getting the released rolled out.
> >>>>
> >>>> In general, when making changes to the website:
> >>>> - Master is the source of truth.
> >>>> - Commit to Master first.
> >>>> - Cherry pick into Site.
> >>>> - Build Site and publish.
> >>>>
> >>>> If a commit is on site, but not on master, then the person making the
> >>>> change made a small mistake and you should make sure the commit is
> >>>> cherry-picked into master.
> >>>>
> >>>> After a release, we need to make Site equal Master since Master is the
> >>>> source of truth.
> >>>>
> >>>> I believe you run "git reset --hard master" on Site to force it to
> >>>> equal
> >>>> master. Note that this completely overwrites site with all the commits
> >>>> from Master and drops commits that were in Site but not in Master.
> >>>> Therefore it is important to make sure any commits that were on Site
> >>>> but
> >>>> not on Master are "fixed" by making sure they are on Master first.
> >>>>
> >>>> Once that's done, just publish the site following the instructions in
> >>>> site/README.md
> >>>>
> >>>> Hope that helps!
> >>>>
> >>>> Francis
> >>>>
> >>>> On 7/10/2020 7:08 am, Ruben Q L wrote:
> >>>> > Hi all,
> >>>> >
> >>>> > I have to publish the site after the release 1.26.0, it is the first
> >>>> time
> >>>> > that I do such a thing, and I don't want to mess things up
> (especially
> >>>> > since I am not a git expert).
> >>>> >
> >>>> > I do not understand the current situation between 'master' and
> 'site'
> >>>> > branches. It looks like they have diverged: 'site' branch is
> >>>> currently "2
> >>>> > commits ahead, 99 commits behind master" [1], is this normal or
> >>>> expected?
> >>>> > The ahead commits seem to be:
> >>>> > -
> >>>> >
> >>>>
> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
> >>>> > -
> >>>> >
> >>>>
> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
> >>>> >
> >>>> > The second one is an interesting case, it seems that the exact same
> >>>> change
> >>>> > was also committed to master (as a different commit):
> >>>> > -
> >>>> >
> >>>>
> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
> >>>> > I guess this was a cherry-pick? Is this normal? In that case, why
> the
> >>>> other
> >>>> > one was not applied to master?
> >>>> >
> >>>> > My question is, how should I proceed? Shall I merge master into
> site?
> >>>> site
> >>>> > into master? both? I have tried both locally, and they cannot be
> >>>> > fast-forwarded (merge --ff-only).
> >>>> >
> >>>> > Then, which branch should I use to re-build the site and re-generate
> >>>> the
> >>>> > javadoc before pushing it into the calcite-site repo? Master? Site?
> >>>> Either
> >>>> > of them once they are aligned?
> >>>> >
> >>>> > Thanks,
> >>>> > Ruben
> >>>> >
> >>>> > [1] https://github.com/apache/calcite/tree/site
> >>>> >
> >>>>
> >>>
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Hi again,

I am sorry, but I am unable to generate the javadoc on my local workspace.
I have tried several times, it runs for around 1 hour and it finally fails:

$ docker-compose run generate-javadoc

...


*> Task :javadocAggregate* FAILED


FAILURE: Build failed with an exception.


* What went wrong:

Execution failed for task ':javadocAggregate'.

> Javadoc generation failed. Generated Javadoc options file (useful for
troubleshooting):
'/usr/src/calcite/build/tmp/javadocAggregate/javadoc.options'


* Try:

Run with *--stacktrace* option to get the stack trace. Run with *--info* or
*--debug* option to get more log output. Run with *--scan* to get full
insights.


* Get more help at *https://help.gradle.org <https://help.gradle.org>*


Deprecated Gradle features were used in this build, making it incompatible
with Gradle 7.0.

Use '--warning-mode all' to show the individual deprecation warnings.

See
https://docs.gradle.org/6.6/userguide/command_line_interface.html#sec:command_line_warnings


*BUILD FAILED* in 54m 5s

I can see in the site/target subfolder many files that have been created /
modified. But I am afraid of committing and pushing these changes, since
the command fails. I will continue investigating.
In the meantime, to avoid having the javadoc out of date much longer on our
web, could someone please fetch the 'site' branch (fyi I had to force push
on it to leave it in the appropriate status), generate the javadoc and
publish it?

Thanks,
Ruben


On Wed, Oct 7, 2020 at 2:53 PM Ruben Q L <ru...@gmail.com> wrote:

> Sorry, my bad, I was using my "normal" github password, instead of a
> Personal Access Token.
> I have just pushed the web site.
>
> Working on the javadoc....
>
>
> On Wed, Oct 7, 2020 at 12:40 PM Ruben Q L <ru...@gmail.com> wrote:
>
>>
>> It seems I cannot push into calcite-site repo (
>> https://github.com/apache/calcite-site.git/)
>> Am I missing something?
>>
>>
>>
>> On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:
>>
>>> Stamatis, Francis, thank you very much for the feedback.
>>> I will work on that.
>>>
>>> Ruben
>>>
>>>
>>> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <fr...@apache.org>
>>> wrote:
>>>
>>>> Hi Ruben,
>>>>
>>>> Thanks for getting the released rolled out.
>>>>
>>>> In general, when making changes to the website:
>>>> - Master is the source of truth.
>>>> - Commit to Master first.
>>>> - Cherry pick into Site.
>>>> - Build Site and publish.
>>>>
>>>> If a commit is on site, but not on master, then the person making the
>>>> change made a small mistake and you should make sure the commit is
>>>> cherry-picked into master.
>>>>
>>>> After a release, we need to make Site equal Master since Master is the
>>>> source of truth.
>>>>
>>>> I believe you run "git reset --hard master" on Site to force it to
>>>> equal
>>>> master. Note that this completely overwrites site with all the commits
>>>> from Master and drops commits that were in Site but not in Master.
>>>> Therefore it is important to make sure any commits that were on Site
>>>> but
>>>> not on Master are "fixed" by making sure they are on Master first.
>>>>
>>>> Once that's done, just publish the site following the instructions in
>>>> site/README.md
>>>>
>>>> Hope that helps!
>>>>
>>>> Francis
>>>>
>>>> On 7/10/2020 7:08 am, Ruben Q L wrote:
>>>> > Hi all,
>>>> >
>>>> > I have to publish the site after the release 1.26.0, it is the first
>>>> time
>>>> > that I do such a thing, and I don't want to mess things up (especially
>>>> > since I am not a git expert).
>>>> >
>>>> > I do not understand the current situation between 'master' and 'site'
>>>> > branches. It looks like they have diverged: 'site' branch is
>>>> currently "2
>>>> > commits ahead, 99 commits behind master" [1], is this normal or
>>>> expected?
>>>> > The ahead commits seem to be:
>>>> > -
>>>> >
>>>> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
>>>> > -
>>>> >
>>>> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
>>>> >
>>>> > The second one is an interesting case, it seems that the exact same
>>>> change
>>>> > was also committed to master (as a different commit):
>>>> > -
>>>> >
>>>> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
>>>> > I guess this was a cherry-pick? Is this normal? In that case, why the
>>>> other
>>>> > one was not applied to master?
>>>> >
>>>> > My question is, how should I proceed? Shall I merge master into site?
>>>> site
>>>> > into master? both? I have tried both locally, and they cannot be
>>>> > fast-forwarded (merge --ff-only).
>>>> >
>>>> > Then, which branch should I use to re-build the site and re-generate
>>>> the
>>>> > javadoc before pushing it into the calcite-site repo? Master? Site?
>>>> Either
>>>> > of them once they are aligned?
>>>> >
>>>> > Thanks,
>>>> > Ruben
>>>> >
>>>> > [1] https://github.com/apache/calcite/tree/site
>>>> >
>>>>
>>>

Re: [HELP] Publishing site after release 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Sorry, my bad, I was using my "normal" github password, instead of a
Personal Access Token.
I have just pushed the web site.

Working on the javadoc....


On Wed, Oct 7, 2020 at 12:40 PM Ruben Q L <ru...@gmail.com> wrote:

>
> It seems I cannot push into calcite-site repo (
> https://github.com/apache/calcite-site.git/)
> Am I missing something?
>
>
>
> On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:
>
>> Stamatis, Francis, thank you very much for the feedback.
>> I will work on that.
>>
>> Ruben
>>
>>
>> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <fr...@apache.org>
>> wrote:
>>
>>> Hi Ruben,
>>>
>>> Thanks for getting the released rolled out.
>>>
>>> In general, when making changes to the website:
>>> - Master is the source of truth.
>>> - Commit to Master first.
>>> - Cherry pick into Site.
>>> - Build Site and publish.
>>>
>>> If a commit is on site, but not on master, then the person making the
>>> change made a small mistake and you should make sure the commit is
>>> cherry-picked into master.
>>>
>>> After a release, we need to make Site equal Master since Master is the
>>> source of truth.
>>>
>>> I believe you run "git reset --hard master" on Site to force it to equal
>>> master. Note that this completely overwrites site with all the commits
>>> from Master and drops commits that were in Site but not in Master.
>>> Therefore it is important to make sure any commits that were on Site but
>>> not on Master are "fixed" by making sure they are on Master first.
>>>
>>> Once that's done, just publish the site following the instructions in
>>> site/README.md
>>>
>>> Hope that helps!
>>>
>>> Francis
>>>
>>> On 7/10/2020 7:08 am, Ruben Q L wrote:
>>> > Hi all,
>>> >
>>> > I have to publish the site after the release 1.26.0, it is the first
>>> time
>>> > that I do such a thing, and I don't want to mess things up (especially
>>> > since I am not a git expert).
>>> >
>>> > I do not understand the current situation between 'master' and 'site'
>>> > branches. It looks like they have diverged: 'site' branch is currently
>>> "2
>>> > commits ahead, 99 commits behind master" [1], is this normal or
>>> expected?
>>> > The ahead commits seem to be:
>>> > -
>>> >
>>> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
>>> > -
>>> >
>>> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
>>> >
>>> > The second one is an interesting case, it seems that the exact same
>>> change
>>> > was also committed to master (as a different commit):
>>> > -
>>> >
>>> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
>>> > I guess this was a cherry-pick? Is this normal? In that case, why the
>>> other
>>> > one was not applied to master?
>>> >
>>> > My question is, how should I proceed? Shall I merge master into site?
>>> site
>>> > into master? both? I have tried both locally, and they cannot be
>>> > fast-forwarded (merge --ff-only).
>>> >
>>> > Then, which branch should I use to re-build the site and re-generate
>>> the
>>> > javadoc before pushing it into the calcite-site repo? Master? Site?
>>> Either
>>> > of them once they are aligned?
>>> >
>>> > Thanks,
>>> > Ruben
>>> >
>>> > [1] https://github.com/apache/calcite/tree/site
>>> >
>>>
>>

Re: [HELP] Publishing site after release 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
It seems I cannot push into calcite-site repo (
https://github.com/apache/calcite-site.git/)
Am I missing something?



On Wed, Oct 7, 2020 at 8:02 AM Ruben Q L <ru...@gmail.com> wrote:

> Stamatis, Francis, thank you very much for the feedback.
> I will work on that.
>
> Ruben
>
>
> On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <fr...@apache.org>
> wrote:
>
>> Hi Ruben,
>>
>> Thanks for getting the released rolled out.
>>
>> In general, when making changes to the website:
>> - Master is the source of truth.
>> - Commit to Master first.
>> - Cherry pick into Site.
>> - Build Site and publish.
>>
>> If a commit is on site, but not on master, then the person making the
>> change made a small mistake and you should make sure the commit is
>> cherry-picked into master.
>>
>> After a release, we need to make Site equal Master since Master is the
>> source of truth.
>>
>> I believe you run "git reset --hard master" on Site to force it to equal
>> master. Note that this completely overwrites site with all the commits
>> from Master and drops commits that were in Site but not in Master.
>> Therefore it is important to make sure any commits that were on Site but
>> not on Master are "fixed" by making sure they are on Master first.
>>
>> Once that's done, just publish the site following the instructions in
>> site/README.md
>>
>> Hope that helps!
>>
>> Francis
>>
>> On 7/10/2020 7:08 am, Ruben Q L wrote:
>> > Hi all,
>> >
>> > I have to publish the site after the release 1.26.0, it is the first
>> time
>> > that I do such a thing, and I don't want to mess things up (especially
>> > since I am not a git expert).
>> >
>> > I do not understand the current situation between 'master' and 'site'
>> > branches. It looks like they have diverged: 'site' branch is currently
>> "2
>> > commits ahead, 99 commits behind master" [1], is this normal or
>> expected?
>> > The ahead commits seem to be:
>> > -
>> >
>> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
>> > -
>> >
>> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
>> >
>> > The second one is an interesting case, it seems that the exact same
>> change
>> > was also committed to master (as a different commit):
>> > -
>> >
>> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
>> > I guess this was a cherry-pick? Is this normal? In that case, why the
>> other
>> > one was not applied to master?
>> >
>> > My question is, how should I proceed? Shall I merge master into site?
>> site
>> > into master? both? I have tried both locally, and they cannot be
>> > fast-forwarded (merge --ff-only).
>> >
>> > Then, which branch should I use to re-build the site and re-generate the
>> > javadoc before pushing it into the calcite-site repo? Master? Site?
>> Either
>> > of them once they are aligned?
>> >
>> > Thanks,
>> > Ruben
>> >
>> > [1] https://github.com/apache/calcite/tree/site
>> >
>>
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Stamatis, Francis, thank you very much for the feedback.
I will work on that.

Ruben


On Tue, Oct 6, 2020 at 11:03 PM Francis Chuang <fr...@apache.org>
wrote:

> Hi Ruben,
>
> Thanks for getting the released rolled out.
>
> In general, when making changes to the website:
> - Master is the source of truth.
> - Commit to Master first.
> - Cherry pick into Site.
> - Build Site and publish.
>
> If a commit is on site, but not on master, then the person making the
> change made a small mistake and you should make sure the commit is
> cherry-picked into master.
>
> After a release, we need to make Site equal Master since Master is the
> source of truth.
>
> I believe you run "git reset --hard master" on Site to force it to equal
> master. Note that this completely overwrites site with all the commits
> from Master and drops commits that were in Site but not in Master.
> Therefore it is important to make sure any commits that were on Site but
> not on Master are "fixed" by making sure they are on Master first.
>
> Once that's done, just publish the site following the instructions in
> site/README.md
>
> Hope that helps!
>
> Francis
>
> On 7/10/2020 7:08 am, Ruben Q L wrote:
> > Hi all,
> >
> > I have to publish the site after the release 1.26.0, it is the first time
> > that I do such a thing, and I don't want to mess things up (especially
> > since I am not a git expert).
> >
> > I do not understand the current situation between 'master' and 'site'
> > branches. It looks like they have diverged: 'site' branch is currently "2
> > commits ahead, 99 commits behind master" [1], is this normal or expected?
> > The ahead commits seem to be:
> > -
> >
> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
> > -
> >
> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
> >
> > The second one is an interesting case, it seems that the exact same
> change
> > was also committed to master (as a different commit):
> > -
> >
> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
> > I guess this was a cherry-pick? Is this normal? In that case, why the
> other
> > one was not applied to master?
> >
> > My question is, how should I proceed? Shall I merge master into site?
> site
> > into master? both? I have tried both locally, and they cannot be
> > fast-forwarded (merge --ff-only).
> >
> > Then, which branch should I use to re-build the site and re-generate the
> > javadoc before pushing it into the calcite-site repo? Master? Site?
> Either
> > of them once they are aligned?
> >
> > Thanks,
> > Ruben
> >
> > [1] https://github.com/apache/calcite/tree/site
> >
>

Re: [HELP] Publishing site after release 1.26.0

Posted by Francis Chuang <fr...@apache.org>.
Hi Ruben,

Thanks for getting the released rolled out.

In general, when making changes to the website:
- Master is the source of truth.
- Commit to Master first.
- Cherry pick into Site.
- Build Site and publish.

If a commit is on site, but not on master, then the person making the 
change made a small mistake and you should make sure the commit is 
cherry-picked into master.

After a release, we need to make Site equal Master since Master is the 
source of truth.

I believe you run "git reset --hard master" on Site to force it to equal 
master. Note that this completely overwrites site with all the commits 
from Master and drops commits that were in Site but not in Master. 
Therefore it is important to make sure any commits that were on Site but 
not on Master are "fixed" by making sure they are on Master first.

Once that's done, just publish the site following the instructions in 
site/README.md

Hope that helps!

Francis

On 7/10/2020 7:08 am, Ruben Q L wrote:
> Hi all,
> 
> I have to publish the site after the release 1.26.0, it is the first time
> that I do such a thing, and I don't want to mess things up (especially
> since I am not a git expert).
> 
> I do not understand the current situation between 'master' and 'site'
> branches. It looks like they have diverged: 'site' branch is currently "2
> commits ahead, 99 commits behind master" [1], is this normal or expected?
> The ahead commits seem to be:
> -
> https://github.com/apache/calcite/commit/8cf0701dac5aad7d695709d8e35957c261f8ae82
> -
> https://github.com/apache/calcite/commit/b65944772c7234612fc5a8c84384d40a5cfa6d84
> 
> The second one is an interesting case, it seems that the exact same change
> was also committed to master (as a different commit):
> -
> https://github.com/apache/calcite/commit/0920796bb917ee8420d2534233486ca0413b4430
> I guess this was a cherry-pick? Is this normal? In that case, why the other
> one was not applied to master?
> 
> My question is, how should I proceed? Shall I merge master into site? site
> into master? both? I have tried both locally, and they cannot be
> fast-forwarded (merge --ff-only).
> 
> Then, which branch should I use to re-build the site and re-generate the
> javadoc before pushing it into the calcite-site repo? Master? Site? Either
> of them once they are aligned?
> 
> Thanks,
> Ruben
> 
> [1] https://github.com/apache/calcite/tree/site
>