[Scipy-organizers] twist on github PR approach: treating gh-pages as master

[Kelsey Jordahl]

James,

I love the idea of "continuous publication".  You also have the possibility
of meaningful git tags (e.g. "submitted", "revised", etc.) to have a record
of certain states.

One problem with the idea of pushing everything directly to the gh-pages
branch, though, is that you still need a build step.  I don't think you can
(or want to) require that every author pushes the PDF, etc., along with any
source changes.  But there are ways to automate that build.  Indeed, there
was a web app to build the PDFs last year:
https://stefan.pythonanywhere.com.  I don't know of a system to
automatically push back to the gh-pages
branch, though it must exist.  The biggest example of a dynamic docoment
build system is probably readthedocs.org: you can hook that up to a GitHub
repo (or other source) and have it build the sphinx docs automatically.  I
don't know if sphinx itself is flexible to do the full proceedings build
including PDFs, but I suspect not (easily).

Kelsey



On Thu, Oct 31, 2013 at 5:24 PM, Andy Ray Terrel <andy.terrel at gmail.com>wrote:

> Well I'm fine with building a script that grabs the github source and
> publishes it on conference.scipy.org.  But we need to create a index
> website and build some providence for things to persist over time.
>
> The only thing I don't like about scipy.github.io/scipy_proceedings is
> that it isn't as stable as conference.scipy.org/proceedings/<year>
> (meaning we can't ever move to a new service with the same url if
> github pages stops).
>
> James, any help in this area would be greatly appreciated. I haven't
> had time to debug the scripts that are there.
>
> -- Andy
>
> On Thu, Oct 31, 2013 at 2:19 PM, James Bergstra
> <james.bergstra at gmail.com> wrote:
> > New to the list: hi people!
> >
> > In follow up to the other thread (Publication and review in SciPy) I
> wanted
> > to suggest a technical twist that would address *part* of the difficulty
> > getting publications out.
> >
> > The github PR system is great, but one trouble with it is that it doesn't
> > go far enough along the path to publication. Namely, merging things to
> > master doesn't actually publish them in the conventional sense of the
> word.
> >
> > However, Github runs Jeckyll-based webpage rendering services so that
> > individuals and organizations can host things at e.g.
> >
> > http://scipy.github.io/scipy_proceedings
> >
> > by pushing to gh-pages branch instead of master or master2013 or
> whatever.
> >
> > PRs should essentially be operating on that branch, rather than master.
> PRs
> > should include a file in the _posts subdirectory, and put supplementary
> > data (like e.g. the paper source and built PDF) in some other folder that
> > the webserver can access. That way, when the chair/admin signs off and
> > merges a PR (a paper) then it's DONE. The website served by github using
> > Jeckyll is immediately and automatically updated with a new post about
> the
> > paper, that post has links to whatever the author wanted: a PDF, a demo,
> > link to slides, source, etc... in short, it is PUBLISHED, and no one has
> to
> > come back and change anything later.
> >
> > Thoughts?
> >
> > - James
> > _______________________________________________
> > Scipy-organizers mailing list
> > Scipy-organizers at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-organizers
> _______________________________________________
> Scipy-organizers mailing list
> Scipy-organizers at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-organizers
>



-- 
Kelsey Jordahl, Ph.D.
Scientific software developer
Enthought, Inc.
750 Third Avenue (9th floor),
New York, NY 10017
kjordahl at enthought.com
1-973-996-8401
http://www.enthought.com