docutils-develop — For developer discussions of the implementation.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(27) |
Jun
(22) |
Jul
(72) |
Aug
(82) |
Sep
(86) |
Oct
(138) |
Nov
(100) |
Dec
(62) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(122) |
Feb
(147) |
Mar
(92) |
Apr
(82) |
May
(101) |
Jun
(153) |
Jul
(37) |
Aug
(34) |
Sep
(46) |
Oct
(46) |
Nov
(6) |
Dec
(38) |
| 2004 |
Jan
(64) |
Feb
(81) |
Mar
(36) |
Apr
(194) |
May
(329) |
Jun
(272) |
Jul
(68) |
Aug
(74) |
Sep
(150) |
Oct
(57) |
Nov
(62) |
Dec
(63) |
| 2005 |
Jan
(78) |
Feb
(30) |
Mar
(137) |
Apr
(78) |
May
(54) |
Jun
(122) |
Jul
(72) |
Aug
(110) |
Sep
(80) |
Oct
(75) |
Nov
(125) |
Dec
(79) |
| 2006 |
Jan
(100) |
Feb
(15) |
Mar
(41) |
Apr
(67) |
May
(30) |
Jun
(11) |
Jul
(14) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(11) |
Dec
(15) |
| 2007 |
Jan
(17) |
Feb
(16) |
Mar
(35) |
Apr
(21) |
May
(33) |
Jun
(50) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2008 |
Jan
(14) |
Feb
(20) |
Mar
(35) |
Apr
(9) |
May
(57) |
Jun
(21) |
Jul
(42) |
Aug
(4) |
Sep
(13) |
Oct
(76) |
Nov
(40) |
Dec
(55) |
| 2009 |
Jan
(26) |
Feb
(15) |
Mar
(3) |
Apr
(67) |
May
(32) |
Jun
(39) |
Jul
(59) |
Aug
(31) |
Sep
(59) |
Oct
(64) |
Nov
(21) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(116) |
Apr
(33) |
May
(6) |
Jun
(28) |
Jul
(21) |
Aug
(23) |
Sep
(146) |
Oct
(70) |
Nov
(31) |
Dec
(57) |
| 2011 |
Jan
(33) |
Feb
(22) |
Mar
(11) |
Apr
(21) |
May
(51) |
Jun
(47) |
Jul
(35) |
Aug
(26) |
Sep
(25) |
Oct
(34) |
Nov
(61) |
Dec
(51) |
| 2012 |
Jan
(75) |
Feb
(31) |
Mar
(26) |
Apr
(16) |
May
(24) |
Jun
(24) |
Jul
(31) |
Aug
(46) |
Sep
(36) |
Oct
(28) |
Nov
(37) |
Dec
(21) |
| 2013 |
Jan
(16) |
Feb
(56) |
Mar
(31) |
Apr
(44) |
May
(45) |
Jun
(29) |
Jul
(38) |
Aug
(18) |
Sep
(12) |
Oct
(16) |
Nov
(21) |
Dec
(11) |
| 2014 |
Jan
(13) |
Feb
(14) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <khedron@us...> - 2014-03-10 16:11:32
|
|
From: darkfeline <darkfeline@us...> - 2014-02-28 21:58:45
|
|
From: darkfeline <darkfeline@us...> - 2014-02-28 21:53:22
|
|
From: Stefan Merten <smerten@oe...> - 2014-02-28 17:48:02
|
Hi! 3 hours ago Guenter Milde wrote: >> ... I was looking for a JavaScript editor really using WYSIWIG but >> writing reStructuredText in the backend. That way you could include it >> in a wiki like MoinMoin and have a web based WYSIWIG editor for nice >> reStructuredText wiki pages. > > I don't know any such thing. I looked around a bit and found CKEditor (http://ckeditor.com/) and TinyMCE (http://www.tinymce.com/) which seem to be the most popular such WYSIWYG editors. Both have a plugin system - though CKEditor seems to have more and more different plugins so far. I looked around in CKEditor a bit. There might be enough hooks to implement a reST writer but there must be someone who does it... Grüße Stefan |
|
From: Günter Milde <milde@us...> - 2014-02-28 14:46:24
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:46:23
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:41:32
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:41:32
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:28:54
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:28:54
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:15:13
|
|
From: Günter Milde <milde@us...> - 2014-02-28 14:15:12
|
|
From: Guenter Milde <milde@us...> - 2014-02-28 11:05:17
|
Dear Stefan, On 2014-02-25, Stefan Merten wrote: > 2 days ago Stefan Merten wrote: >> Does anyone know of a JavaScript WYSIWYG editor producing reST? That >> would be something that would be really great to have. > Two persons replied privately. They pointed me to two solutions. I'd > like to share them here. May be they can be included in the respective > documentation pages? > Notex (https://notex.ch/) uses typical buttons for styles and using a > button transforms the content to reStructuredText syntax. This is > interesting but not WYSIWIG. May be good enough for many cases, > however. > Then there is http://rst.ninjs.org/. I guess it's an application of > https://rubygems.org/gems/ninjs. To me it seems more like an > experiment. At the very least it needs much more functionality. In the > left pane you can enter text using typical formatting buttons. In the > right pane it is shown as rendered reStructuredText - probably calling > a reStructuredText transformer. I added "rsted" (the second link) to our "Links" page "links.txt". Notex was already there. > ... I was looking for a JavaScript editor really using WYSIWIG but > writing reStructuredText in the backend. That way you could include it > in a wiki like MoinMoin and have a web based WYSIWIG editor for nice > reStructuredText wiki pages. I don't know any such thing. Günter |
|
From: Stefan Merten <smerten@oe...> - 2014-02-25 19:10:16
|
Hi! 2 days ago Stefan Merten wrote: > Does anyone know of a JavaScript WYSIWYG editor producing reST? That > would be something that would be really great to have. Two persons replied privately. They pointed me to two solutions. I'd like to share them here. May be they can be included in the respective documentation pages? Notex (https://notex.ch/) uses typical buttons for styles and using a button transforms the content to reStructuredText syntax. This is interesting but not WYSIWIG. May be good enough for many cases, however. Then there is http://rst.ninjs.org/. I guess it's an application of https://rubygems.org/gems/ninjs. To me it seems more like an experiment. At the very least it needs much more functionality. In the left pane you can enter text using typical formatting buttons. In the right pane it is shown as rendered reStructuredText - probably calling a reStructuredText transformer. Both tools seem interesting to learn reStructuredText syntax. However, ... > I looked around a bit and found CKEditor (http://ckeditor.com/) and > TinyMCE (http://www.tinymce.com/) which seem to be the most popular > such WYSIWYG editors. Both have a plugin system - though CKEditor > seems to have more and more different plugins so far. ... I was looking for a JavaScript editor really using WYSIWIG but writing reStructuredText in the backend. That way you could include it in a wiki like MoinMoin and have a web based WYSIWIG editor for nice reStructuredText wiki pages. Grüße Stefan |
|
From: Stefan Merten <smerten@oe...> - 2014-02-23 17:40:16
|
Hi! Does anyone know of a JavaScript WYSIWYG editor producing reST? That would be something that would be really great to have. I looked around a bit and found CKEditor (http://ckeditor.com/) and TinyMCE (http://www.tinymce.com/) which seem to be the most popular such WYSIWYG editors. Both have a plugin system - though CKEditor seems to have more and more different plugins so far. Grüße Stefan |
|
From: Guenter Milde <milde@us...> - 2014-01-27 12:39:52
|
Dear Docutils friends, dear Tony,
thank you for speaking up. The impression of Docutils as a "ghost town" is
not completely out of the way. Most core developers have far less time to
spend on docutils nowadays than in the past and have a preference of keeping
it functional (works for me). The interesting development goes on at Sphinx
or other places. This may be a good thing (Docutils as the "rock solid" base
for other stuff) but may also be a sign of decay.
On 2014-01-21, Tony N wrote:
> I wanted to get a status report on where things stand with VCS and a home
> for docutils.
> To begin, I have a few issues with source forge:
...
> 4. The current work flow works. But, I don't think it's true. I think
> there are people who don't want to criticize, or people who just see
> docutils website and (sorry here) think it's a dead ghost town.
> That's my first impression when I see it. To people who used SF for
> a decade, this may not make sense, but this place honestly sucks. To
> other people who are newer to python, they may not be talking, but
> it scares them off or confuses them.
I see 3 distinct issues:
a) website
b) VC system
c) provider
to a) website
I agree that the website can be improved. My plan is to use Sphinx for
the Docutils documentation:
* the website should also be a showcase for Docutils and rSt but
Docutils is intended for stand-alone documents without proper support
for complete projects/sites.
* Sphinx is the most popular Docutils extension providing an advanced
documentation framework for more complex projects. As Sphinx builds on
Docutils, a Sphinx-built site is still a showcase for our project.
to b) VC system
> I have issues with subversion. Its positive is simplicity. On the other
> hand, it lacks many of the conveniences git has. It's actually nice to have
> a decentralized system. The workflow for branches is nice. It's fast. In
> 2014, I think it's safe to say many developers know how to use it.
I also prefer git over SVN. I would agree if someone would undertake the
move to a git-based repository, however it is not as high on my priority
list that I personally would like to put many time and effort in it. Many
of the advantages are also available via git-svn.
c) the provider
> I don't find the interface friendly. It's inconsistent. I am not up to
> date with it, because everyone else is using something else.
...
The conception of "everyone" varies widely. For me, github would mean one
more site to learn (to SF, BerliOS, repo.or.cz, ...)
But most important: SF is the home of Docutils for "ages".
Cool URIs don't change
-- Tim BL <http://www.w3.org/Provider/Style/URI.html>;
> I have a preference for github and git. I like their interface for browsing
> source, pull requests, issues. I think github's pull requests and issue
> system is very contributor friendly.
Docutils is a system with great emphasis on stability and overal
consistency. With all core developers short on spare time, we need a
developer-friendly system that makes dealing with proposals, patches and bug
reports easy for the developers to avoid building up a heap of unprocessed
issues.
For me, a better organized and navigable web site has priority over other
changes to the "PR".
Thanks,
Günter
|
|
From: David Goodger <goodger@py...> - 2014-01-24 16:40:55
|
On 23 January 2014 17:43, Leandro Lucarella <luca@...> wrote: > There is a social aspect of it, it might sound stupid, but I've seen > project multiply the number of contributions just by moving the project > to GitHub (git is great for the SCM part, but GitHub makes a huge > difference in terms of the social part). > > I agree for a project like docutils it might not sound very tempting, > but I think you might be surprised by the outcome of such a move. I wouldn't be surprised. GitHub seems to be where all the cool kids hang out these days, and there are lots of them. This doesn't change the fact that someone has to champion the change, plan the transition, and implement it. I'm not going to do it. Who is? Talk is cheap; actions speak louder than words. -- David Goodger <http://python.net/~goodger>; |
|
From: Purnank <purnank@gm...> - 2014-01-24 11:30:21
|
> > Hello up there. Just FYI: you already have Docutils Git mirror with all > the history, branches, tags and full sandbox here: > > http://repo.or.cz/w/docutils.git > > It's maybe not perfect, because SVN account names were not translated to > emails, but otherwise it works. > > Kirill > > > P.S. and making local changes to it and then publishing patches was, > indeed, a lot more convenient with Git. > > Just my 2коп. > > Couple of weeks back I tried to migrate code to Git. The history of snapshot is missing in this migration. But I have taken care to get the Names of authors and contributors in place. https://github.com/purnank/docutils-code-html5epub3 https://github.com/purnank/docutils_try1 -- Purnank |
|
From: Kirill Smelkov <kirr@mn...> - 2014-01-24 11:14:30
|
On Thu, Jan 23, 2014 at 09:24:53AM -0600, David Goodger wrote:
> There is definitely an advantage to a distributed VCS. Being able to
> commit, branch, roll back — experiment incrementally — on your local
> system, and only produce a patch or "pull request" once your changes
> are fully realized and polished, is a great tool. A distributed VCS
> allows developers to commit as often as they like without affecting
> other developers — it's "commit often" on steroids. I haven't used Git
> much in earnest, but I've had good results from Mercurial and Bazaar.
> I'm open to such a change, but I have no desire (let alone time) to
> implement the change myself. So my vote is +0.
>
> Maybe it's short-sighted but for me, the pain of making the switch to
> another VCS outweighs the benefit we'd see, at least in the short
> term. But I'm used to SVN and not doing much active development on
> Docutils these days. I don't see SVN as much of a pain point.
>
> The group of active developers and project "admins" has to make any
> such decision, but it requires a champion (or a group) who care enough
> to push through the group's inertia, convince the others, and
> implement the change. An absolute requirement, for me, is that such a
> change be complete. We can't lose any data or have to refer to the old
> system as an "archive". So all the SVN history, all branches, and the
> full sandbox need to be converted at the same time.
>
> My 2¢.
Hello up there. Just FYI: you already have Docutils Git mirror with all
the history, branches, tags and full sandbox here:
http://repo.or.cz/w/docutils.git
It's maybe not perfect, because SVN account names were not translated to
emails, but otherwise it works.
Kirill
P.S. and making local changes to it and then publishing patches was,
indeed, a lot more convenient with Git.
Just my 2коп.
> On 23 January 2014 02:21, engelbert gruber <engelbert.gruber@...> wrote:
> > hello,
> >
> > subversion does the job, so why change it .
> >
> > considering the premize "release often" translated for developers "commit
> > often" , distributed vcs are an excuse.
> > (considering that people check their facebook every 5 minutes, what is the
> > problem with a centralized vcs)
> >
> > daily vcs usage with svn is svn update, svn diff, svn commit, git doubls
> > this so where is the advancement ?
> >
> > cheers e
> >
> >
> >
> > On 21 January 2014 23:41, Tony N <railsdontscale@...> wrote:
> >>
> >> Greetings all,
> >>
> >> I wanted to get a status report on where things stand with VCS and a home
> >> for docutils.
> >>
> >> To begin, I have a few issues with source forge:
> >>
> >> I don't find the interface friendly. It's inconsistent. I am not up to
> >> date with it, because everyone else is using something else.
> >>
> >> The good things with source forge:
> >>
> >> 1. The good news is sourceforge may allow docutils to bind with
> >> advertisements, with DevShare, we can hook into setup.py and monetize
> >> docutils development. For more information, you can see
> >> http://sourceforge.net/blog/advertising-bundling-community-and-criticism/.
> >>
> >> 2. Also source forge benefits from being funded by Dice Holdings, Inc. You
> >> can read more about them at http://www.diceholdingsinc.com/. According to
> >> their front page, I see they announced as $50 million Stock Repurchase
> >> program. So while I'm ignorant of finance, we can get someone from numpy to
> >> confirm if fiscals are sound for 2014. SF could be around for a long time.
> >>
> >> 3. SVN is simple. Older versions have a folder in every sub-directory to
> >> maintain metadata. It has no upsides but it's cool when you get them tangled
> >> up.
> >>
> >> 4. The current work flow works. But, I don't think it's true. I think
> >> there are people who don't want to criticize, or people who just see
> >> docutils website and (sorry here) think it's a dead ghost town. That's my
> >> first impression when I see it. To people who used SF for a decade, this may
> >> not make sense, but this place honestly sucks. To other people who are newer
> >> to python, they may not be talking, but it scares them off or confuses them.
> >>
> >> I have issues with subversion. Its positive is simplicity. On the other
> >> hand, it lacks many of the conveniences git has. It's actually nice to have
> >> a decentralized system. The workflow for branches is nice. It's fast. In
> >> 2014, I think it's safe to say many developers know how to use it.
> >>
> >> Many python projects make their home on github. Flask, Werkzeug, Tornado,
> >> Requests. Cython. Pandas. Numpy. IPython.
> >>
> >> I have a preference for github and git. I like their interface for
> >> browsing source, pull requests, issues. I think github's pull requests and
> >> issue system is very contributor friendly.
> >>
> >> Even SQLAlchemy moved from bitbucket to github. Here is their rationale:
> >> http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/
> >>
> >> For the sake of articulating it, who makes the choice if docutils were to
> >> move to a new place? What is the current feeling around here?
|
|
From: Leandro Lucarella <luca@ll...> - 2014-01-24 00:06:47
|
David Goodger, el 23 de January a las 09:24 me escribiste: > There is definitely an advantage to a distributed VCS. Being able to > commit, branch, roll back — experiment incrementally — on your local > system, and only produce a patch or "pull request" once your changes > are fully realized and polished, is a great tool. A distributed VCS > allows developers to commit as often as they like without affecting > other developers — it's "commit often" on steroids. I haven't used Git > much in earnest, but I've had good results from Mercurial and Bazaar. > I'm open to such a change, but I have no desire (let alone time) to > implement the change myself. So my vote is +0. > > Maybe it's short-sighted but for me, the pain of making the switch to > another VCS outweighs the benefit we'd see, at least in the short > term. But I'm used to SVN and not doing much active development on > Docutils these days. I don't see SVN as much of a pain point. > > The group of active developers and project "admins" has to make any > such decision, but it requires a champion (or a group) who care enough > to push through the group's inertia, convince the others, and > implement the change. An absolute requirement, for me, is that such a > change be complete. We can't lose any data or have to refer to the old > system as an "archive". So all the SVN history, all branches, and the > full sandbox need to be converted at the same time. There is a social aspect of it, it might sound stupid, but I've seen project multiply the number of contributions just by moving the project to GitHub (git is great for the SCM part, but GitHub makes a huge difference in terms of the social part). I agree for a project like docutils it might not sound very tempting, but I think you might be surprised by the outcome of such a move. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Breathe, breathe in the air. Don't be afraid to care. Leave but don't leave me. Look around and choose your own ground. |
|
From: Stefan Merten <smerten@oe...> - 2014-01-23 21:23:31
|
Hi! Today engelbert gruber wrote: > subversion does the job, so why change it . +1 Grüße Stefan |
|
From: David Goodger <goodger@py...> - 2014-01-23 15:25:40
|
There is definitely an advantage to a distributed VCS. Being able to commit, branch, roll back — experiment incrementally — on your local system, and only produce a patch or "pull request" once your changes are fully realized and polished, is a great tool. A distributed VCS allows developers to commit as often as they like without affecting other developers — it's "commit often" on steroids. I haven't used Git much in earnest, but I've had good results from Mercurial and Bazaar. I'm open to such a change, but I have no desire (let alone time) to implement the change myself. So my vote is +0. Maybe it's short-sighted but for me, the pain of making the switch to another VCS outweighs the benefit we'd see, at least in the short term. But I'm used to SVN and not doing much active development on Docutils these days. I don't see SVN as much of a pain point. The group of active developers and project "admins" has to make any such decision, but it requires a champion (or a group) who care enough to push through the group's inertia, convince the others, and implement the change. An absolute requirement, for me, is that such a change be complete. We can't lose any data or have to refer to the old system as an "archive". So all the SVN history, all branches, and the full sandbox need to be converted at the same time. My 2¢. -- David Goodger <http://python.net/~goodger>; On 23 January 2014 02:21, engelbert gruber <engelbert.gruber@...> wrote: > hello, > > subversion does the job, so why change it . > > considering the premize "release often" translated for developers "commit > often" , distributed vcs are an excuse. > (considering that people check their facebook every 5 minutes, what is the > problem with a centralized vcs) > > daily vcs usage with svn is svn update, svn diff, svn commit, git doubls > this so where is the advancement ? > > cheers e > > > > On 21 January 2014 23:41, Tony N <railsdontscale@...> wrote: >> >> Greetings all, >> >> I wanted to get a status report on where things stand with VCS and a home >> for docutils. >> >> To begin, I have a few issues with source forge: >> >> I don't find the interface friendly. It's inconsistent. I am not up to >> date with it, because everyone else is using something else. >> >> The good things with source forge: >> >> 1. The good news is sourceforge may allow docutils to bind with >> advertisements, with DevShare, we can hook into setup.py and monetize >> docutils development. For more information, you can see >> http://sourceforge.net/blog/advertising-bundling-community-and-criticism/. >> >> 2. Also source forge benefits from being funded by Dice Holdings, Inc. You >> can read more about them at http://www.diceholdingsinc.com/. According to >> their front page, I see they announced as $50 million Stock Repurchase >> program. So while I'm ignorant of finance, we can get someone from numpy to >> confirm if fiscals are sound for 2014. SF could be around for a long time. >> >> 3. SVN is simple. Older versions have a folder in every sub-directory to >> maintain metadata. It has no upsides but it's cool when you get them tangled >> up. >> >> 4. The current work flow works. But, I don't think it's true. I think >> there are people who don't want to criticize, or people who just see >> docutils website and (sorry here) think it's a dead ghost town. That's my >> first impression when I see it. To people who used SF for a decade, this may >> not make sense, but this place honestly sucks. To other people who are newer >> to python, they may not be talking, but it scares them off or confuses them. >> >> I have issues with subversion. Its positive is simplicity. On the other >> hand, it lacks many of the conveniences git has. It's actually nice to have >> a decentralized system. The workflow for branches is nice. It's fast. In >> 2014, I think it's safe to say many developers know how to use it. >> >> Many python projects make their home on github. Flask, Werkzeug, Tornado, >> Requests. Cython. Pandas. Numpy. IPython. >> >> I have a preference for github and git. I like their interface for >> browsing source, pull requests, issues. I think github's pull requests and >> issue system is very contributor friendly. >> >> Even SQLAlchemy moved from bitbucket to github. Here is their rationale: >> http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ >> >> For the sake of articulating it, who makes the choice if docutils were to >> move to a new place? What is the current feeling around here? >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Docutils-develop mailing list >> Docutils-develop@... >> https://lists.sourceforge.net/lists/listinfo/docutils-develop >> >> Please use "Reply All" to reply to the list. >> > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Docutils-develop mailing list > Docutils-develop@... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. > |
|
From: engelbert gruber <engelbert.gruber@gm...> - 2014-01-23 08:21:17
|
hello, subversion does the job, so why change it . considering the premize "release often" translated for developers "commit often" , distributed vcs are an excuse. (considering that people check their facebook every 5 minutes, what is the problem with a centralized vcs) daily vcs usage with svn is svn update, svn diff, svn commit, git doubls this so where is the advancement ? cheers e On 21 January 2014 23:41, Tony N <railsdontscale@...> wrote: > Greetings all, > > I wanted to get a status report on where things stand with VCS and a home > for docutils. > > To begin, I have a few issues with source forge: > > I don't find the interface friendly. It's inconsistent. I am not up to > date with it, because everyone else is using something else. > > The good things with source forge: > > 1. The good news is sourceforge may allow docutils to bind with > advertisements, with DevShare, we can hook into setup.py and monetize > docutils development. For more information, you can see > http://sourceforge.net/blog/advertising-bundling-community-and-criticism/. > > 2. Also source forge benefits from being funded by Dice Holdings, Inc. You > can read more about them at http://www.diceholdingsinc.com/. According to > their front page, I see they announced as $50 million Stock Repurchase > program. So while I'm ignorant of finance, we can get someone from numpy to > confirm if fiscals are sound for 2014. SF could be around for a long time. > > 3. SVN is simple. Older versions have a folder in every sub-directory to > maintain metadata. It has no upsides but it's cool when you get them > tangled up. > > 4. The current work flow works. But, I don't think it's true. I think > there are people who don't want to criticize, or people who just see > docutils website and (sorry here) think it's a dead ghost town. That's my > first impression when I see it. To people who used SF for a decade, this > may not make sense, but this place honestly sucks. To other people who are > newer to python, they may not be talking, but it scares them off or > confuses them. > > I have issues with subversion. Its positive is simplicity. On the other > hand, it lacks many of the conveniences git has. It's actually nice to have > a decentralized system. The workflow for branches is nice. It's fast. In > 2014, I think it's safe to say many developers know how to use it. > > Many python projects make their home on github. Flask, Werkzeug, Tornado, > Requests. Cython. Pandas. Numpy. IPython. > > I have a preference for github and git. I like their interface for > browsing source, pull requests, issues. I think github's pull requests and > issue system is very contributor friendly. > > Even SQLAlchemy moved from bitbucket to github. Here is their rationale: > http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ > > For the sake of articulating it, who makes the choice if docutils were to > move to a new place? What is the current feeling around here? > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Docutils-develop mailing list > Docutils-develop@... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. > > |
|
From: Tony N <railsdontscale@gm...> - 2014-01-21 22:42:07
|
Greetings all, I wanted to get a status report on where things stand with VCS and a home for docutils. To begin, I have a few issues with source forge: I don't find the interface friendly. It's inconsistent. I am not up to date with it, because everyone else is using something else. The good things with source forge: 1. The good news is sourceforge may allow docutils to bind with advertisements, with DevShare, we can hook into setup.py and monetize docutils development. For more information, you can see http://sourceforge.net/blog/advertising-bundling-community-and-criticism/. 2. Also source forge benefits from being funded by Dice Holdings, Inc. You can read more about them at http://www.diceholdingsinc.com/. According to their front page, I see they announced as $50 million Stock Repurchase program. So while I'm ignorant of finance, we can get someone from numpy to confirm if fiscals are sound for 2014. SF could be around for a long time. 3. SVN is simple. Older versions have a folder in every sub-directory to maintain metadata. It has no upsides but it's cool when you get them tangled up. 4. The current work flow works. But, I don't think it's true. I think there are people who don't want to criticize, or people who just see docutils website and (sorry here) think it's a dead ghost town. That's my first impression when I see it. To people who used SF for a decade, this may not make sense, but this place honestly sucks. To other people who are newer to python, they may not be talking, but it scares them off or confuses them. I have issues with subversion. Its positive is simplicity. On the other hand, it lacks many of the conveniences git has. It's actually nice to have a decentralized system. The workflow for branches is nice. It's fast. In 2014, I think it's safe to say many developers know how to use it. Many python projects make their home on github. Flask, Werkzeug, Tornado, Requests. Cython. Pandas. Numpy. IPython. I have a preference for github and git. I like their interface for browsing source, pull requests, issues. I think github's pull requests and issue system is very contributor friendly. Even SQLAlchemy moved from bitbucket to github. Here is their rationale: http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ For the sake of articulating it, who makes the choice if docutils were to move to a new place? What is the current feeling around here? |
|
From: Brecht Machiels <darklite09@us...> - 2014-01-12 19:21:50
|