[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513660#comment-15513660
]
Steve Rowe commented on SOLR-6871:
--
Thanks [~janhoy] - for some reason your branch_6x commit didn't get posted here
- from the email notification to commits@l.a.o:
{quote}
Repository: lucene-solr
Updated Branches:
refs/heads/branch_6x 082f8e3f9 -> 9611478c7
SOLR-6871: Fix precommit - accept /solr/downloads.html as valid link
(cherry picked from commit d146354)
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/9611478c
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/9611478c
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/9611478c
Branch: refs/heads/branch_6x
Commit: 9611478c7e249b7c65d3807e2ae672aabaefa50b
Parents: 082f8e3
Author: Jan Høydahl
Authored: Thu Sep 22 10:52:01 2016 +0200
Committer: Jan Høydahl
Committed: Thu Sep 22 10:53:21 2016 +0200
{quote}
> Need a process for updating & maintaining the new quickstart tutorial (and
> any other tutorials added to the website)
>
>
> Key: SOLR-6871
> URL: https://issues.apache.org/jira/browse/SOLR-6871
> Project: Solr
> Issue Type: Task
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-6871.patch
>
>
> Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only
> a simple landing page that then linked people to the "versioned" tutorial for
> the most recent release -- or more specificly: the most recent release*s*
> (plural) when we were releasing off of multiple branches (ie: links to both
> the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out)
> The old tutorial content lived along side the solr code, and was
> automatically branched, tagged & released along with Solr. When committing
> any changes to Solr code (or post.jar code, or the sample data, or the sample
> configs, etc..) you could also commit changes to the tutorial at th same time
> and be confident that it was clear what version of solr that tutorial went
> along with.
> As part of SOLR-6058, it seems that there was a concensus to move to a
> keeping "tutorial" content on the website, where it can be integrated
> directly in with other site content/navigation, and use the same look and
> feel.
> I have no objection to this in principle -- but as a result of this choice,
> there are outstanding issues regarding how devs should go about maintaining
> this doc as changes are made to solr & the solr examples used in the tutorial.
> We need a clear process for where/how to edit the tutorial(s) as new versions
> of solr come out and cahnges are made that mandate corisponding hanges to the
> tutorial. this process _should_ also account for things like having multiple
> versions of the tutorial live at one time (ie: at some point in the future,
> we'll certainly need to host the "5.13" tutorial if that's the current
> "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so
> that people can try it out)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512661#comment-15512661 ] ASF subversion and git services commented on SOLR-6871: --- Commit d14635445750cfcde2deca4d9f400d2c839f15eb in lucene-solr's branch refs/heads/master from [~janhoy] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d146354 ] SOLR-6871: Fix precommit - accept /solr/downloads.html as valid link > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512597#comment-15512597
]
Jan Høydahl commented on SOLR-6871:
---
Precommit fails as noted by [~dawid.weiss] in SOLR-8186:
{noformat}
-documentation-lint:
[jtidy] Checking for broken html (such as invalid tags)...
[delete] Deleting directory
/mnt/storage/dweiss/work/lucene-solr/lucene/build/jtidy_tmp
[echo] Checking for broken links...
[exec]
[exec] Crawl/parse...
[exec]
[exec] Verify...
[exec]
[exec]
file:///mnt/storage/dweiss/work/lucene-solr/solr/build/docs/quickstart.html
[exec] BAD EXTERNAL LINK: http://lucene.apache.org/solr/downloads.html
[exec]
[exec] Broken javadocs links were found!
{noformat}
Will commit a fix now
> Need a process for updating & maintaining the new quickstart tutorial (and
> any other tutorials added to the website)
>
>
> Key: SOLR-6871
> URL: https://issues.apache.org/jira/browse/SOLR-6871
> Project: Solr
> Issue Type: Task
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-6871.patch
>
>
> Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only
> a simple landing page that then linked people to the "versioned" tutorial for
> the most recent release -- or more specificly: the most recent release*s*
> (plural) when we were releasing off of multiple branches (ie: links to both
> the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out)
> The old tutorial content lived along side the solr code, and was
> automatically branched, tagged & released along with Solr. When committing
> any changes to Solr code (or post.jar code, or the sample data, or the sample
> configs, etc..) you could also commit changes to the tutorial at th same time
> and be confident that it was clear what version of solr that tutorial went
> along with.
> As part of SOLR-6058, it seems that there was a concensus to move to a
> keeping "tutorial" content on the website, where it can be integrated
> directly in with other site content/navigation, and use the same look and
> feel.
> I have no objection to this in principle -- but as a result of this choice,
> there are outstanding issues regarding how devs should go about maintaining
> this doc as changes are made to solr & the solr examples used in the tutorial.
> We need a clear process for where/how to edit the tutorial(s) as new versions
> of solr come out and cahnges are made that mandate corisponding hanges to the
> tutorial. this process _should_ also account for things like having multiple
> versions of the tutorial live at one time (ie: at some point in the future,
> we'll certainly need to host the "5.13" tutorial if that's the current
> "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so
> that people can try it out)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511717#comment-15511717 ] Steve Rowe commented on SOLR-6871: -- I committed the updated quickstart tutorial in both places. I'll leave the issue open for a little while in case anybody wants to do more here. > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511680#comment-15511680 ] ASF subversion and git services commented on SOLR-6871: --- Commit 1761836 from [~steve_rowe] in branch 'cms/trunk' [ https://svn.apache.org/r1761836 ] SOLR-6871: Updated the quickstart tutorial to cover the 6.2.0 release > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511594#comment-15511594 ] ASF subversion and git services commented on SOLR-6871: --- Commit 53981795fd73e85aae1892c3c72344af7c57083a in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5398179 ] SOLR-6871: Updated the quickstart tutorial to cover the 6.2.0 release, and added ant target "generate-website-quickstart" to convert the bundled version of the tutorial into one suitable for the website. > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511593#comment-15511593 ] ASF subversion and git services commented on SOLR-6871: --- Commit 8984e73660427b4be37f5eae177fbf8697e2e0c0 in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8984e73 ] SOLR-6871: Updated the quickstart tutorial to cover the 6.2.0 release, and added ant target "generate-website-quickstart" to convert the bundled version of the tutorial into one suitable for the website. > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Steve Rowe >Priority: Minor > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507593#comment-15507593 ] Steve Rowe commented on SOLR-6871: -- [~arafalov]: bq. So, what do we do about this? [...] Is this just a matter of one person taking a lead and updating the tutorial as they see fit? Or is there some sort of discussion on which features need to be highlighted and which can be omitted. I think the normal process should work okay - Lucene/Solr's official process is commit-then-review, but (as I've just done) pre-commit communication via patches should work too. But maybe you're thinking about the live website? I think we should err on the side of exhausting available review prior to publishing there. (My version of that here was giving a rough deadline at which I'll publish if I havn't gotten any review.) bq. And with links to the Reference Guide, do we link into the live version of it (easy and convenient) or do an offline reference to the version-matched export? All of the links are to specific sections in the ref guide, and while I've seen internal PDF links work (depending on how the PDF was created and the PDF reader being used), I don't think they're dependable enough to allow us to use for this purpose. So I don't think there's a real choice at this point. However, once [~ctargett]'s ref guide work is in place ([https://github.com/ctargett/refguide-asciidoc-poc]), we should be able to make version-matched online docs that would be suitable for outbound links from the tutorial. > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Priority: Minor > Fix For: 5.0 > > Attachments: SOLR-6871.patch > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425534#comment-15425534 ] Alexandre Rafalovitch commented on SOLR-6871: - So, what do we do about this? Solr 6.2 is in the planning to be released and it would be good to get both website and the shipped version (still at '5.0') up to date and in sync. Is this just a matter of one person taking a lead and updating the tutorial as they see fit? Or is there some sort of discussion on which features need to be highlighted and which can be omitted. And with links to the Reference Guide, do we link into the live version of it (easy and convenient) or do an offline reference to the version-matched export? > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Priority: Minor > Fix For: 5.0 > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423207#comment-15423207 ] Christine Poerschke commented on SOLR-6871: --- Observations/Ideas from reading through http://lucene.apache.org/solr/quickstart.html today. * https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020 appears to be the source code but as mentioned above there is also in git (older version) https://github.com/apache/lucene-solr/blob/master/solr/site/quickstart.mdtext of the quickstart tutorial * We could link the "release" part of the "... you will need ... An Apache Solr release." to the download page. ([line 13|https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020=markup#l13]) * The "Query tab" link appears to be broken. ([line 106|https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020=markup#l106]) * The "Transforming and Indexing Custom JSON data" link appears to be broken. ([line 192|https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020=markup#l192]) * The "Indexing JSON" heading could become "Indexing Solr JSON" and its paragraph link into the Solr JSON reference guide section as is done for Solr XML. ([line 169|https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020=markup#l169]) * The "Indexing CSV" heading could link into the reference guide also. ([line 194|https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/quickstart.mdtext?revision=1705020=markup#l194]) > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Priority: Minor > Fix For: 5.0 > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322296#comment-15322296
]
Alexandre Rafalovitch commented on SOLR-6871:
-
Well, the shipped quickstart tutorial in Solr 6.0, says:
{quote}
To follow along with this tutorial, you will need…
1. To meet the system requirements
2. An Apache Solr release. This tutorial was written using *Apache Solr
5.0.0*
{quote}
So, I suspect it is not that the problem is less, but more that nobody quite
knows where to start.
> Need a process for updating & maintaining the new quickstart tutorial (and
> any other tutorials added to the website)
>
>
> Key: SOLR-6871
> URL: https://issues.apache.org/jira/browse/SOLR-6871
> Project: Solr
> Issue Type: Task
>Reporter: Hoss Man
>Priority: Minor
> Fix For: 5.0
>
>
> Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only
> a simple landing page that then linked people to the "versioned" tutorial for
> the most recent release -- or more specificly: the most recent release*s*
> (plural) when we were releasing off of multiple branches (ie: links to both
> the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out)
> The old tutorial content lived along side the solr code, and was
> automatically branched, tagged & released along with Solr. When committing
> any changes to Solr code (or post.jar code, or the sample data, or the sample
> configs, etc..) you could also commit changes to the tutorial at th same time
> and be confident that it was clear what version of solr that tutorial went
> along with.
> As part of SOLR-6058, it seems that there was a concensus to move to a
> keeping "tutorial" content on the website, where it can be integrated
> directly in with other site content/navigation, and use the same look and
> feel.
> I have no objection to this in principle -- but as a result of this choice,
> there are outstanding issues regarding how devs should go about maintaining
> this doc as changes are made to solr & the solr examples used in the tutorial.
> We need a clear process for where/how to edit the tutorial(s) as new versions
> of solr come out and cahnges are made that mandate corisponding hanges to the
> tutorial. this process _should_ also account for things like having multiple
> versions of the tutorial live at one time (ie: at some point in the future,
> we'll certainly need to host the "5.13" tutorial if that's the current
> "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so
> that people can try it out)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating & maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322248#comment-15322248 ] Adrien Grand commented on SOLR-6871: There has been no activity for a long time so I decreased the priority. > Need a process for updating & maintaining the new quickstart tutorial (and > any other tutorials added to the website) > > > Key: SOLR-6871 > URL: https://issues.apache.org/jira/browse/SOLR-6871 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Priority: Minor > Fix For: 5.0 > > > Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only > a simple landing page that then linked people to the "versioned" tutorial for > the most recent release -- or more specificly: the most recent release*s* > (plural) when we were releasing off of multiple branches (ie: links to both > the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) > The old tutorial content lived along side the solr code, and was > automatically branched, tagged & released along with Solr. When committing > any changes to Solr code (or post.jar code, or the sample data, or the sample > configs, etc..) you could also commit changes to the tutorial at th same time > and be confident that it was clear what version of solr that tutorial went > along with. > As part of SOLR-6058, it seems that there was a concensus to move to a > keeping "tutorial" content on the website, where it can be integrated > directly in with other site content/navigation, and use the same look and > feel. > I have no objection to this in principle -- but as a result of this choice, > there are outstanding issues regarding how devs should go about maintaining > this doc as changes are made to solr & the solr examples used in the tutorial. > We need a clear process for where/how to edit the tutorial(s) as new versions > of solr come out and cahnges are made that mandate corisponding hanges to the > tutorial. this process _should_ also account for things like having multiple > versions of the tutorial live at one time (ie: at some point in the future, > we'll certainly need to host the "5.13" tutorial if that's the current > "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so > that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating maintaining the new quickstart tutorial (and any other tutorials added to the website)
[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266857#comment-14266857
]
Steve Rowe commented on SOLR-6871:
--
I think it should be possible to share Markdown content between the website
quickstart tutorial and the versioned tutorial that ships with the release and
is part of the versioned docs on the website. That should serve both purposes:
a per-version tutorial, and the latest release tutorial with a consistent
lookfeel.
I'll look at what it will take to get the doc build to do this. We already
have some stuff getting converted from markdown now, via the pegdown macro (via
groovy) in {{lucene/common-build.xml}}.
Need a process for updating maintaining the new quickstart tutorial (and
any other tutorials added to the website)
Key: SOLR-6871
URL: https://issues.apache.org/jira/browse/SOLR-6871
Project: Solr
Issue Type: Task
Reporter: Hoss Man
Priority: Blocker
Fix For: 5.0
Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only
a simple landing page that then linked people to the versioned tutorial for
the most recent release -- or more specificly: the most recent release*s*
(plural) when we were releasing off of multiple branches (ie: links to both
the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out)
The old tutorial content lived along side the solr code, and was
automatically branched, tagged released along with Solr. When committing
any changes to Solr code (or post.jar code, or the sample data, or the sample
configs, etc..) you could also commit changes to the tutorial at th same time
and be confident that it was clear what version of solr that tutorial went
along with.
As part of SOLR-6058, it seems that there was a concensus to move to a
keeping tutorial content on the website, where it can be integrated
directly in with other site content/navigation, and use the same look and
feel.
I have no objection to this in principle -- but as a result of this choice,
there are outstanding issues regarding how devs should go about maintaining
this doc as changes are made to solr the solr examples used in the tutorial.
We need a clear process for where/how to edit the tutorial(s) as new versions
of solr come out and cahnges are made that mandate corisponding hanges to the
tutorial. this process _should_ also account for things like having multiple
versions of the tutorial live at one time (ie: at some point in the future,
we'll certainly need to host the 5.13 tutorial if that's the current
stable release, but we'll also want to host the tutorial for 6.0-BETA so
that people can try it out)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266584#comment-14266584 ] Hoss Man commented on SOLR-6871: bq. ... folks making these changes can't edit the currently live quickstart.html file because it, by design, is suppose to be reflecting what happens if folks are trying out the examples in the current release (4.10.2) branching the website might be a way of addressing this type of edits not ready to be live but wouldn't help with the larger issue of having 2 versions of the tutorial live for users at the same time during periods when we are supporting multiple versions: ie: having a way for people to find the 4.10 quickstart content right after 5.0 is released -- similar to how the live site's tutorial.html looked when 4.0 came out... https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/tutorial.mdtext?revision=1436785view=markuppathrev=1638603 ...i know there has also been talk in other issues about wanting to include multiple tutorials beyond the quickstart (SOLR-6078, SOLR-6748, SOLR-6080, SOLR-6079, etc...) so all of those will have the same versioning issues as the current quickstart content. Need a process for updating maintaining the new quickstart tutorial (and any other tutorials added to the website) Key: SOLR-6871 URL: https://issues.apache.org/jira/browse/SOLR-6871 Project: Solr Issue Type: Task Reporter: Hoss Man Priority: Blocker Fix For: 5.0 Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only a simple landing page that then linked people to the versioned tutorial for the most recent release -- or more specificly: the most recent release*s* (plural) when we were releasing off of multiple branches (ie: links to both the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) The old tutorial content lived along side the solr code, and was automatically branched, tagged released along with Solr. When committing any changes to Solr code (or post.jar code, or the sample data, or the sample configs, etc..) you could also commit changes to the tutorial at th same time and be confident that it was clear what version of solr that tutorial went along with. As part of SOLR-6058, it seems that there was a concensus to move to a keeping tutorial content on the website, where it can be integrated directly in with other site content/navigation, and use the same look and feel. I have no objection to this in principle -- but as a result of this choice, there are outstanding issues regarding how devs should go about maintaining this doc as changes are made to solr the solr examples used in the tutorial. We need a clear process for where/how to edit the tutorial(s) as new versions of solr come out and cahnges are made that mandate corisponding hanges to the tutorial. this process _should_ also account for things like having multiple versions of the tutorial live at one time (ie: at some point in the future, we'll certainly need to host the 5.13 tutorial if that's the current stable release, but we'll also want to host the tutorial for 6.0-BETA so that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6871) Need a process for updating maintaining the new quickstart tutorial (and any other tutorials added to the website)
[ https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254412#comment-14254412 ] Hoss Man commented on SOLR-6871: As a concrete example of why a process like this is crucial: there are a lot of changes going on righ now with bin/solr and what exactly happens when you run when bin/solr -e foo -- and there is talk of adding a bin/post as well ... all of these things affect the quickstart tutorial, but folks making these changes can't edit the currently live quickstart.html file because it, by design, is suppose to be reflecting what happens if folks are trying out the examples in the current release (4.10.2) Need a process for updating maintaining the new quickstart tutorial (and any other tutorials added to the website) Key: SOLR-6871 URL: https://issues.apache.org/jira/browse/SOLR-6871 Project: Solr Issue Type: Task Reporter: Hoss Man Priority: Blocker Fix For: 5.0 Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only a simple landing page that then linked people to the versioned tutorial for the most recent release -- or more specificly: the most recent release*s* (plural) when we were releasing off of multiple branches (ie: links to both the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out) The old tutorial content lived along side the solr code, and was automatically branched, tagged released along with Solr. When committing any changes to Solr code (or post.jar code, or the sample data, or the sample configs, etc..) you could also commit changes to the tutorial at th same time and be confident that it was clear what version of solr that tutorial went along with. As part of SOLR-6058, it seems that there was a concensus to move to a keeping tutorial content on the website, where it can be integrated directly in with other site content/navigation, and use the same look and feel. I have no objection to this in principle -- but as a result of this choice, there are outstanding issues regarding how devs should go about maintaining this doc as changes are made to solr the solr examples used in the tutorial. We need a clear process for where/how to edit the tutorial(s) as new versions of solr come out and cahnges are made that mandate corisponding hanges to the tutorial. this process _should_ also account for things like having multiple versions of the tutorial live at one time (ie: at some point in the future, we'll certainly need to host the 5.13 tutorial if that's the current stable release, but we'll also want to host the tutorial for 6.0-BETA so that people can try it out) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
