You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by Jungtaek Lim <ka...@gmail.com> on 2017/08/01 11:00:39 UTC
Re: Considerably slow building website
I found I forgot to build website with "-d publish/" parameter. Now it
reduced to 1347.585 secs but that is still way too long
I've done some tests on building website ('jekyll build -d publish/
--profile'):
1. as it is : 1347.585 secs
2. excluding 'releases' directories : 2.38 secs
3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
directory of releases : 45 secs
The build time is not stable but you can see how much the difference is. If
we can separate building doc for each release, that should be best and it
should reduce the build time greatly.
If we can't separate building doc, we may want to take alternative
approach: reducing maintaining releases. You can imagine that if we keep
adding docs for new releases in website repo it should increase overall
build time. I guess we may be better to provide only the last version of
version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
changes shouldn't be introduced in bug-fix releases so don't need to
maintain docs separately.
I would like to gather opinions around this along with moving website to
git. Looking forward to hear others opinions.
Thanks,
Jungtaek Lim (HeartSaVioR)
2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
> Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
> directory is not created in 'publish/releases' directory. Maybe also missed
> that.
>
> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
>> Hi devs,
>>
>> I'm trying to modify release note on 1.0.4 one of user reported about
>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
>> website locally. Any hints to reduce the time? 50 mins for only building
>> the website is really annoying and anyone don't want to wait for that if we
>> modify "a" file.
>>
>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
>> could you add it back to the SVN repo?
>>
>> Thanks,
>> Jungtaek Lim (HeartSaVioR)
>>
>
Re: Considerably slow building website
Posted by Jungtaek Lim <ka...@gmail.com>.
Another approach is separating release specific docs and common docs. I
found other projects are already doing that, most of them are using root
path as common, and docs/<release_version>/ as release specific. Common
docs still need to provide menu to link the root page of each release docs
indeed.
This approach needs some redesign of docs: that is only blocker for the
approach.
2017년 8월 1일 (화) 오후 10:39, Bobby Evans <ev...@yahoo-inc.com.invalid>님이 작성:
> Rebuilding everything each time is sadly necessary as currently the
> header/footer for all of the content is inline in each page. So if we add
> a new release every page changes. To fix this we would have to change the
> header to dynamically include the HTML from another file that gets updated
> on it's own.
> We might also want to think about rearranging things a bit, and reduce the
> number of releases that we have on the site. Do we really need both 0.9.6
> and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive some
> of these so they are a part of the final site, but are not generated each
> time? (probably would need the header change at a minimum to work)
>
>
> - Bobby
>
>
> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <
> kabhwan@gmail.com> wrote:
>
> I found I forgot to build website with "-d publish/" parameter. Now it
> reduced to 1347.585 secs but that is still way too long
>
> I've done some tests on building website ('jekyll build -d publish/
> --profile'):
>
> 1. as it is : 1347.585 secs
> 2. excluding 'releases' directories : 2.38 secs
> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
> directory of releases : 45 secs
>
> The build time is not stable but you can see how much the difference is. If
> we can separate building doc for each release, that should be best and it
> should reduce the build time greatly.
>
> If we can't separate building doc, we may want to take alternative
> approach: reducing maintaining releases. You can imagine that if we keep
> adding docs for new releases in website repo it should increase overall
> build time. I guess we may be better to provide only the last version of
> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
> changes shouldn't be introduced in bug-fix releases so don't need to
> maintain docs separately.
>
> I would like to gather opinions around this along with moving website to
> git. Looking forward to hear others opinions.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
> > Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
> > directory is not created in 'publish/releases' directory. Maybe also
> missed
> > that.
> >
> > 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
> >
> >> Hi devs,
> >>
> >> I'm trying to modify release note on 1.0.4 one of user reported about
> >> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
> >> website locally. Any hints to reduce the time? 50 mins for only building
> >> the website is really annoying and anyone don't want to wait for that
> if we
> >> modify "a" file.
> >>
> >> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
> >> could you add it back to the SVN repo?
> >>
> >> Thanks,
> >> Jungtaek Lim (HeartSaVioR)
> >>
> >
Re: Considerably slow building website
Posted by Jungtaek Lim <ka...@gmail.com>.
I can't think better way than separating common docs and release specific
docs.
This approach allows us get rid of all release specific docs (source md
files) from storm site repo, and we only need to build them from storm repo
and copy to publish directory of storm site repo. On the side effect,
release specific docs will not expose the link to move to another releases.
If we are OK to go on this approach, dropping 'First Look' section and
'Documentation' on footer would be necessary, which mean we no longer rely
on 'current' release.
'Documentation' section clearly matches specific release so just good to
drop. Docs in 'First Look' barely change so maybe we can bring them to the
common docs, but even if we want to maintain per release manner, we can
just move 'First Look' to the first of 'Documentation' page of each release.
We need to have another header and footer for release specific docs so that
it doesn't rely on other releases. We may also want to isolate doc links to
the release specific docs, but not 100% sure this is what most of us want.
2017년 8월 2일 (수) 오전 3:29, P. Taylor Goetz <pt...@gmail.com>님이 작성:
> Thanks for the heads up. If I screw something up we can always regenerate
> from the release tag.
>
> -Taylor
>
> > On Aug 1, 2017, at 2:27 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID>
> wrote:
> >
> > Be careful when removing the javadocs. There are links to the javadocs
> from within the docs themselves.
> >
> >
> > - Bobby
> >
> >
> > On Tuesday, August 1, 2017, 12:57:56 PM CDT, P. Taylor Goetz <
> ptgoetz@gmail.com> wrote:
> >
> > I cleaned up the download page to remove some of the older releases and
> added a link to archive.a.o for older releases. I will also clean up dist
> as requested by infra.
> >
> > While I’m at it, I’ll clean up the javadoc so we only include javadoc
> for releases on the download page.
> >
> > That should help a little bit, but I agree that the publishing process
> is painful and would welcome any improvements.
> >
> > One option (I haven’t tested yet) might be to simply move the javadoc to
> the “publish” directory so it doesn’t get regenerated every time the site
> gets published. That would mean the javadoc links won’t work when running
> Jekyll locally, but I think it’s a fair trade off.
> >
> > -Taylor
> >
> >> On Aug 1, 2017, at 9:39 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID>
> wrote:
> >>
> >> Rebuilding everything each time is sadly necessary as currently the
> header/footer for all of the content is inline in each page. So if we add
> a new release every page changes. To fix this we would have to change the
> header to dynamically include the HTML from another file that gets updated
> on it's own.
> >> We might also want to think about rearranging things a bit, and reduce
> the number of releases that we have on the site. Do we really need both
> 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive
> some of these so they are a part of the final site, but are not generated
> each time? (probably would need the header change at a minimum to work)
> >>
> >>
> >> - Bobby
> >>
> >>
> >> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <
> kabhwan@gmail.com> wrote:
> >>
> >> I found I forgot to build website with "-d publish/" parameter. Now it
> >> reduced to 1347.585 secs but that is still way too long
> >>
> >> I've done some tests on building website ('jekyll build -d publish/
> >> --profile'):
> >>
> >> 1. as it is : 1347.585 secs
> >> 2. excluding 'releases' directories : 2.38 secs
> >> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
> >> directory of releases : 45 secs
> >>
> >> The build time is not stable but you can see how much the difference
> is. If
> >> we can separate building doc for each release, that should be best and
> it
> >> should reduce the build time greatly.
> >>
> >> If we can't separate building doc, we may want to take alternative
> >> approach: reducing maintaining releases. You can imagine that if we keep
> >> adding docs for new releases in website repo it should increase overall
> >> build time. I guess we may be better to provide only the last version of
> >> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
> >> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning,
> major
> >> changes shouldn't be introduced in bug-fix releases so don't need to
> >> maintain docs separately.
> >>
> >> I would like to gather opinions around this along with moving website to
> >> git. Looking forward to hear others opinions.
> >>
> >> Thanks,
> >> Jungtaek Lim (HeartSaVioR)
> >>
> >> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
> >>
> >>> Also found that we don't expose 1.0.4 in documentation dropdown and
> 1.0.4
> >>> directory is not created in 'publish/releases' directory. Maybe also
> missed
> >>> that.
> >>>
> >>> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
> >>>
> >>>> Hi devs,
> >>>>
> >>>> I'm trying to modify release note on 1.0.4 one of user reported about
> >>>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
> >>>> website locally. Any hints to reduce the time? 50 mins for only
> building
> >>>> the website is really annoying and anyone don't want to wait for that
> if we
> >>>> modify "a" file.
> >>>>
> >>>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
> >>>> could you add it back to the SVN repo?
> >>>>
> >>>> Thanks,
> >>>> Jungtaek Lim (HeartSaVioR)
> >>>>
>
>
Re: Considerably slow building website
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Thanks for the heads up. If I screw something up we can always regenerate from the release tag.
-Taylor
> On Aug 1, 2017, at 2:27 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>
> Be careful when removing the javadocs. There are links to the javadocs from within the docs themselves.
>
>
> - Bobby
>
>
> On Tuesday, August 1, 2017, 12:57:56 PM CDT, P. Taylor Goetz <pt...@gmail.com> wrote:
>
> I cleaned up the download page to remove some of the older releases and added a link to archive.a.o for older releases. I will also clean up dist as requested by infra.
>
> While I’m at it, I’ll clean up the javadoc so we only include javadoc for releases on the download page.
>
> That should help a little bit, but I agree that the publishing process is painful and would welcome any improvements.
>
> One option (I haven’t tested yet) might be to simply move the javadoc to the “publish” directory so it doesn’t get regenerated every time the site gets published. That would mean the javadoc links won’t work when running Jekyll locally, but I think it’s a fair trade off.
>
> -Taylor
>
>> On Aug 1, 2017, at 9:39 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>>
>> Rebuilding everything each time is sadly necessary as currently the header/footer for all of the content is inline in each page. So if we add a new release every page changes. To fix this we would have to change the header to dynamically include the HTML from another file that gets updated on it's own.
>> We might also want to think about rearranging things a bit, and reduce the number of releases that we have on the site. Do we really need both 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive some of these so they are a part of the final site, but are not generated each time? (probably would need the header change at a minimum to work)
>>
>>
>> - Bobby
>>
>>
>> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <ka...@gmail.com> wrote:
>>
>> I found I forgot to build website with "-d publish/" parameter. Now it
>> reduced to 1347.585 secs but that is still way too long
>>
>> I've done some tests on building website ('jekyll build -d publish/
>> --profile'):
>>
>> 1. as it is : 1347.585 secs
>> 2. excluding 'releases' directories : 2.38 secs
>> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
>> directory of releases : 45 secs
>>
>> The build time is not stable but you can see how much the difference is. If
>> we can separate building doc for each release, that should be best and it
>> should reduce the build time greatly.
>>
>> If we can't separate building doc, we may want to take alternative
>> approach: reducing maintaining releases. You can imagine that if we keep
>> adding docs for new releases in website repo it should increase overall
>> build time. I guess we may be better to provide only the last version of
>> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
>> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
>> changes shouldn't be introduced in bug-fix releases so don't need to
>> maintain docs separately.
>>
>> I would like to gather opinions around this along with moving website to
>> git. Looking forward to hear others opinions.
>>
>> Thanks,
>> Jungtaek Lim (HeartSaVioR)
>>
>> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>
>>> Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
>>> directory is not created in 'publish/releases' directory. Maybe also missed
>>> that.
>>>
>>> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>>
>>>> Hi devs,
>>>>
>>>> I'm trying to modify release note on 1.0.4 one of user reported about
>>>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
>>>> website locally. Any hints to reduce the time? 50 mins for only building
>>>> the website is really annoying and anyone don't want to wait for that if we
>>>> modify "a" file.
>>>>
>>>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
>>>> could you add it back to the SVN repo?
>>>>
>>>> Thanks,
>>>> Jungtaek Lim (HeartSaVioR)
>>>>
Re: Considerably slow building website
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
Be careful when removing the javadocs. There are links to the javadocs from within the docs themselves.
- Bobby
On Tuesday, August 1, 2017, 12:57:56 PM CDT, P. Taylor Goetz <pt...@gmail.com> wrote:
I cleaned up the download page to remove some of the older releases and added a link to archive.a.o for older releases. I will also clean up dist as requested by infra.
While I’m at it, I’ll clean up the javadoc so we only include javadoc for releases on the download page.
That should help a little bit, but I agree that the publishing process is painful and would welcome any improvements.
One option (I haven’t tested yet) might be to simply move the javadoc to the “publish” directory so it doesn’t get regenerated every time the site gets published. That would mean the javadoc links won’t work when running Jekyll locally, but I think it’s a fair trade off.
-Taylor
> On Aug 1, 2017, at 9:39 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>
> Rebuilding everything each time is sadly necessary as currently the header/footer for all of the content is inline in each page. So if we add a new release every page changes. To fix this we would have to change the header to dynamically include the HTML from another file that gets updated on it's own.
> We might also want to think about rearranging things a bit, and reduce the number of releases that we have on the site. Do we really need both 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive some of these so they are a part of the final site, but are not generated each time? (probably would need the header change at a minimum to work)
>
>
> - Bobby
>
>
> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <ka...@gmail.com> wrote:
>
> I found I forgot to build website with "-d publish/" parameter. Now it
> reduced to 1347.585 secs but that is still way too long
>
> I've done some tests on building website ('jekyll build -d publish/
> --profile'):
>
> 1. as it is : 1347.585 secs
> 2. excluding 'releases' directories : 2.38 secs
> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
> directory of releases : 45 secs
>
> The build time is not stable but you can see how much the difference is. If
> we can separate building doc for each release, that should be best and it
> should reduce the build time greatly.
>
> If we can't separate building doc, we may want to take alternative
> approach: reducing maintaining releases. You can imagine that if we keep
> adding docs for new releases in website repo it should increase overall
> build time. I guess we may be better to provide only the last version of
> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
> changes shouldn't be introduced in bug-fix releases so don't need to
> maintain docs separately.
>
> I would like to gather opinions around this along with moving website to
> git. Looking forward to hear others opinions.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
>> Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
>> directory is not created in 'publish/releases' directory. Maybe also missed
>> that.
>>
>> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>
>>> Hi devs,
>>>
>>> I'm trying to modify release note on 1.0.4 one of user reported about
>>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
>>> website locally. Any hints to reduce the time? 50 mins for only building
>>> the website is really annoying and anyone don't want to wait for that if we
>>> modify "a" file.
>>>
>>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
>>> could you add it back to the SVN repo?
>>>
>>> Thanks,
>>> Jungtaek Lim (HeartSaVioR)
>>>
Re: Considerably slow building website
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
I cleaned up the download page to remove some of the older releases and added a link to archive.a.o for older releases. I will also clean up dist as requested by infra.
While I’m at it, I’ll clean up the javadoc so we only include javadoc for releases on the download page.
That should help a little bit, but I agree that the publishing process is painful and would welcome any improvements.
One option (I haven’t tested yet) might be to simply move the javadoc to the “publish” directory so it doesn’t get regenerated every time the site gets published. That would mean the javadoc links won’t work when running Jekyll locally, but I think it’s a fair trade off.
-Taylor
> On Aug 1, 2017, at 9:39 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>
> Rebuilding everything each time is sadly necessary as currently the header/footer for all of the content is inline in each page. So if we add a new release every page changes. To fix this we would have to change the header to dynamically include the HTML from another file that gets updated on it's own.
> We might also want to think about rearranging things a bit, and reduce the number of releases that we have on the site. Do we really need both 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive some of these so they are a part of the final site, but are not generated each time? (probably would need the header change at a minimum to work)
>
>
> - Bobby
>
>
> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <ka...@gmail.com> wrote:
>
> I found I forgot to build website with "-d publish/" parameter. Now it
> reduced to 1347.585 secs but that is still way too long
>
> I've done some tests on building website ('jekyll build -d publish/
> --profile'):
>
> 1. as it is : 1347.585 secs
> 2. excluding 'releases' directories : 2.38 secs
> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
> directory of releases : 45 secs
>
> The build time is not stable but you can see how much the difference is. If
> we can separate building doc for each release, that should be best and it
> should reduce the build time greatly.
>
> If we can't separate building doc, we may want to take alternative
> approach: reducing maintaining releases. You can imagine that if we keep
> adding docs for new releases in website repo it should increase overall
> build time. I guess we may be better to provide only the last version of
> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
> changes shouldn't be introduced in bug-fix releases so don't need to
> maintain docs separately.
>
> I would like to gather opinions around this along with moving website to
> git. Looking forward to hear others opinions.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
>> Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
>> directory is not created in 'publish/releases' directory. Maybe also missed
>> that.
>>
>> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
>>
>>> Hi devs,
>>>
>>> I'm trying to modify release note on 1.0.4 one of user reported about
>>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
>>> website locally. Any hints to reduce the time? 50 mins for only building
>>> the website is really annoying and anyone don't want to wait for that if we
>>> modify "a" file.
>>>
>>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
>>> could you add it back to the SVN repo?
>>>
>>> Thanks,
>>> Jungtaek Lim (HeartSaVioR)
>>>
Re: Considerably slow building website
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
Rebuilding everything each time is sadly necessary as currently the header/footer for all of the content is inline in each page. So if we add a new release every page changes. To fix this we would have to change the header to dynamically include the HTML from another file that gets updated on it's own.
We might also want to think about rearranging things a bit, and reduce the number of releases that we have on the site. Do we really need both 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive some of these so they are a part of the final site, but are not generated each time? (probably would need the header change at a minimum to work)
- Bobby
On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim <ka...@gmail.com> wrote:
I found I forgot to build website with "-d publish/" parameter. Now it
reduced to 1347.585 secs but that is still way too long
I've done some tests on building website ('jekyll build -d publish/
--profile'):
1. as it is : 1347.585 secs
2. excluding 'releases' directories : 2.38 secs
3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT'
directory of releases : 45 secs
The build time is not stable but you can see how much the difference is. If
we can separate building doc for each release, that should be best and it
should reduce the build time greatly.
If we can't separate building doc, we may want to take alternative
approach: reducing maintaining releases. You can imagine that if we keep
adding docs for new releases in website repo it should increase overall
build time. I guess we may be better to provide only the last version of
version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon),
2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, major
changes shouldn't be introduced in bug-fix releases so don't need to
maintain docs separately.
I would like to gather opinions around this along with moving website to
git. Looking forward to hear others opinions.
Thanks,
Jungtaek Lim (HeartSaVioR)
2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <ka...@gmail.com>님이 작성:
> Also found that we don't expose 1.0.4 in documentation dropdown and 1.0.4
> directory is not created in 'publish/releases' directory. Maybe also missed
> that.
>
> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <ka...@gmail.com>님이 작성:
>
>> Hi devs,
>>
>> I'm trying to modify release note on 1.0.4 one of user reported about
>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the
>> website locally. Any hints to reduce the time? 50 mins for only building
>> the website is really annoying and anyone don't want to wait for that if we
>> modify "a" file.
>>
>> And I found Storm 1.1.0 release note markdown file is missing. Taylor,
>> could you add it back to the SVN repo?
>>
>> Thanks,
>> Jungtaek Lim (HeartSaVioR)
>>
>