[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
