[yt-dev] Best place for planning documentation?

[Casey W. Stark]

Does anyone happen to know how numpy/scipy handle this? It looks like they
autodoc as well and must have coordinated this in the past.

- Casey


On Mon, Nov 19, 2012 at 8:16 AM, Britton Smith <brittonsmith at gmail.com>wrote:

> Maybe the simplest solution for now is for more people to have privileges
> to rebuild the docs.  Then, it can be the responsibility of the last person
> to push a change to do it.  Every other solution seems like more work than
> anyone has time to put in right now.
>
> Britton
>
>
>
> On Mon, Nov 19, 2012 at 11:12 AM, Matthew Turk <matthewturk at gmail.com>wrote:
>
>> On Mon, Nov 19, 2012 at 11:09 AM, Stephen Skory <s at skory.us> wrote:
>> >> Confluence is the slickest, and the Wiki in the past has gone out of
>> >> date relatively quickly.  Any strong feelings on which I should start
>> >> using as a dumping ground for information about 3.0 vs 2.x?
>> >
>> > I hate to inflict pain, but I really think that sphinx/yt-doc is the
>> > way to go. I think having diverging documentation trees is going to
>> > cause more pain in the long run. Is there no way to automate the
>> > (re)building of the sphinx docs (not the default public ones, of
>> > course)?
>>
>> The problem with rebuilding the sphinx documentation is that since it
>> relies on introspection of a running yt session to do the automodule /
>> autofunction documentation, we can't use solutions like ReadTheDocs.
>> In principle, we could use ShiningPanda, but since it takes ten to
>> fifteen minutes to build yt-doc, this could run out of credits
>> quickly.  If you wanted to take on the project of migrating our entire
>> hosting system to Amazon S3, we could probably make it work.  As it
>> stands, the only non-dynamic content yt has is the pastebin.  That
>> would have to stay at dreamhost for now, but we could move the main
>> page, the docs, and so on, over to S3.
>>
>> So I think yes, it could be done, but I'm not willing to do it; I'm
>> more than happy to turn this over to someone else, though.  And it's
>> not clear to me that it would meet the need of an evolving design
>> specification where multiple contributors commented; it would only
>> meet the need of a single designer, which I don't think is necessarily
>> the right solution.
>>
>> -Matt
>>
>> >
>> > --
>> > Stephen Skory
>> > s at skory.us
>> > http://stephenskory.com/
>> > 510.621.3687 (google voice)
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20121119/18398ca8/attachment.html>