Fwiw, most old projects at the ASF were using svn with anakia before confluence' use spread within the ASF i think.
On Thursday, November 11, 2010, Jon Anstey <jans...@gmail.com> wrote: > Personally I would favor *instead of* (cause its probably more work to have > both...) but I want whats best for the community of course :) > > BTW I was poking around in svn and saw that Apache Ant also hosts their docs > in SCM http://svn.apache.org/repos/asf/ant/core/trunk/docs/ so we wouldn't > be the first or anything to do that... > > On Thu, Nov 11, 2010 at 11:28 AM, Hadrian Zbarcea <hzbar...@gmail.com>wrote: > >> Jon, >> >> Absolutely valid point. Are you saying that you'd like that *in addition >> to* a wiki way of updating documentation or *instead of*? >> >> Hadrian >> >> >> On Nov 11, 2010, at 8:29 AM, Jon Anstey wrote: >> >> > I think this thread is over but I just wanted to agree on a point Johan >> (and >> > probably others) made here. >> > >> > "Not to mention if you actually fix a bug and submit a patch you could >> fix >> > documentation in one feel swoop." >> > >> > That is an EXCELLENT point. In the past I've always put off writing any >> docs >> > for a code change (bad, I know..) partly because confluence is slow >> > and cumbersome and also because once the code fix has been made docs seem >> > lower priority... I think being able to do both in one commit would make >> doc >> > updates happen more often. I mean, sometimes it may be just that you >> renamed >> > an endpoint URI property so it may be a really simple change to the docs. >> > >> > On Wed, Nov 10, 2010 at 12:34 PM, Johan Edstrom <seij...@gmail.com> >> wrote: >> > >> >> I actually really liked the scalate project and writing the docs in >> IDEA, >> >> making a patch and tossing it in github. >> >> >> >> Offline editing also seems really nice for when you are on planes, in >> >> airports or hotels. >> >> Not to mention if you actually fix a bug and submit a patch you could >> fix >> >> documentation in one feel swoop. >> >> >> >> And with the possibility of editing and running Jetty locally - it was >> >> really easy. >> >> >> >> Just my .02, i'm one of those that like irc for the quick informal style >> >> over forums for example, >> >> I also really like svn/git since I have tooling around versioning et al. >> >> >> >> And yeah, making patches is "klunky" using diff and things like that. >> >> >> >> /je >> >> On Nov 10, 2010, at 8:52 AM, Hadrian Zbarcea wrote: >> >> >> >>> >> >>> On Nov 10, 2010, at 10:28 AM, James Strachan wrote: >> >>> >> >>>> On 10 November 2010 15:15, Daniel Kulp <dk...@apache.org> wrote: >> >>>>> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote: >> >>>>>> On 10 November 2010 14:51, Daniel Kulp <dk...@apache.org> wrote: >> >>>>>>> >> >>>>>>> For most of the people on this list, it ISN'T a big deal. We deal >> >> with >> >>>>>>> svn and mvn every day. For others, it could be. >> >>>>>> >> >>>>>> Given 99% of all our documentation and web content is developed by >> >>>>>> committers or folks who are capable of editing text files and using >> >>>>>> git/svn, I'd rather use a system that helps the 99% be more >> effective. >> >>>>>> >> >>>>>> Maybe you should just help out this one CXF person & show them how >> to >> >>>>>> fork & commit to github (its very easy), then you can easily pull >> >>>>>> their commits from there? >> >>>>> >> >>>>> Umm.. no. Pulling branches from github is NOT, at this point, an >> >> acceptable >> >>>>> way of getting content into an Apache product. They would still >> need >> >> to >> >>>>> create a patch and attach it to JIRA with the "grant" checkbox >> >> checked. >> >>>> >> >>>> Whatever happens folks have to raise a JIRA and click the "grant" >> >> checkbox. >> >>>> >> >>>> I fail to see why a link to a specific commit (i.e. a link to a number >> >>>> of patches) is any less suitable than a number of patch files being >> >>>> attached in place to the JIRA. Got anything specific to back this up >> >>>> or is it just that we've not done it before? >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
