On Mon, Aug 22, 2016 at 9:46 AM Jan Høydahl wrote:
> Pull requests for docs is a great plus so more people can contribute. The
> online version-specific docs can then have a link below each page
> encouraging people to contribute through PR to version-branch or by comment
Pull requests for docs is a great plus so more people can contribute. The
online version-specific docs can then have a link below each page encouraging
people to contribute through PR to version-branch or by comment system.
An issue with only maintaining the next-release branch is that docs on
Thanks for taking time for looking at these options Casandra. I specially
agree with the third of the painful points you mentioned, the fact that we
can't maintain online documentation for different versions. I like that we
have a released PDF version for every minor version, but 99.9% of the time
On 8/19/2016 11:23 AM, Chris Hostetter wrote:
> To be very clear, my point was that by moving out of confluence and to an
> asciidoc based system kept in git, we know have the *choice* to
> maintain/backport documentation for multiple versions, and an easy way to
> backport changes.
>
> This is
: I am not against having multiple documentation branches -- I am *for*
: that. I am against emulating our current source code practice of needing
: to commit twice (two branches) for most things. I think that should be the
: exception, not the rule. Only during a new dot-zero release would we
I am not against having multiple documentation branches -- I am *for*
that. I am against emulating our current source code practice of needing
to commit twice (two branches) for most things. I think that should be the
exception, not the rule. Only during a new dot-zero release would we be
On Thu, Aug 18, 2016 at 10:38 PM, Erick Erickson
wrote:
>
> The other question I have is how to find the file I want to edit. I'm
> taking it on faith that there's a way to find a particular asciidoc
> file without resorting to a recursive grep, but if not I can cope with
On Thu, Aug 18, 2016 at 8:48 PM, David Smiley wrote:
> Ugh! I think it's a PITA that we basically always back-port all commits to
> another branch, and the prospect of having to do this to documentation as
> well will add a large barrier to editing the docs. I propose
On 19 August 2016 at 13:38, Erick Erickson wrote:
> Does GitHub have any edit-in-place magic? Kind of seems contrary to
> the spirit of Git though
Yes, it does. It even clones the repo and does pull request afterwards
if you don't have access directly.
Regards,
Does GitHub have any edit-in-place magic? Kind of seems contrary to
the spirit of Git though
The other question I have is how to find the file I want to edit. I'm
taking it on faith that there's a way to find a particular asciidoc
file without resorting to a recursive grep, but if not I can
Everything here sounds great (+1 from me) but...
On Thu, Aug 18, 2016 at 7:30 PM Chris Hostetter
wrote:
> But the other nice thing is that this will make it easy to
> maintain "branches" of the ref guide in git, and publish those with
> releases as well -- so you can
: Is there anyway to maintain inbound links to confluence pages with the new
: system? I'm just thinking about all the user group questions, stackoverflow
: Qs, and the like that link to cwiki pages.
:
: Is it possible to setup the right redirects for cwiki pages into the new
: system?
That
Is there anyway to maintain inbound links to confluence pages with the new
system? I'm just thinking about all the user group questions, stackoverflow
Qs, and the like that link to cwiki pages.
Is it possible to setup the right redirects for cwiki pages into the new
system?
Doug
On Thu, Aug 18,
: First, I'm not about to second-guess this. I wouldn't like to lose the
: ability to download a full doc to search offline, but it looks like
: this solution allows that since there is a PDF version after all.
I also like being able to officially "release" the guide, and doing so via
PDF will
First, I'm not about to second-guess this. I wouldn't like to lose the
ability to download a full doc to search offline, but it looks like
this solution allows that since there is a PDF version after all.
As you know, every time I try to edit he CWiki I come whimpering to
you or Hoss. Sounds
+1 with Asciidoc and moving off Confluence and into anything that
allows to generate stable-version HTML export. Offline builds that can
also be used for tooling (e.g. for search index generation) is also
great. I had a quick look at indexing Confluence export and it is a
confusing mess (though I
I was thinking about Asciidoc as well the other day, I love it!
+1
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 18. aug. 2016 kl. 21.45 skrev Cassandra Targett :
>
> When the Solr Ref Guide was donated back in 2013, we decided to host
> it
When the Solr Ref Guide was donated back in 2013, we decided to host
it in Confluence (cwiki) because the source had originated from a
Confluence system, and it made the handoff easier. Today, though, it
has become really painful to maintain there.[1]
I'll suggest that it's time to move from
18 matches
Mail list logo