camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Anstey <jans...@gmail.com>
Subject Re: helping out with the Web site
Date Thu, 11 Nov 2010 15:20:57 GMT
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 <hzbarcea@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 <seijoed@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 <dkulp@apache.org> wrote:
> >>>>> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
> >>>>>> On 10 November 2010 14:51, Daniel Kulp <dkulp@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?
> >>>>
> >>>> Patch files are a total PITA for both the person contributing and the
> >>>> person applying the patch. (They usually break, get out of sync, have
> >>>> whitespace issues and frequently have the wrong path information in
> >>>> them & often have problems with new/renamed/deleted files).
> >>>>
> >>>> If this discussion really is about being a "community issue" and
> >>>> making it easy for both folks to contribute and for committers to
> >>>> apply those contributions, I'd rather we figure out this issue of
> >>>> using links to git commits as an alternative to patch files on JIRAs
-
> >>>> this could make a *massive* difference to both getting contributions
> >>>> and more effectively applying them IMHO. Helping scm-novices
> >>>> contribute to documentation (which they've never really done so far
on
> >>>> Camel anyway) seems quite irrelevant in comparison.
> >>> I don't know if this is a scm-novices issues. We had contributions from
> >> not committers in the past.
> >>> Johan (before his commiter days) is one example, Steve Bate is another.
> I
> >> would rather ask them how likely would it be to contribute to doc if
> they
> >> had to co/edit/submit-patch, vs edit in-place wiki style.
> >>> I know they are not scm-novices.
> >>>
> >>> I am open to any alternative that would not raise the barrier to entry
> >> for documentation contributors and that's acceptable to the ASF.
> >>>
> >>> Hadrian
> >>>
> >>>>
> >>>> --
> >>>> James
> >>>> -------
> >>>> FuseSource
> >>>> Email: james@fusesource.com
> >>>> Web: http://fusesource.com
> >>>> Twitter: jstrachan
> >>>> Blog: http://macstrac.blogspot.com/
> >>>>
> >>>> Open Source Integration
> >>>
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Jon
> > ---------------
> > FuseSource
> > Email: jon@fusesource.com
> > Web: fusesource.com
> > Twitter: jon_anstey
> > Blog: http://janstey.blogspot.com
> > Author of Camel in Action: http://manning.com/ibsen
>
>


-- 
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message