Silly things: *) should there be LICENCE on the Github repo if you want people to play/experiment/contribute ideas? *) This part is future, right? "Custom Java tooling will be used to process the .adoc file metadata to build up navigation data files" I can't find it in the repo, but maybe I am confused.
*) Blue sky idea: We should generate Solr index from the Asciidoc file as well and offer HTML version of the manual bundled with custom Solr index as a demo collection. Not as part of Solr, but somewhere else (where). *) Because "How will we provide search? Recommend probably indexing generated HTML pages. Could use bin/post from Solr to recurse over the HTML files and index them. In this case, we will need to figure out where to host Solr." - this is slightly embarrassing.... Regards, Alex. ---- http://www.solr-start.com/ - Resources for Solr users, new and experienced On 13 March 2017 at 16:41, Cassandra Targett <[email protected]> wrote: > It's been a while, but I (with Hoss' assistance) have been doing some > work on the proposal I made last summer to move the Ref Guide off of > Confluence. In my opinion, we're really close to being ready to make > this move, and I'd like to make it before Solr 7, and maybe even by > 6.5 (partially, at least; see below). > > Here's where I think we are at, and next steps I'd like to take: > > 1) We have reorganized the project to reflect how it can look when > integrated with Lucene/Solr source tree (link below). > > The project now has 2 top-level directories, "confluence-export", > which contains tools for conversion out of Confluence, and > "solr-ref-guide" for source content, tools and build output of the > current Ref Guide. > > Feedback on this structure is welcome. > > 2) We need to decide on our policy for branches. I recall there was > valid concern about the process around this when I first proposed the > change. I'd like to iron that out as soon as we can since that will be > a key part of our new process. > > From our discussion last summer, there are 2 potential approaches: > > a) Make all changes in 'master' (trunk) and backport to branches for > releasing the content. We'd need to merge "backward" into upcoming > release branch. > b) Make all changes in branch_6x (or branch_7x, etc.) and only move > things to master when they are only applicable to unreleased next > major version. We'd merge 6x "forward" when it's time for next major > version. > > There might be other ideas also - we should explore them and come to a > consensus. > > * To move forward on #1 and #2 here, I'll create a JIRA issue for this > effort (finally), and then create a branch in the lucene-solr repo > named after the JIRA issue and move the project from the current > location to the new branch. Then I'll file sub-tasks for the remaining > work and decisions (such as branching, conversion, publication > processes, where it lives, etc). > > 3) I'd like to see if we can publish the 6.5 Solr Ref Guide PDF with > this new approach. This would require converting all the content out > of Confluence, but it would only require that we get the PDF-relevant > parts of the process finalized in the next couple of weeks.The entire > publication process would remain the same; however, the editing > experience for new content would be radically different so that may be > too substantial an obstacle. > > I know it's an ambitious idea, and could leave us in a half-way state > with the PDF published from one source and online docs in another, but > it may be worth trying in order to get moving on this front and iron > out remaining issues before 7.0. > > I appreciate in advance your feedback. As a reminder, you can see the > demo site/PDF and the project repo at: > > http://people.apache.org/~ctargett/RefGuidePOC/ > https://github.com/ctargett/refguide-asciidoc-poc > > > Thanks, > Cassandra > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
