From: Steve J. <st...@st...> - 2014-05-20 03:25:07
|
Continuous integration is now working. Whenever you submit a pull request, Travis CI runs the tests and tells GitHub if they pass. Example: https://github.com/irskep/docutils/pull/1 https://www.dropbox.com/s/ezj4ut8qezio5sw/Screenshot%202014-05-19%2020.22.08.png https://travis-ci.org/irskep/docutils/builds/25569594 On Mon, May 19, 2014, at 10:31 AM, Steve Johnson wrote: > Hello everyone, > > I am a friendly developer who recently crossed the threshold from "I > wish docutils was better" to "I want to help improve docutils." > Specifically, I want to give the docs a major update (with Sphinx, which > you all seem to agree is fine) and see if I can convince you to move the > project to GitHub. Plus some other stuff, but that can come later. > > It seems like most people on the list would welcome such a move but want > someone else to do all the work. So, I'll do all the work! > > One thing first: I really appreciate all the work you guys have done > over the years. You are a big part of why the Python documentation > ecosystem is so good. So thank you. > > Now, here's my plan... > > PHASE 1: TO THE GITHUB > > 1. Using the git fork set up by Kirill Smelkov, which contains all repo > history AFAIK, clone a new git repository on GitHub. I've already done > this under my own account (github.com/irskep/docutils), but I think we > should have an organization (github.com/docutils/docutils being the main > repo). > > 2. Give push and admin privileges to contributors and maintainers on the > GitHub site. Start making all changes via pull request. People who could > commit on SVN can merge pull requests on GitHub. > > 3. Set up Travis CI to do continuous integration on all pull requests > (started, but not quite working yet). > > 4. Split trunk/sandbox/ and trunk/prest/ into separate repositories; > move trunk/docutils/docutils/ to just trunk/docutils/. This will be a > history-preserving move. > > Is there a reason not to do this? With git branching it's not necessary > to have a 'random unpackaged user stuff' folder, and the Perl project > should probably have its own repo anyway. It's common for projects to > have multiple repos under their GitHub org, and it tends to be easier to > find things that way. > > At this point we should be totally moved to GitHub. If for some reason > there are still commits coming into the SVN repo, we can just send > ourselves a pull request from the SVN mirror branch, which Kirill has > already set up. > > This whole phase could take less than a day. Did I miss any important > steps? > > PHASE 2: ALL THE DOCS > > 1. Start working on a Sphinx docs branch. I have a lot of gripes with > the current site, and I'm hoping to have the chance to fix them all. (I > will elaborate later.) Publish this branch to readthedocs.org as a way > to check progress; this will not become the official URL. > > 2. Do lots more work. Try to preserve URLs; should be possible to > preserve most. > > 3. Deploy new docs at docutils.sourceforge.net. > > 4. Buy docutils.org so it stops mattering where docs are hosted. > Eventually host on readthedocs.org or pythonhosted.org with convenient > redirects from the old site. > > Now you may be asking yourself... > > STEVE WHO ARE YOU AND WHY SHOULD WE LET YOU DO THIS > > I am a 25 year old programmer with a weird passion for documentation. To > help convince you that I am capable of following through, here are some > projects whose code and docs I wrote 40-100% of: > > mrjob: http://mrjob.readthedocs.org/en/latest/ > Literally Canvas: http://literallycanvas.com/ > zhang-shasha: http://zhang-shasha.readthedocs.org/en/latest/ > sphinx-better-theme: > http://sphinx-better-theme.readthedocs.org/en/latest/ (yeah a little > pretentious, what can I say) > > I should also mention Pillow, whose docs I painstakingly converted from > the old PyDoc format: http://pillow.readthedocs.org/en/latest/ > > I really prefer to work in git, or at least not SVN. I've used both and > the DVCS workflow is better for both individuals and communities. So I'm > much more likely to invest time if the project moves away from SVN. I > imagine lots of people (potential contributors) feel the same way. > > To be a little more blunt: this project looks pretty stagnant, and > making it more welcoming to contributors could give it new life. People > didn't migrate to git en masse just because because it was new and > shiny; it legitimately has positive effects on open source projects. > > Well, that was quite a lot of typing. What do you say? > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform > available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Docutils-develop mailing list > Doc...@li... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. |