Thanks everyone, by the way, for the encouragement and feedback here. For next steps, how do folks feel about making the change to stop voting on the PDF *now*? Or, I guess, retroactively for 8.2 since that’s not out yet. I could push the HTML and make a PDF but announce to the list that from 8.2 forward we consider the HTML the main Ref Guide and the PDF is “for convenience” (and explain the thinking behind it).
If we want a VOTE on this policy change, I can do that - I feel like we have consensus without it, but we could be more formal about it if folks prefer. For 8.3 we'll see what we can get automated there, but if it’s not ready I’ll just do it manually once the RC is out. I’ll file a Jira for some of the changes I’ll make to the docs for the process, etc., and another one for automation ideas. Cassandra On Sep 19, 2019, 2:53 PM -0500, Noble Paul <noble.p...@gmail.com>, wrote: > First of all a big thanks to Cassandra to help coordinate and build > our ref guide to make it professional. It really used to be pathetic > before you took over > > . Yes we need to avoid "creating work" . There should be no need for a > ref guide release. > > +1 for your plan > > On Thu, Sep 19, 2019 at 11:57 PM Cassandra Targett > <casstarg...@gmail.com> wrote: > > > > The pages do already have a “Site last generated” date on them at the > > bottom. It’s specifically worded that way for a reason. > > > > We actually wanted the date the .adoc file was last updated to be in the > > footer too, but the problem has always been that a static site generator > > always regenerates all pages every time - so every single page, edited or > > not, always has the same exact date on it. > > > > And, our build works by copying everything under `solr/solr-ref-guide/src` > > to `solr/build`, so every file really has a create date and last updated > > date that are always the date you do the build. Basically, the files you > > see and work with are not actually the same files that get built - we build > > from copies that are made at build-time. > > > > (That’s all why it says “Site last generated” instead of “Last updated”.) > > > > I’m not saying there’s no way to add a last updated date for the underlying > > file, it’s just not obvious how to do it so we skipped it. > > > > No problem, though, adding a link to Github - that’s actually kind of a > > different thing and I’m pretty sure we could do that right now. > > > > Cassandra > > On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta <ans...@anshumgupta.net>, > > wrote: > > > > I agree that we should be able to fix mistakes, my only suggestion was that > > those mistakes not be non-trivial. But the more I think about it, the more > > I feel convinced about just publishing the updates - however, having a time > > stamp on when the guide was last updated would be nice to have. Anything > > else would require much more effort and I'm not sure it's worth it. > > > > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter <hossman_luc...@fucit.org> > > wrote: > > > > > > > > > : > However Anshum does make a good point that users wouldn't know when > > > : the pages have changed. I think it would be great to have a link on each > > > : ref-guide page that shows the last modified date and links to the > > > : history of that page in github > > > > > > : Perhaps we could instead provide a single HTML page or HTML table as > > > : part of or alongside each guide, showing all commits touching the guide > > > : on that branch after the release. Could probably be baked in as part of > > > : the release script. Using the release date or git hash for the release, > > > > > > Yeah, there are a lot of options we could pursue for generating a > > > "changes" list as part of an automated build process -- but i would > > > consider this idea a "nice to have" feature that shouldn't block moving > > > forward. > > > > > > Given 2 options, I would much rather: > > > a) have the ability to quickly/easily "fix" mistakes/ommisions in > > > "official X.y ref-guide" on our site and have it automatically republish, > > > w/o it being immediately obvious to users that a page may have changed > > > between yesterday and today. > > > ... over ... > > > b) *NOT* being able to re-publish at all just for the sake of users > > > knowing that the (incorrect) content they are reading is consistent > > > between yesterday and today. > > > > > > > > > -Hoss > > > http://www.lucidworks.com/ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > -- > > Anshum Gupta > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
