lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shannon Deminick <shan...@umbraco.dk>
Subject Re: Streamlining website, docs & getting started
Date Fri, 01 Jun 2018 01:22:21 GMT
OK cool, thanks for the info.

IMO having the site powered by markdown files in Git / GitHub makes the
content much easier to manage and more easily allows contribution via PRs.
There's only 5 pages making up the site currently
https://lucenenet.apache.org along with maybe a few still relevant articles
from the wiki so seems it could be pretty simple to manage with the
gitpubsub option. We can use any static site generator for this and the
output is committed/pushed to an "asf-site" branch of the repo which is
hosted. Since most file's wont change the git commit delta to this branch
would generally remain very small.

The docs site is a static site generated with docfx and doesn't need any
server side technology. I've pushed the current state of the docs site to a
temp azure website so people can see it:
https://lucenenetdocs.azurewebsites.net/ . There's some tweaks that still
need to be done but overall it's OK, the discussion about it is here
https://github.com/apache/lucenenet/pull/206

I'd be happy to put together a POC for the main website using docfx since
that's what already being used for the docs generation. Of course design,
etc.. can come later (i'm no designer ;)



On Wed, May 30, 2018 at 5:29 PM Stefan Bodewig <bodewig@apache.org> wrote:

> On 2018-05-30, Shannon Deminick wrote:
>
> > I mentioned that I would like to get the current state of the website,
> > documentation, getting started guide, etc... into a more usable state
> which
> > would help promote getting more contributors to the project. The current
> > 4.8 docs project based on docfx is pretty far and can be easily updated.
>
> Great.
>
> > I'd love to get the current website https://lucenenet.apache.org content
> > converted to this new format where it makes sense and I'm happy to do all
> > of the copy/pasting/formatting, etc...
>
> Please not there are a few "branding" policies an *.apache.org wesite
> has to adhere to, see http://www.apache.org/foundation/marks/pmcs . TBH
> I don't believe the current site is matching all requirements :-)
>
> > Before I start, does anyone object to me doing this?
>
> I'm not sure I understand the technical requirements the solution you
> are working on will impose on the website. We may need to involve infra
> if we need more than static pages in the end.
>
> > Also some questions:
>
> >    - The wiki is based on confluence:
> >    https://cwiki.apache.org/confluence/display/LUCENENET/ Can we remove
> >    this? A lot of this info is duplicated in the docs and it seems like
> >    updated markdown files in the repo would be easier to contribute to
> than
> >    this other system.
>
> Sure, we can turn off the Wiki if we no longer see any value in it.
>
> >    - Can i get access to the markdown source for this to make it easier
> to
> >    port over?
>
> I don't believe the Confluence installation is using markdown at all.
>
> >    - Where/how is the site https://lucenenet.apache.org hosted?
>
> Run on ASF infrastructure operated by our infra team.
>
> >    - How is it deployed? (i.e. FTP, etc..?)
>
> In general there are three options of hosting a *.apache.org website,
> see http://www.apache.org/dev/project-site.html .
>
> We currently use the Apache CMS which at one point in time was the
> recommended approach but no longer is. Actually the CMS uses svnpubsub
> under the covers together with a Buildbot run job that creates static
> pages from a bunch of templates. The sources for the site can be found
> at http://svn.apache.org/repos/asf/lucene.net/site/trunk/
>
> We are free to switch from CMS to any of the alternative approaches.
>
> I haven't got any first hand experience with gitpubsub but do know
> svnpubsub as something robust. I've heard gitpubsub tends to get into
> trouble with bigger changesets, so we may need to tweak the generated
> content to not contain last modified timestamps and things like that.
>
> Stefan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message