+1. That all sounds good to me. Excited to see some streamlining here. On Fri, Sep 20, 2019 at 3:46 PM Cassandra Targett <casstarg...@gmail.com> wrote: > > 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
