Eric, thanks for the wiki page, excellent work.
While editing the wiki page Eric created I got to think more about the concrete
ways in which the two approaches are different. Most of the documentation is
generated by committers. Not ideal for at least two reasons. It doesn't scale
first of all
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 wrote:
> Personally I would favor *instead of* (cause its probably more work to have
> both...) but I want whats best for the community of
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 f
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) mad
On 11 November 2010 13:29, 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 poin
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
Agree on all counts.
Hadrian
On Nov 10, 2010, at 5:06 PM, Guillaume Nodet wrote:
> AAFAIK, most projects use the default settings, i.e. edit for
> committers, comments for everyone with an ICLA on file.
> If non-committers with a ICLA on file want to edit, permissions is
> granted case by case us
Then this is a problem. I added you to the asf-cla group and you should have
the karma to edit the wiki.
By the way you have two confluence accounts, which one did you use? Can you
ping me on #camel tomorrow and resolve this interactively?
Thanks,
Hadrian
On Nov 10, 2010, at 4:16 PM, Eric John
AAFAIK, most projects use the default settings, i.e. edit for
committers, comments for everyone with an ICLA on file.
If non-committers with a ICLA on file want to edit, permissions is
granted case by case usually (at least, that's what i've done since a
few years).
So the bar is lower than for cod
Hadrian,
As it turns out, not anyone with a signed CLA can edit the Camel wiki.
The Apache Confluence wiki allows each community to determine who can
edit the pages in their space.
I went create a page listing the ideas/issues around a site update and
was confronted with a "Permission Denied" page.
On Wednesday 10 November 2010 2:07:48 pm Guillaume Nodet wrote:
> On Wed, Nov 10, 2010 at 16:15, Daniel Kulp wrote:
> > On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
> >> On 10 November 2010 14:51, Daniel Kulp wrote:
> >> > For most of the people on this list, it ISN'T a big deal
On Wed, Nov 10, 2010 at 16:15, Daniel Kulp wrote:
> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
>> On 10 November 2010 14:51, Daniel Kulp 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
Just for the record. I like scalate too, it's f*** awesome s*** :).
Hadrian
On Nov 10, 2010, at 11:04 AM, Johan Edstrom 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 wh
Now, that's not entirely true either.
Not all projects include the wiki documentation in the distro. That is the
issue!
Since we do, everything in the distro must be AL2 and the IP tracked to
original contributions.
A non committer must either submit a patch (which does not currently work for
d
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
On Nov 10, 2010, at 10:28 AM, James Strachan wrote:
> On 10 November 2010 15:15, Daniel Kulp wrote:
>> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
>>> On 10 November 2010 14:51, Daniel Kulp wrote:
For most of the people on this list, it ISN'T a big deal. We deal
> And then for people to actually be able to edit the wiki page they
> have to sign up for the ICLA which takes a fair bit of time and for
> some people just scare them off.
This is a mandatory part as long as we include the manual in the distro.
Hadrian
On Nov 10, 2010, at 10:07 AM, Claus Ibsen
On Wed, Nov 10, 2010 at 16:29, Eric Johnson wrote:
> I want to make sure I understand a few of the issues here:
>
> We want to make it as easy as possible for people to make changes to
> the documentation.
> Before a person can edit the wiki they need to sign an icla.
> We don't let anyone change
On 10 November 2010 15:00, Hadrian Zbarcea wrote:
> That is true, but you can see your changes in the wiki right away.
>
> I love the idea of having the docs version controlled, I understand all the
> benefits. I am also convinced losing the ability to edit in place is a major
> community issue.
I want to make sure I understand a few of the issues here:
We want to make it as easy as possible for people to make changes to
the documentation.
Before a person can edit the wiki they need to sign an icla.
We don't let anyone change the code who hasn't been vetted by the
community and made a com
On 10 November 2010 15:15, Daniel Kulp wrote:
> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
>> On 10 November 2010 14:51, Daniel Kulp 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.
On 10 November 2010 15:00, Hadrian Zbarcea wrote:
> That is true, but you can see your changes in the wiki right away.
>
> I love the idea of having the docs version controlled, I understand all the
> benefits. I am also convinced losing the ability to edit in place is a major
> community issue.
On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
> On 10 November 2010 14:51, Daniel Kulp 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 con
On Wed, Nov 10, 2010 at 4:00 PM, Hadrian Zbarcea wrote:
> That is true, but you can see your changes in the wiki right away.
>
> I love the idea of having the docs version controlled, I understand all the
> benefits. I am also convinced losing the ability to edit in place is a major
> community
That is true, but you can see your changes in the wiki right away.
I love the idea of having the docs version controlled, I understand all the
benefits. I am also convinced losing the ability to edit in place is a major
community issue. Can we have both? We want to make it as easy as possible fo
On 10 November 2010 14:51, Daniel Kulp wrote:
> On Wednesday 10 November 2010 9:43:13 am Guillaume Nodet wrote:
>> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea wrote:
>> > Thanks James,
>> >
>> > You have to comment out the dependency on scalate-test in the pom for
>> > this to work (otherwise
On 10 November 2010 14:43, Guillaume Nodet wrote:
> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea wrote:
>> Thanks James,
>>
>> You have to comment out the dependency on scalate-test in the pom for this
>> to work (otherwise you get a "Failed to resolve artifact").
>>
>> That aside, one of the
Yeah, that's what I mean and what I believe was discussed in Aug. Hosting it at
the ASF (or somewhere) I don't think would be a problem.
Guillaume, I assume we'd deploy the webapp in Karaf, correct? ;)
On a second thought, since a few projects plan on using it, what about
incubating it at the AS
On Wednesday 10 November 2010 9:43:13 am Guillaume Nodet wrote:
> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea wrote:
> > Thanks James,
> >
> > You have to comment out the dependency on scalate-test in the pom for
> > this to work (otherwise you get a "Failed to resolve artifact").
> >
> > Tha
On 10 November 2010 13:40, Hadrian Zbarcea wrote:
> Thanks James,
>
> You have to comment out the dependency on scalate-test in the pom for this to
> work (otherwise you get a "Failed to resolve artifact").
>
> That aside, one of the important requirements I believe is not to raise the
> barrier
On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea wrote:
> Thanks James,
>
> You have to comment out the dependency on scalate-test in the pom for this to
> work (otherwise you get a "Failed to resolve artifact").
>
> That aside, one of the important requirements I believe is not to raise the
> bar
Thanks James,
You have to comment out the dependency on scalate-test in the pom for this to
work (otherwise you get a "Failed to resolve artifact").
That aside, one of the important requirements I believe is not to raise the
barrier to entry for those who want to contribute documentation. Today
FWIW I started an experimental spike to try recreate the Camel website
using wiki files from source control - exported from Confluence -
(rather than the Confluence / AutoExport icky stuff) like Karaf &
ServiceMix are doing. More as a test of Scalate than any attempt to
actually change any document
hzbar...@gmail.com]
Sent: Tuesday, November 09, 2010 10:04 PM
To: dev@camel.apache.org
Subject: Re: helping out with the Web site
Eric, you can do it. I made sure you have the right karma (based on your
icla filed with the ASF).
Cheers,
Hadrian
On Nov 9, 2010, at 3:34 PM, Eric Johnson wrote:
>
Eric, you can do it. I made sure you have the right karma (based on your icla
filed with the ASF).
Cheers,
Hadrian
On Nov 9, 2010, at 3:34 PM, Eric Johnson wrote:
> Hadrian,
> Lukasz is polishing up the SMX design this week. It looks pretty
> snazy. Hopefully it will be integrated into the Saca
Hadrian,
Lukasz is polishing up the SMX design this week. It looks pretty
snazy. Hopefully it will be integrated into the Sacalte generated
pilot project soon.
A wiki page for proposals is a good idea. I can post a link to the
proposed design for SMX and use that as a starting point for the
discuss
Thanks Richard. I am glad somebody noticed that, because there was no response.
However there was a lot of related activity on Karaf and SMX following my post.
Cheers,
Hadrian
On Nov 9, 2010, at 3:15 PM, Richard Kettelerij wrote:
>
> FYI,
> http://camel.465427.n5.nabble.com/DISCUSS-Apache-Cam
Eric, nice to hear from you. I've seen you busy with Karaf and SMX.
Yes, absolutely. We talked in Aug about aligning as much as possible the
AMQ/SMX/Karaf/Camel sites as much a possible. Not sure how much that would be
possible with CXF. The rationale for that is that many users use these projec
FYI,
http://camel.465427.n5.nabble.com/DISCUSS-Apache-Camel-website-facelift-td3202031.html#a3202031
--
View this message in context:
http://camel.465427.n5.nabble.com/helping-out-with-the-Web-site-tp3257543p3257592.html
Sent from the Camel Development mailing list archive at Nabble.com.
39 matches
Mail list logo
