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

[James Bergstra]

Good points Kelsey, you're right there are various tools for this sort of
thing.

For my part, I'm suspicious of such automatic build systems for latex,
because they seem annoying to use, and fragile to support. Arxiv is
annoying to use for this reason. I actually *was* suggesting that people
put the built PDF in their git project, so it looks *just right* and goes
straight into the master copy without worrying about if the upstream server
has the right latex version & packages installed. My sense is that papers
are typically not that big. And they're never necessarily big. If everyone
in the 2012 conference submitted 3 revisions of the PDF copy that would be
still only be like 100MB.  Anyway, the person merging to master should
collapse the history to remove duplicate binary copies.

I'm not going to argue against using any one of the build tools you
suggested, but I did want to make sure that submitting PDFs is considered
as an option.

There is also the possibility of using an e.g. git-annex server to handle
binary blobs. In principle this could be elegant, but I'm not crystal clear
on how it would work... github conveniently handles authentication.



On Thu, Oct 31, 2013 at 6:09 PM, Kelsey Jordahl <kjordahl at enthought.com>wrote:

> 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
>