You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Alasdair Nottingham <no...@apache.org> on 2011/03/18 10:46:29 UTC

Permissions for changing the web site

Hi,

I was wondering if it was possible to do one of the following things:

1. Allow all Apache Committers to make changes to our website.
2. To allow a subset of Apache Committers, who aren't aries committers
to modify our website.

Because this is all in subversion I don't know what is and isn't
possible, but it would be nice I think if people who aren't aries
committers could contribute to the website. This used to be possible
with confluence.

Thoughts?
Alasdair

-- 
Alasdair Nottingham
not@apache.org

Re: Permissions for changing the web site

Posted by Jeremy Hughes <hu...@apache.org>.
On 18 March 2011 11:28, Daniel Kulp <dk...@apache.org> wrote:
> On Friday 18 March 2011 6:03:33 AM Guillaume Nodet wrote:
>> That being said, I'm quite sure our PMC chair can edit the authorization
>> file
>> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authori
>> zation to add the following:
>>
>> [/aries/site]
>> @committers  = rw
>>
>> We just need to agree on it.
>
> One note about this (which I think will work fine for Guillaume's concerns) is
> that this allows any commiter to use the CMS to make changes and stage a new
> site.  That is good.   But I believe only an Aries commiter can then hit the
> "publish" button to publish it.    Thus, all doc changes would still need a
> review by a committer before going live.    It's basically just making the
> "patch" process automatic, but would still require a bit of committer review.

You're probably right, because the CMS built files are checked in, in
a different place in SVN ... in a different repo even! The thing is,
if a dev makes his/her own change and there are others stacked up
which haven't been published yet, then by default all those stacked up
changes are included in the dev's publish of his own change.
Admittedly a complete diff is shown in CMS, but if the dev doesn't
want to publish all the other changes, it's difficult to unpick them.

>
> In anycase, I think that would be acceptable.
>
> Dan
>
>
>>
>> On Fri, Mar 18, 2011 at 10:57, Guillaume Nodet <gn...@gmail.com> wrote:
>> > Another way too look at that would be that they now need to provide
>> > patches, which mean they should get voted as committer even faster.
>> > People can become committers without contributing *code* fwiw.
>> >
>> > On Fri, Mar 18, 2011 at 10:46, Alasdair Nottingham <no...@apache.org> wrote:
>> >> Hi,
>> >>
>> >> I was wondering if it was possible to do one of the following things:
>> >>
>> >> 1. Allow all Apache Committers to make changes to our website.
>> >> 2. To allow a subset of Apache Committers, who aren't aries committers
>> >> to modify our website.
>> >>
>> >> Because this is all in subversion I don't know what is and isn't
>> >> possible, but it would be nice I think if people who aren't aries
>> >> committers could contribute to the website. This used to be possible
>> >> with confluence.
>> >>
>> >> Thoughts?
>> >> Alasdair
>> >>
>> >> --
>> >> Alasdair Nottingham
>> >> not@apache.org
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>

Re: Permissions for changing the web site

Posted by Daniel Kulp <dk...@apache.org>.
On Friday 18 March 2011 6:03:33 AM Guillaume Nodet wrote:
> That being said, I'm quite sure our PMC chair can edit the authorization
> file
> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authori
> zation to add the following:
> 
> [/aries/site]
> @committers  = rw
> 
> We just need to agree on it.

One note about this (which I think will work fine for Guillaume's concerns) is 
that this allows any commiter to use the CMS to make changes and stage a new 
site.  That is good.   But I believe only an Aries commiter can then hit the 
"publish" button to publish it.    Thus, all doc changes would still need a 
review by a committer before going live.    It's basically just making the 
"patch" process automatic, but would still require a bit of committer review.

In anycase, I think that would be acceptable.

Dan


> 
> On Fri, Mar 18, 2011 at 10:57, Guillaume Nodet <gn...@gmail.com> wrote:
> > Another way too look at that would be that they now need to provide
> > patches, which mean they should get voted as committer even faster.
> > People can become committers without contributing *code* fwiw.
> > 
> > On Fri, Mar 18, 2011 at 10:46, Alasdair Nottingham <no...@apache.org> wrote:
> >> Hi,
> >> 
> >> I was wondering if it was possible to do one of the following things:
> >> 
> >> 1. Allow all Apache Committers to make changes to our website.
> >> 2. To allow a subset of Apache Committers, who aren't aries committers
> >> to modify our website.
> >> 
> >> Because this is all in subversion I don't know what is and isn't
> >> possible, but it would be nice I think if people who aren't aries
> >> committers could contribute to the website. This used to be possible
> >> with confluence.
> >> 
> >> Thoughts?
> >> Alasdair
> >> 
> >> --
> >> Alasdair Nottingham
> >> not@apache.org
> > 
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Re: Permissions for changing the web site

Posted by Guillaume Nodet <gn...@gmail.com>.
That being said, I'm quite sure our PMC chair can edit the authorization file
   https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization
to add the following:

[/aries/site]
@committers  = rw

We just need to agree on it.

On Fri, Mar 18, 2011 at 10:57, Guillaume Nodet <gn...@gmail.com> wrote:
> Another way too look at that would be that they now need to provide
> patches, which mean they should get voted as committer even faster.
> People can become committers without contributing *code* fwiw.
>
> On Fri, Mar 18, 2011 at 10:46, Alasdair Nottingham <no...@apache.org> wrote:
>> Hi,
>>
>> I was wondering if it was possible to do one of the following things:
>>
>> 1. Allow all Apache Committers to make changes to our website.
>> 2. To allow a subset of Apache Committers, who aren't aries committers
>> to modify our website.
>>
>> Because this is all in subversion I don't know what is and isn't
>> possible, but it would be nice I think if people who aren't aries
>> committers could contribute to the website. This used to be possible
>> with confluence.
>>
>> Thoughts?
>> Alasdair
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 18/03/2011 11:22, Holly Cummins wrote:
> zoe slattery<zo...@gmail.com>  wrote on 03/18/2011 10:28:32 AM:
>
>> +1 I would like to see committers elected because of doc contributions
> [cut for length]
>
> The downside of this is that Alasdair's and Charles's experience of
> submitting and applying a patch doesn't seem to have been very smooth.
> It's hard to say if that's because the CMS process just doesn't work well
> for patches, or they just did it wrong. :)
It _should_ be no different than any other SVN patch. I do a lot of 
updating by checking files out, editing and checking in.
Its possible that something may have changed recently - but that would 
be a CMS bug.
> If the patch process genuinely doesn't work so well for doc contributions
> we may decide that facilitating doc contributions is more important than
> facilitating new committers - or we may not, of course, since enabling
> doc-driven committers sounds like a good thing to me as well.
>
> (If we can identify a better way of submitting patches, of course, what
> we'll need is someone to submit an patch for our docs pages with
> instructions. :) )
>
> Holly
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>


Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Hi Zoe,

I will remake a test to see if I experience again the same issue using
CMS tool. If this is the case, I will check with you.

Regards,

Charles



On Fri, Mar 18, 2011 at 3:08 PM, zoe slattery <zo...@gmail.com> wrote:
> On 18/03/2011 12:39, Jeremy Hughes wrote:
>>
>> On 18 March 2011 11:22, Holly Cummins<cu...@uk.ibm.com>  wrote:
>>>
>>> zoe slattery<zo...@gmail.com>  wrote on 03/18/2011 10:28:32 AM:
>>>
>>>> +1 I would like to see committers elected because of doc contributions
>>>
>>> [cut for length]
>>>
>>> The downside of this is that Alasdair's and Charles's experience of
>>> submitting and applying a patch doesn't seem to have been very smooth.
>>> It's hard to say if that's because the CMS process just doesn't work well
>>> for patches, or they just did it wrong. :)
>>>
>>> If the patch process genuinely doesn't work so well for doc contributions
>>> we may decide that facilitating doc contributions is more important than
>>> facilitating new committers - or we may not, of course, since enabling
>>> doc-driven committers sounds like a good thing to me as well.
>>
>> It's very easy for committers to make changes using CMS, but for
>> contributors (inlcuding those who don't have an ASF id) they have to
>> check out the site, configure the build env, build it (instructions on
>> our site) and submit a patch.
>
> This is true and I can see its a bit of a PITA.
>>
>>  Then the committer applying the patch
>> also needs the full site checked out and configured to build.
>
> This is not true. You should just be able to check out, apply patch, commit
> and use the CMS tooling to verify.
>>
>> I think
>> that process could be improved on, but that would need changes in CMS
>> a) to allow anyone to make changes in a sandbox and create a patch for
>> a committer b) for a committer to be able to take that patch and apply
>> it.
>>
>> So I don't think the patch process doesn't work (unless you can
>> elaborate), just that it's long winded.
>>
>>> (If we can identify a better way of submitting patches, of course, what
>>> we'll need is someone to submit an patch for our docs pages with
>>> instructions. :) )
>>>
>>> Holly
>>>
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>>> 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Zoe,

As a Aries Commiter, you have the rights to commit something into SVN
which is not the case for me. So I cannot commit using svn -->

Charles-Moulliards-MacBook-Pro:modules charlesmoulliard$ svn commit -m
"Add text"
Sending        modules/jpaproject.mdtext
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response
to CHECKOUT request for
'/repos/asf/!svn/ver/1082937/aries/site/trunk/content/modules/jpaproject.mdtext'

The procedure requiring a patch from CMS + open a ticket in Jira to
commit the patch seems too complicated and in fact does not work (see
ticket https://issues.apache.org/jira/browse/ARIES-597)

So what solution do you suggest to simplify the procedure for persons
who would like to improve Aries Documentation and (provide grants on
aries-site for apache committers which are not Aries committer, ....)
?

Regards,

Charles
On Fri, Mar 18, 2011 at 3:45 PM, zoe slattery <zo...@gmail.com> wrote:
> On 18/03/2011 14:19, Charles Moulliard wrote:
>>
>> Here is a new patch that you can use to make a test
>>
> OK - not exactly sure what you wanted me to do with this but this is what I
> did:
>
> Copied your file to patch.txt
> Changed directory to where my site is checked out (aries/site)
> cd content/modules
> patch < patch.txt
> used svn diff to check that it had been applied
> svn commit -m "Apply CM patch"
>
> So, this was pretty straightforward. The checkin generates a staging build
> of the site, your change is visible here:
>
> http://aries.staging.apache.org/modules/jpaproject.html
>
> So, I'm not sure what the issue was?
>
> Zoe
>
>> On Fri, Mar 18, 2011 at 3:14 PM, zoe slattery<zo...@gmail.com>
>>  wrote:
>>>>>
>>>>>  Then the committer applying the patch
>>>>> also needs the full site checked out and configured to build.
>>>>
>>>> This is not true. You should just be able to check out, apply patch,
>>>> commit and use the CMS tooling to verify.
>>>
>>> Hmm - on second thoughts - strictly speaking you are right.
>>>
>>> Z
>>>
>>>>>>
>>>
>
>

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 18/03/2011 14:56, Alasdair Nottingham wrote:
> When I tried to apply the original patch I got error messages back. I
> can't recall the messages and I also can't reproduce them.
>
> I tried to apply the original patch again today and got this:
>
> patching file jpaproject.mdtext
> Hunk #1 FAILED at 13.
> patch: **** malformed patch at line 66: \ No newline at end of file
>
> which is not what I got before. I must have done something wrong, but
> I don't know what.
Don't know - I have had problems with patch in the past and never 
completely understood why they went away.
I wonder if I randomly installed some other version of patch? I may have.

Z
> Alasdair
>
> On 18 March 2011 14:45, zoe slattery<zo...@gmail.com>  wrote:
>> On 18/03/2011 14:19, Charles Moulliard wrote:
>>> Here is a new patch that you can use to make a test
>>>
>> OK - not exactly sure what you wanted me to do with this but this is what I
>> did:
>>
>> Copied your file to patch.txt
>> Changed directory to where my site is checked out (aries/site)
>> cd content/modules
>> patch<  patch.txt
>> used svn diff to check that it had been applied
>> svn commit -m "Apply CM patch"
>>
>> So, this was pretty straightforward. The checkin generates a staging build
>> of the site, your change is visible here:
>>
>> http://aries.staging.apache.org/modules/jpaproject.html
>>
>> So, I'm not sure what the issue was?
>>
>> Zoe
>>
>>> On Fri, Mar 18, 2011 at 3:14 PM, zoe slattery<zo...@gmail.com>
>>>   wrote:
>>>>>>   Then the committer applying the patch
>>>>>> also needs the full site checked out and configured to build.
>>>>> This is not true. You should just be able to check out, apply patch,
>>>>> commit and use the CMS tooling to verify.
>>>> Hmm - on second thoughts - strictly speaking you are right.
>>>>
>>>> Z
>>>>
>>
>
>


Re: Permissions for changing the web site

Posted by Alasdair Nottingham <no...@apache.org>.
When I tried to apply the original patch I got error messages back. I
can't recall the messages and I also can't reproduce them.

I tried to apply the original patch again today and got this:

patching file jpaproject.mdtext
Hunk #1 FAILED at 13.
patch: **** malformed patch at line 66: \ No newline at end of file

which is not what I got before. I must have done something wrong, but
I don't know what.

Alasdair

On 18 March 2011 14:45, zoe slattery <zo...@gmail.com> wrote:
> On 18/03/2011 14:19, Charles Moulliard wrote:
>>
>> Here is a new patch that you can use to make a test
>>
> OK - not exactly sure what you wanted me to do with this but this is what I
> did:
>
> Copied your file to patch.txt
> Changed directory to where my site is checked out (aries/site)
> cd content/modules
> patch < patch.txt
> used svn diff to check that it had been applied
> svn commit -m "Apply CM patch"
>
> So, this was pretty straightforward. The checkin generates a staging build
> of the site, your change is visible here:
>
> http://aries.staging.apache.org/modules/jpaproject.html
>
> So, I'm not sure what the issue was?
>
> Zoe
>
>> On Fri, Mar 18, 2011 at 3:14 PM, zoe slattery<zo...@gmail.com>
>>  wrote:
>>>>>
>>>>>  Then the committer applying the patch
>>>>> also needs the full site checked out and configured to build.
>>>>
>>>> This is not true. You should just be able to check out, apply patch,
>>>> commit and use the CMS tooling to verify.
>>>
>>> Hmm - on second thoughts - strictly speaking you are right.
>>>
>>> Z
>>>
>>>>>>
>>>
>
>



-- 
Alasdair Nottingham
not@apache.org

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 18/03/2011 14:19, Charles Moulliard wrote:
> Here is a new patch that you can use to make a test
>
OK - not exactly sure what you wanted me to do with this but this is 
what I did:

Copied your file to patch.txt
Changed directory to where my site is checked out (aries/site)
cd content/modules
patch < patch.txt
used svn diff to check that it had been applied
svn commit -m "Apply CM patch"

So, this was pretty straightforward. The checkin generates a staging 
build of the site, your change is visible here:

http://aries.staging.apache.org/modules/jpaproject.html

So, I'm not sure what the issue was?

Zoe

> On Fri, Mar 18, 2011 at 3:14 PM, zoe slattery<zo...@gmail.com>  wrote:
>>>>   Then the committer applying the patch
>>>> also needs the full site checked out and configured to build.
>>> This is not true. You should just be able to check out, apply patch,
>>> commit and use the CMS tooling to verify.
>> Hmm - on second thoughts - strictly speaking you are right.
>>
>> Z
>>
>>>>>
>>


Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Here is a new patch that you can use to make a test


On Fri, Mar 18, 2011 at 3:14 PM, zoe slattery <zo...@gmail.com> wrote:
>
>>>  Then the committer applying the patch
>>> also needs the full site checked out and configured to build.
>>
>> This is not true. You should just be able to check out, apply patch,
>> commit and use the CMS tooling to verify.
>
> Hmm - on second thoughts - strictly speaking you are right.
>
> Z
>
>>>
>>>>
>>>>
>>>
>>
>
>

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
>>   Then the committer applying the patch
>> also needs the full site checked out and configured to build.
> This is not true. You should just be able to check out, apply patch, 
> commit and use the CMS tooling to verify.
Hmm - on second thoughts - strictly speaking you are right.

Z

>>
>>>
>>>
>>
>


Re: Permissions for changing the web site

Posted by Jeremy Hughes <hu...@apache.org>.
On 18 March 2011 14:08, zoe slattery <zo...@gmail.com> wrote:
> On 18/03/2011 12:39, Jeremy Hughes wrote:
>>
>> On 18 March 2011 11:22, Holly Cummins<cu...@uk.ibm.com>  wrote:
>>>
>>> zoe slattery<zo...@gmail.com>  wrote on 03/18/2011 10:28:32 AM:
>>>
>>>> +1 I would like to see committers elected because of doc contributions
>>>
>>> [cut for length]
>>>
>>> The downside of this is that Alasdair's and Charles's experience of
>>> submitting and applying a patch doesn't seem to have been very smooth.
>>> It's hard to say if that's because the CMS process just doesn't work well
>>> for patches, or they just did it wrong. :)
>>>
>>> If the patch process genuinely doesn't work so well for doc contributions
>>> we may decide that facilitating doc contributions is more important than
>>> facilitating new committers - or we may not, of course, since enabling
>>> doc-driven committers sounds like a good thing to me as well.
>>
>> It's very easy for committers to make changes using CMS, but for
>> contributors (inlcuding those who don't have an ASF id) they have to
>> check out the site, configure the build env, build it (instructions on
>> our site) and submit a patch.
>
> This is true and I can see its a bit of a PITA.
>>
>>  Then the committer applying the patch
>> also needs the full site checked out and configured to build.
>
> This is not true. You should just be able to check out, apply patch, commit
> and use the CMS tooling to verify.

Fair enough.

>>
>> I think
>> that process could be improved on, but that would need changes in CMS
>> a) to allow anyone to make changes in a sandbox and create a patch for
>> a committer b) for a committer to be able to take that patch and apply
>> it.
>>
>> So I don't think the patch process doesn't work (unless you can
>> elaborate), just that it's long winded.
>>
>>> (If we can identify a better way of submitting patches, of course, what
>>> we'll need is someone to submit an patch for our docs pages with
>>> instructions. :) )
>>>
>>> Holly
>>>
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>>> 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 18/03/2011 12:39, Jeremy Hughes wrote:
> On 18 March 2011 11:22, Holly Cummins<cu...@uk.ibm.com>  wrote:
>> zoe slattery<zo...@gmail.com>  wrote on 03/18/2011 10:28:32 AM:
>>
>>> +1 I would like to see committers elected because of doc contributions
>> [cut for length]
>>
>> The downside of this is that Alasdair's and Charles's experience of
>> submitting and applying a patch doesn't seem to have been very smooth.
>> It's hard to say if that's because the CMS process just doesn't work well
>> for patches, or they just did it wrong. :)
>>
>> If the patch process genuinely doesn't work so well for doc contributions
>> we may decide that facilitating doc contributions is more important than
>> facilitating new committers - or we may not, of course, since enabling
>> doc-driven committers sounds like a good thing to me as well.
> It's very easy for committers to make changes using CMS, but for
> contributors (inlcuding those who don't have an ASF id) they have to
> check out the site, configure the build env, build it (instructions on
> our site) and submit a patch.
This is true and I can see its a bit of a PITA.
>   Then the committer applying the patch
> also needs the full site checked out and configured to build.
This is not true. You should just be able to check out, apply patch, 
commit and use the CMS tooling to verify.
> I think
> that process could be improved on, but that would need changes in CMS
> a) to allow anyone to make changes in a sandbox and create a patch for
> a committer b) for a committer to be able to take that patch and apply
> it.
>
> So I don't think the patch process doesn't work (unless you can
> elaborate), just that it's long winded.
>
>> (If we can identify a better way of submitting patches, of course, what
>> we'll need is someone to submit an patch for our docs pages with
>> instructions. :) )
>>
>> Holly
>>
>>
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>>
>>
>>
>>


Re: Permissions for changing the web site

Posted by Jeremy Hughes <hu...@apache.org>.
Charles, thank you.

I think we need a procedure for everyone without an Apache ID to
submit patches. Giving non-Aries committers commit privs would just
put off figuring this out. So all the time you're submitting patches
we can fine tune the process.

Also, I think if we were to give all people with Apache IDs privs to
change the site we would be creating a two tier system of 'karma' (bad
IMO) - which would be: submit code patches and/or doc patches then get
voted in as commiter vs use your Apache ID to change the Aries site,
make good contributions, but then have to be voted in as a committer
to change code.

Cheers,
Jeremy

On 25 March 2011 17:15, Charles Moulliard <cm...@gmail.com> wrote:
> Ok. I will continue to provide patches.
>
> I will work on pages about Blueprint to demystify that and explain in
> more detail options of Aries JPA and Aries Transaction.
>
> On Fri, Mar 25, 2011 at 12:47 PM, zoe slattery <zo...@gmail.com> wrote:
>> On 25/03/2011 11:33, Charles Moulliard wrote:
>>>
>>> Which decision has been taken finally to allow to provide
>>> content/documentation and commit it into Aries project ?
>>
>> No decision afaik.
>>
>> Might I suggest that you continue to submit patches? That will at some stage
>> force a
>> discussion on commit rights. I think what you are doing is extremely
>> valuable.
>>
>> Zoe
>>>
>>> On Fri, Mar 18, 2011 at 5:51 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>>>>
>>>> What does the CMS bring to scalate ?  Maybe I'm missing something, but
>>>> I don't really see the value of a webapp that simply do the commit on
>>>> your behalf.  Though I haven't used it a lot, so I'm sure I'm missing
>>>> a lot of nice features here.
>>>> Using pure scalate, you can have a live editing view of the website
>>>> using scalate by running mvn:jetty -Plive in Karaf for example.   If
>>>> you use chrome, you can even plug in livereload so that the pages are
>>>> updated automatically.  When you want the changes to go live, you can
>>>> mvn scalate:deploy, and that's all.
>>>>
>>>>
>>>> On Fri, Mar 18, 2011 at 17:23, Daniel Kulp<dk...@apache.org>  wrote:
>>>>>
>>>>> On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
>>>>>>
>>>>>> On 18/03/2011 13:44, Charles Moulliard wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> My question is perhaps stupid but why don't we use wiki/confluence
>>>>>>> like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
>>>>>>> confluence is not the most powerful tool to be used but it helps a
>>>>>>> lot. Additionialy, we use maven plugin to generate Camel manual. This
>>>>>>> process has been enhanced with Apache Karaf project using
>>>>>>> scala/scalate to generate the manual in PDF, HTML format. In this
>>>>>>> case, the pages of the manual are edited manually (outside of the web
>>>>>>> site) and this process is governed by SVN
>>>>>>
>>>>>> See here: http://www.apache.org/dev/cms.html
>>>>>>
>>>>>> The short summary is that confluence will not be supported and any
>>>>>> projects using it should be moving to CMS which is actually a lot
>>>>>> bettter :-)
>>>>>
>>>>> "A lot better" is certainly subjective.   I wouldn't agree with it.  :-)
>>>>> The markdown syntax of the CMS certainly is a step backwords compared to
>>>>> the
>>>>> Confluence syntax.
>>>>>
>>>>> What I kind of keep hoping for is that one of the Scalate experts would
>>>>> step
>>>>> up and wire Scalate into the CMS (write an extension mapper thing for
>>>>> the cms)
>>>>> that would allow using Scalate with the CMS.   Thus, we could retain the
>>>>> use
>>>>> of the Confluence syntax (Scalate has a templating thing for that), but
>>>>> still
>>>>> be able to use the CMS.
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Charles
>>>>>>>
>>>>>>> On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>
>>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Jeremy wrote:
>>>>>>>>>
>>>>>>>>> It's very easy for committers to make changes using CMS, but for
>>>>>>>>> contributors (inlcuding those who don't have an ASF id) they have to
>>>>>>>>> check out the site, configure the build env, build it (instructions
>>>>>>>>> on
>>>>>>>>> our site) and submit a patch. Then the committer applying the patch
>>>>>>>>> also needs the full site checked out and configured to build. I
>>>>>>>>> think
>>>>>>>>> that process could be improved on, but that would need changes in
>>>>>>>>> CMS
>>>>>>>>> a) to allow anyone to make changes in a sandbox and create a patch
>>>>>>>>> for
>>>>>>>>> a committer b) for a committer to be able to take that patch and
>>>>>>>>> apply
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> So I don't think the patch process doesn't work (unless you can
>>>>>>>>> elaborate), just that it's long winded.
>>>>>>>>
>>>>>>>> Patching documentation is not something I have direct experience of
>>>>>>>> myself, so I should avoid getting myself in too deep into this
>>>>>>>> discussion! I was judging by Alasdair and Charles's comments at the
>>>>>>>> end
>>>>>>>> of
>>>>>>>> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>>>>>>>> Charles is probably better placed to comment than me.
>>>>>>>>
>>>>>>>> It appears Alasdair tried several times to merge in Charles's patch,
>>>>>>>> sent it back to Charles to see if Charles could do anything, and then
>>>>>>>> ended up manually merging in Charles's changes, with the comment "I
>>>>>>>> guess the diff capability in Apache CMS is broken, or not intended
>>>>>>>> for
>>>>>>>> creating patches. "
>>>>>>>>
>>>>>>>> If we have to do that every time it won't be a great experience for
>>>>>>>> either committer or patch-provider. But maybe there's a better way.
>>>>>>>>
>>>>>>>> Holly
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Unless stated otherwise above:
>>>>>>>> IBM United Kingdom Limited - Registered in England and Wales with
>>>>>>>> number
>>>>>>>> 741598.
>>>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>>>>>>> PO6
>>>>>>>> 3AU
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://dankulp.com/blog
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>
>>
>

Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Ok. I will continue to provide patches.

I will work on pages about Blueprint to demystify that and explain in
more detail options of Aries JPA and Aries Transaction.

On Fri, Mar 25, 2011 at 12:47 PM, zoe slattery <zo...@gmail.com> wrote:
> On 25/03/2011 11:33, Charles Moulliard wrote:
>>
>> Which decision has been taken finally to allow to provide
>> content/documentation and commit it into Aries project ?
>
> No decision afaik.
>
> Might I suggest that you continue to submit patches? That will at some stage
> force a
> discussion on commit rights. I think what you are doing is extremely
> valuable.
>
> Zoe
>>
>> On Fri, Mar 18, 2011 at 5:51 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>>>
>>> What does the CMS bring to scalate ?  Maybe I'm missing something, but
>>> I don't really see the value of a webapp that simply do the commit on
>>> your behalf.  Though I haven't used it a lot, so I'm sure I'm missing
>>> a lot of nice features here.
>>> Using pure scalate, you can have a live editing view of the website
>>> using scalate by running mvn:jetty -Plive in Karaf for example.   If
>>> you use chrome, you can even plug in livereload so that the pages are
>>> updated automatically.  When you want the changes to go live, you can
>>> mvn scalate:deploy, and that's all.
>>>
>>>
>>> On Fri, Mar 18, 2011 at 17:23, Daniel Kulp<dk...@apache.org>  wrote:
>>>>
>>>> On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
>>>>>
>>>>> On 18/03/2011 13:44, Charles Moulliard wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> My question is perhaps stupid but why don't we use wiki/confluence
>>>>>> like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
>>>>>> confluence is not the most powerful tool to be used but it helps a
>>>>>> lot. Additionialy, we use maven plugin to generate Camel manual. This
>>>>>> process has been enhanced with Apache Karaf project using
>>>>>> scala/scalate to generate the manual in PDF, HTML format. In this
>>>>>> case, the pages of the manual are edited manually (outside of the web
>>>>>> site) and this process is governed by SVN
>>>>>
>>>>> See here: http://www.apache.org/dev/cms.html
>>>>>
>>>>> The short summary is that confluence will not be supported and any
>>>>> projects using it should be moving to CMS which is actually a lot
>>>>> bettter :-)
>>>>
>>>> "A lot better" is certainly subjective.   I wouldn't agree with it.  :-)
>>>> The markdown syntax of the CMS certainly is a step backwords compared to
>>>> the
>>>> Confluence syntax.
>>>>
>>>> What I kind of keep hoping for is that one of the Scalate experts would
>>>> step
>>>> up and wire Scalate into the CMS (write an extension mapper thing for
>>>> the cms)
>>>> that would allow using Scalate with the CMS.   Thus, we could retain the
>>>> use
>>>> of the Confluence syntax (Scalate has a templating thing for that), but
>>>> still
>>>> be able to use the CMS.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Charles
>>>>>>
>>>>>> On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>
>>>>
>>>> wrote:
>>>>>>>
>>>>>>> Jeremy wrote:
>>>>>>>>
>>>>>>>> It's very easy for committers to make changes using CMS, but for
>>>>>>>> contributors (inlcuding those who don't have an ASF id) they have to
>>>>>>>> check out the site, configure the build env, build it (instructions
>>>>>>>> on
>>>>>>>> our site) and submit a patch. Then the committer applying the patch
>>>>>>>> also needs the full site checked out and configured to build. I
>>>>>>>> think
>>>>>>>> that process could be improved on, but that would need changes in
>>>>>>>> CMS
>>>>>>>> a) to allow anyone to make changes in a sandbox and create a patch
>>>>>>>> for
>>>>>>>> a committer b) for a committer to be able to take that patch and
>>>>>>>> apply
>>>>>>>> it.
>>>>>>>>
>>>>>>>> So I don't think the patch process doesn't work (unless you can
>>>>>>>> elaborate), just that it's long winded.
>>>>>>>
>>>>>>> Patching documentation is not something I have direct experience of
>>>>>>> myself, so I should avoid getting myself in too deep into this
>>>>>>> discussion! I was judging by Alasdair and Charles's comments at the
>>>>>>> end
>>>>>>> of
>>>>>>> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>>>>>>> Charles is probably better placed to comment than me.
>>>>>>>
>>>>>>> It appears Alasdair tried several times to merge in Charles's patch,
>>>>>>> sent it back to Charles to see if Charles could do anything, and then
>>>>>>> ended up manually merging in Charles's changes, with the comment "I
>>>>>>> guess the diff capability in Apache CMS is broken, or not intended
>>>>>>> for
>>>>>>> creating patches. "
>>>>>>>
>>>>>>> If we have to do that every time it won't be a great experience for
>>>>>>> either committer or patch-provider. But maybe there's a better way.
>>>>>>>
>>>>>>> Holly
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Unless stated otherwise above:
>>>>>>> IBM United Kingdom Limited - Registered in England and Wales with
>>>>>>> number
>>>>>>> 741598.
>>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>>>>>> PO6
>>>>>>> 3AU
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>
>

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 25/03/2011 11:33, Charles Moulliard wrote:
> Which decision has been taken finally to allow to provide
> content/documentation and commit it into Aries project ?
No decision afaik.

Might I suggest that you continue to submit patches? That will at some 
stage force a
discussion on commit rights. I think what you are doing is extremely 
valuable.

Zoe
> On Fri, Mar 18, 2011 at 5:51 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>> What does the CMS bring to scalate ?  Maybe I'm missing something, but
>> I don't really see the value of a webapp that simply do the commit on
>> your behalf.  Though I haven't used it a lot, so I'm sure I'm missing
>> a lot of nice features here.
>> Using pure scalate, you can have a live editing view of the website
>> using scalate by running mvn:jetty -Plive in Karaf for example.   If
>> you use chrome, you can even plug in livereload so that the pages are
>> updated automatically.  When you want the changes to go live, you can
>> mvn scalate:deploy, and that's all.
>>
>>
>> On Fri, Mar 18, 2011 at 17:23, Daniel Kulp<dk...@apache.org>  wrote:
>>> On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
>>>> On 18/03/2011 13:44, Charles Moulliard wrote:
>>>>> Hi,
>>>>>
>>>>> My question is perhaps stupid but why don't we use wiki/confluence
>>>>> like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
>>>>> confluence is not the most powerful tool to be used but it helps a
>>>>> lot. Additionialy, we use maven plugin to generate Camel manual. This
>>>>> process has been enhanced with Apache Karaf project using
>>>>> scala/scalate to generate the manual in PDF, HTML format. In this
>>>>> case, the pages of the manual are edited manually (outside of the web
>>>>> site) and this process is governed by SVN
>>>> See here: http://www.apache.org/dev/cms.html
>>>>
>>>> The short summary is that confluence will not be supported and any
>>>> projects using it should be moving to CMS which is actually a lot
>>>> bettter :-)
>>> "A lot better" is certainly subjective.   I wouldn't agree with it.  :-)
>>> The markdown syntax of the CMS certainly is a step backwords compared to the
>>> Confluence syntax.
>>>
>>> What I kind of keep hoping for is that one of the Scalate experts would step
>>> up and wire Scalate into the CMS (write an extension mapper thing for the cms)
>>> that would allow using Scalate with the CMS.   Thus, we could retain the use
>>> of the Confluence syntax (Scalate has a templating thing for that), but still
>>> be able to use the CMS.
>>>
>>>
>>> Dan
>>>
>>>
>>>>> Regards,
>>>>>
>>>>> Charles
>>>>>
>>>>> On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>
>>> wrote:
>>>>>> Jeremy wrote:
>>>>>>> It's very easy for committers to make changes using CMS, but for
>>>>>>> contributors (inlcuding those who don't have an ASF id) they have to
>>>>>>> check out the site, configure the build env, build it (instructions on
>>>>>>> our site) and submit a patch. Then the committer applying the patch
>>>>>>> also needs the full site checked out and configured to build. I think
>>>>>>> that process could be improved on, but that would need changes in CMS
>>>>>>> a) to allow anyone to make changes in a sandbox and create a patch for
>>>>>>> a committer b) for a committer to be able to take that patch and apply
>>>>>>> it.
>>>>>>>
>>>>>>> So I don't think the patch process doesn't work (unless you can
>>>>>>> elaborate), just that it's long winded.
>>>>>> Patching documentation is not something I have direct experience of
>>>>>> myself, so I should avoid getting myself in too deep into this
>>>>>> discussion! I was judging by Alasdair and Charles's comments at the end
>>>>>> of
>>>>>> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>>>>>> Charles is probably better placed to comment than me.
>>>>>>
>>>>>> It appears Alasdair tried several times to merge in Charles's patch,
>>>>>> sent it back to Charles to see if Charles could do anything, and then
>>>>>> ended up manually merging in Charles's changes, with the comment "I
>>>>>> guess the diff capability in Apache CMS is broken, or not intended for
>>>>>> creating patches. "
>>>>>>
>>>>>> If we have to do that every time it won't be a great experience for
>>>>>> either committer or patch-provider. But maybe there's a better way.
>>>>>>
>>>>>> Holly
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Unless stated otherwise above:
>>>>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>>>>> 741598.
>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>>>>>> 3AU
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>


Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Which decision has been taken finally to allow to provide
content/documentation and commit it into Aries project ?

On Fri, Mar 18, 2011 at 5:51 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> What does the CMS bring to scalate ?  Maybe I'm missing something, but
> I don't really see the value of a webapp that simply do the commit on
> your behalf.  Though I haven't used it a lot, so I'm sure I'm missing
> a lot of nice features here.
> Using pure scalate, you can have a live editing view of the website
> using scalate by running mvn:jetty -Plive in Karaf for example.   If
> you use chrome, you can even plug in livereload so that the pages are
> updated automatically.  When you want the changes to go live, you can
> mvn scalate:deploy, and that's all.
>
>
> On Fri, Mar 18, 2011 at 17:23, Daniel Kulp <dk...@apache.org> wrote:
>> On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
>>> On 18/03/2011 13:44, Charles Moulliard wrote:
>>> > Hi,
>>> >
>>> > My question is perhaps stupid but why don't we use wiki/confluence
>>> > like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
>>> > confluence is not the most powerful tool to be used but it helps a
>>> > lot. Additionialy, we use maven plugin to generate Camel manual. This
>>> > process has been enhanced with Apache Karaf project using
>>> > scala/scalate to generate the manual in PDF, HTML format. In this
>>> > case, the pages of the manual are edited manually (outside of the web
>>> > site) and this process is governed by SVN
>>>
>>> See here: http://www.apache.org/dev/cms.html
>>>
>>> The short summary is that confluence will not be supported and any
>>> projects using it should be moving to CMS which is actually a lot
>>> bettter :-)
>>
>> "A lot better" is certainly subjective.   I wouldn't agree with it.  :-)
>> The markdown syntax of the CMS certainly is a step backwords compared to the
>> Confluence syntax.
>>
>> What I kind of keep hoping for is that one of the Scalate experts would step
>> up and wire Scalate into the CMS (write an extension mapper thing for the cms)
>> that would allow using Scalate with the CMS.   Thus, we could retain the use
>> of the Confluence syntax (Scalate has a templating thing for that), but still
>> be able to use the CMS.
>>
>>
>> Dan
>>
>>
>>>
>>> > Regards,
>>> >
>>> > Charles
>>> >
>>> > On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>
>> wrote:
>>> >> Jeremy wrote:
>>> >>> It's very easy for committers to make changes using CMS, but for
>>> >>> contributors (inlcuding those who don't have an ASF id) they have to
>>> >>> check out the site, configure the build env, build it (instructions on
>>> >>> our site) and submit a patch. Then the committer applying the patch
>>> >>> also needs the full site checked out and configured to build. I think
>>> >>> that process could be improved on, but that would need changes in CMS
>>> >>> a) to allow anyone to make changes in a sandbox and create a patch for
>>> >>> a committer b) for a committer to be able to take that patch and apply
>>> >>> it.
>>> >>>
>>> >>> So I don't think the patch process doesn't work (unless you can
>>> >>> elaborate), just that it's long winded.
>>> >>
>>> >> Patching documentation is not something I have direct experience of
>>> >> myself, so I should avoid getting myself in too deep into this
>>> >> discussion! I was judging by Alasdair and Charles's comments at the end
>>> >> of
>>> >> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>>> >> Charles is probably better placed to comment than me.
>>> >>
>>> >> It appears Alasdair tried several times to merge in Charles's patch,
>>> >> sent it back to Charles to see if Charles could do anything, and then
>>> >> ended up manually merging in Charles's changes, with the comment "I
>>> >> guess the diff capability in Apache CMS is broken, or not intended for
>>> >> creating patches. "
>>> >>
>>> >> If we have to do that every time it won't be a great experience for
>>> >> either committer or patch-provider. But maybe there's a better way.
>>> >>
>>> >> Holly
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Unless stated otherwise above:
>>> >> IBM United Kingdom Limited - Registered in England and Wales with number
>>> >> 741598.
>>> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>>> >> 3AU
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

Re: Permissions for changing the web site

Posted by Guillaume Nodet <gn...@gmail.com>.
What does the CMS bring to scalate ?  Maybe I'm missing something, but
I don't really see the value of a webapp that simply do the commit on
your behalf.  Though I haven't used it a lot, so I'm sure I'm missing
a lot of nice features here.
Using pure scalate, you can have a live editing view of the website
using scalate by running mvn:jetty -Plive in Karaf for example.   If
you use chrome, you can even plug in livereload so that the pages are
updated automatically.  When you want the changes to go live, you can
mvn scalate:deploy, and that's all.


On Fri, Mar 18, 2011 at 17:23, Daniel Kulp <dk...@apache.org> wrote:
> On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
>> On 18/03/2011 13:44, Charles Moulliard wrote:
>> > Hi,
>> >
>> > My question is perhaps stupid but why don't we use wiki/confluence
>> > like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
>> > confluence is not the most powerful tool to be used but it helps a
>> > lot. Additionialy, we use maven plugin to generate Camel manual. This
>> > process has been enhanced with Apache Karaf project using
>> > scala/scalate to generate the manual in PDF, HTML format. In this
>> > case, the pages of the manual are edited manually (outside of the web
>> > site) and this process is governed by SVN
>>
>> See here: http://www.apache.org/dev/cms.html
>>
>> The short summary is that confluence will not be supported and any
>> projects using it should be moving to CMS which is actually a lot
>> bettter :-)
>
> "A lot better" is certainly subjective.   I wouldn't agree with it.  :-)
> The markdown syntax of the CMS certainly is a step backwords compared to the
> Confluence syntax.
>
> What I kind of keep hoping for is that one of the Scalate experts would step
> up and wire Scalate into the CMS (write an extension mapper thing for the cms)
> that would allow using Scalate with the CMS.   Thus, we could retain the use
> of the Confluence syntax (Scalate has a templating thing for that), but still
> be able to use the CMS.
>
>
> Dan
>
>
>>
>> > Regards,
>> >
>> > Charles
>> >
>> > On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>
> wrote:
>> >> Jeremy wrote:
>> >>> It's very easy for committers to make changes using CMS, but for
>> >>> contributors (inlcuding those who don't have an ASF id) they have to
>> >>> check out the site, configure the build env, build it (instructions on
>> >>> our site) and submit a patch. Then the committer applying the patch
>> >>> also needs the full site checked out and configured to build. I think
>> >>> that process could be improved on, but that would need changes in CMS
>> >>> a) to allow anyone to make changes in a sandbox and create a patch for
>> >>> a committer b) for a committer to be able to take that patch and apply
>> >>> it.
>> >>>
>> >>> So I don't think the patch process doesn't work (unless you can
>> >>> elaborate), just that it's long winded.
>> >>
>> >> Patching documentation is not something I have direct experience of
>> >> myself, so I should avoid getting myself in too deep into this
>> >> discussion! I was judging by Alasdair and Charles's comments at the end
>> >> of
>> >> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>> >> Charles is probably better placed to comment than me.
>> >>
>> >> It appears Alasdair tried several times to merge in Charles's patch,
>> >> sent it back to Charles to see if Charles could do anything, and then
>> >> ended up manually merging in Charles's changes, with the comment "I
>> >> guess the diff capability in Apache CMS is broken, or not intended for
>> >> creating patches. "
>> >>
>> >> If we have to do that every time it won't be a great experience for
>> >> either committer or patch-provider. But maybe there's a better way.
>> >>
>> >> Holly
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Unless stated otherwise above:
>> >> IBM United Kingdom Limited - Registered in England and Wales with number
>> >> 741598.
>> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> >> 3AU
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Permissions for changing the web site

Posted by Daniel Kulp <dk...@apache.org>.
On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
> On 18/03/2011 13:44, Charles Moulliard wrote:
> > Hi,
> > 
> > My question is perhaps stupid but why don't we use wiki/confluence
> > like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
> > confluence is not the most powerful tool to be used but it helps a
> > lot. Additionialy, we use maven plugin to generate Camel manual. This
> > process has been enhanced with Apache Karaf project using
> > scala/scalate to generate the manual in PDF, HTML format. In this
> > case, the pages of the manual are edited manually (outside of the web
> > site) and this process is governed by SVN
> 
> See here: http://www.apache.org/dev/cms.html
> 
> The short summary is that confluence will not be supported and any
> projects using it should be moving to CMS which is actually a lot
> bettter :-)
 
"A lot better" is certainly subjective.   I wouldn't agree with it.  :-)     
The markdown syntax of the CMS certainly is a step backwords compared to the 
Confluence syntax.

What I kind of keep hoping for is that one of the Scalate experts would step 
up and wire Scalate into the CMS (write an extension mapper thing for the cms) 
that would allow using Scalate with the CMS.   Thus, we could retain the use 
of the Confluence syntax (Scalate has a templating thing for that), but still 
be able to use the CMS.


Dan


> 
> > Regards,
> > 
> > Charles
> > 
> > On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>  
wrote:
> >> Jeremy wrote:
> >>> It's very easy for committers to make changes using CMS, but for
> >>> contributors (inlcuding those who don't have an ASF id) they have to
> >>> check out the site, configure the build env, build it (instructions on
> >>> our site) and submit a patch. Then the committer applying the patch
> >>> also needs the full site checked out and configured to build. I think
> >>> that process could be improved on, but that would need changes in CMS
> >>> a) to allow anyone to make changes in a sandbox and create a patch for
> >>> a committer b) for a committer to be able to take that patch and apply
> >>> it.
> >>> 
> >>> So I don't think the patch process doesn't work (unless you can
> >>> elaborate), just that it's long winded.
> >> 
> >> Patching documentation is not something I have direct experience of
> >> myself, so I should avoid getting myself in too deep into this
> >> discussion! I was judging by Alasdair and Charles's comments at the end
> >> of
> >> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
> >> Charles is probably better placed to comment than me.
> >> 
> >> It appears Alasdair tried several times to merge in Charles's patch,
> >> sent it back to Charles to see if Charles could do anything, and then
> >> ended up manually merging in Charles's changes, with the comment "I
> >> guess the diff capability in Apache CMS is broken, or not intended for
> >> creating patches. "
> >> 
> >> If we have to do that every time it won't be a great experience for
> >> either committer or patch-provider. But maybe there's a better way.
> >> 
> >> Holly
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with number
> >> 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> >> 3AU

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
On 18/03/2011 13:44, Charles Moulliard wrote:
> Hi,
>
> My question is perhaps stupid but why don't we use wiki/confluence
> like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
> confluence is not the most powerful tool to be used but it helps a
> lot. Additionialy, we use maven plugin to generate Camel manual. This
> process has been enhanced with Apache Karaf project using
> scala/scalate to generate the manual in PDF, HTML format. In this
> case, the pages of the manual are edited manually (outside of the web
> site) and this process is governed by SVN

See here: http://www.apache.org/dev/cms.html

The short summary is that confluence will not be supported and any 
projects using it should be moving to CMS which is actually a lot 
bettter :-)
> Regards,
>
> Charles
>
> On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<cu...@uk.ibm.com>  wrote:
>> Jeremy wrote:
>>
>>> It's very easy for committers to make changes using CMS, but for
>>> contributors (inlcuding those who don't have an ASF id) they have to
>>> check out the site, configure the build env, build it (instructions on
>>> our site) and submit a patch. Then the committer applying the patch
>>> also needs the full site checked out and configured to build. I think
>>> that process could be improved on, but that would need changes in CMS
>>> a) to allow anyone to make changes in a sandbox and create a patch for
>>> a committer b) for a committer to be able to take that patch and apply
>>> it.
>>>
>>> So I don't think the patch process doesn't work (unless you can
>>> elaborate), just that it's long winded.
>> Patching documentation is not something I have direct experience of
>> myself, so I should avoid getting myself in too deep into this discussion!
>> I was judging by Alasdair and Charles's comments at the end of
>> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
>> Charles is probably better placed to comment than me.
>>
>> It appears Alasdair tried several times to merge in Charles's patch, sent
>> it back to Charles to see if Charles could do anything, and then ended up
>> manually merging in Charles's changes, with the comment "I guess the diff
>> capability in Apache CMS is broken, or not intended for creating patches.
>> "
>>
>> If we have to do that every time it won't be a great experience for either
>> committer or patch-provider. But maybe there's a better way.
>>
>> Holly
>>
>>
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>>
>>
>>
>>


Re: Permissions for changing the web site

Posted by Charles Moulliard <cm...@gmail.com>.
Hi,

My question is perhaps stupid but why don't we use wiki/confluence
like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
confluence is not the most powerful tool to be used but it helps a
lot. Additionialy, we use maven plugin to generate Camel manual. This
process has been enhanced with Apache Karaf project using
scala/scalate to generate the manual in PDF, HTML format. In this
case, the pages of the manual are edited manually (outside of the web
site) and this process is governed by SVN.

Regards,

Charles

On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins <cu...@uk.ibm.com> wrote:
> Jeremy wrote:
>
>> It's very easy for committers to make changes using CMS, but for
>> contributors (inlcuding those who don't have an ASF id) they have to
>> check out the site, configure the build env, build it (instructions on
>> our site) and submit a patch. Then the committer applying the patch
>> also needs the full site checked out and configured to build. I think
>> that process could be improved on, but that would need changes in CMS
>> a) to allow anyone to make changes in a sandbox and create a patch for
>> a committer b) for a committer to be able to take that patch and apply
>> it.
>>
>> So I don't think the patch process doesn't work (unless you can
>> elaborate), just that it's long winded.
>
> Patching documentation is not something I have direct experience of
> myself, so I should avoid getting myself in too deep into this discussion!
> I was judging by Alasdair and Charles's comments at the end of
> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
> Charles is probably better placed to comment than me.
>
> It appears Alasdair tried several times to merge in Charles's patch, sent
> it back to Charles to see if Charles could do anything, and then ended up
> manually merging in Charles's changes, with the comment "I guess the diff
> capability in Apache CMS is broken, or not intended for creating patches.
> "
>
> If we have to do that every time it won't be a great experience for either
> committer or patch-provider. But maybe there's a better way.
>
> Holly
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>

Re: Permissions for changing the web site

Posted by Holly Cummins <cu...@uk.ibm.com>.
Jeremy wrote:
 
> It's very easy for committers to make changes using CMS, but for
> contributors (inlcuding those who don't have an ASF id) they have to
> check out the site, configure the build env, build it (instructions on
> our site) and submit a patch. Then the committer applying the patch
> also needs the full site checked out and configured to build. I think
> that process could be improved on, but that would need changes in CMS
> a) to allow anyone to make changes in a sandbox and create a patch for
> a committer b) for a committer to be able to take that patch and apply
> it.
> 
> So I don't think the patch process doesn't work (unless you can
> elaborate), just that it's long winded.

Patching documentation is not something I have direct experience of 
myself, so I should avoid getting myself in too deep into this discussion! 
I was judging by Alasdair and Charles's comments at the end of 
https://issues.apache.org/jira/browse/aries-597, and so Alasdair or 
Charles is probably better placed to comment than me. 

It appears Alasdair tried several times to merge in Charles's patch, sent 
it back to Charles to see if Charles could do anything, and then ended up 
manually merging in Charles's changes, with the comment "I guess the diff 
capability in Apache CMS is broken, or not intended for creating patches. 
"

If we have to do that every time it won't be a great experience for either 
committer or patch-provider. But maybe there's a better way.

Holly
 





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






Re: Permissions for changing the web site

Posted by Jeremy Hughes <jp...@gmail.com>.
On 18 March 2011 11:22, Holly Cummins <cu...@uk.ibm.com> wrote:
> zoe slattery <zo...@gmail.com> wrote on 03/18/2011 10:28:32 AM:
>
>> +1 I would like to see committers elected because of doc contributions
>
> [cut for length]
>
> The downside of this is that Alasdair's and Charles's experience of
> submitting and applying a patch doesn't seem to have been very smooth.
> It's hard to say if that's because the CMS process just doesn't work well
> for patches, or they just did it wrong. :)
>
> If the patch process genuinely doesn't work so well for doc contributions
> we may decide that facilitating doc contributions is more important than
> facilitating new committers - or we may not, of course, since enabling
> doc-driven committers sounds like a good thing to me as well.

It's very easy for committers to make changes using CMS, but for
contributors (inlcuding those who don't have an ASF id) they have to
check out the site, configure the build env, build it (instructions on
our site) and submit a patch. Then the committer applying the patch
also needs the full site checked out and configured to build. I think
that process could be improved on, but that would need changes in CMS
a) to allow anyone to make changes in a sandbox and create a patch for
a committer b) for a committer to be able to take that patch and apply
it.

So I don't think the patch process doesn't work (unless you can
elaborate), just that it's long winded.

>
> (If we can identify a better way of submitting patches, of course, what
> we'll need is someone to submit an patch for our docs pages with
> instructions. :) )
>
> Holly
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>

Re: Permissions for changing the web site

Posted by Holly Cummins <cu...@uk.ibm.com>.
zoe slattery <zo...@gmail.com> wrote on 03/18/2011 10:28:32 AM:

> +1 I would like to see committers elected because of doc contributions

[cut for length]

The downside of this is that Alasdair's and Charles's experience of 
submitting and applying a patch doesn't seem to have been very smooth. 
It's hard to say if that's because the CMS process just doesn't work well 
for patches, or they just did it wrong. :) 

If the patch process genuinely doesn't work so well for doc contributions 
we may decide that facilitating doc contributions is more important than 
facilitating new committers - or we may not, of course, since enabling 
doc-driven committers sounds like a good thing to me as well.

(If we can identify a better way of submitting patches, of course, what 
we'll need is someone to submit an patch for our docs pages with 
instructions. :) )

Holly






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






Re: Permissions for changing the web site

Posted by zoe slattery <zo...@gmail.com>.
+1 I would like to see committers elected because of doc contributions
> Another way too look at that would be that they now need to provide
> patches, which mean they should get voted as committer even faster.
> People can become committers without contributing *code* fwiw.
>
> On Fri, Mar 18, 2011 at 10:46, Alasdair Nottingham<no...@apache.org>  wrote:
>> Hi,
>>
>> I was wondering if it was possible to do one of the following things:
>>
>> 1. Allow all Apache Committers to make changes to our website.
>> 2. To allow a subset of Apache Committers, who aren't aries committers
>> to modify our website.
>>
>> Because this is all in subversion I don't know what is and isn't
>> possible, but it would be nice I think if people who aren't aries
>> committers could contribute to the website. This used to be possible
>> with confluence.
>>
>> Thoughts?
>> Alasdair
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>


Re: Permissions for changing the web site

Posted by Guillaume Nodet <gn...@gmail.com>.
Another way too look at that would be that they now need to provide
patches, which mean they should get voted as committer even faster.
People can become committers without contributing *code* fwiw.

On Fri, Mar 18, 2011 at 10:46, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> I was wondering if it was possible to do one of the following things:
>
> 1. Allow all Apache Committers to make changes to our website.
> 2. To allow a subset of Apache Committers, who aren't aries committers
> to modify our website.
>
> Because this is all in subversion I don't know what is and isn't
> possible, but it would be nice I think if people who aren't aries
> committers could contribute to the website. This used to be possible
> with confluence.
>
> Thoughts?
> Alasdair
>
> --
> Alasdair Nottingham
> not@apache.org
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com