You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Henryk Konsek <he...@gmail.com> on 2012/09/15 22:27:19 UTC
[VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Hi,
While working on the camel-extra stuff together with Christian, I've
risen the proposal of removing the 'Issues' tab [1] from the Camel
extra page. Instead of Google Issues tracker, we could put the
information on the Camel Extra home page, telling that one should use
Camel Jira [2] to report the issues. This will make maintenance of the
Camel Extra issues a bit easier.
Code base of Camel extra is hosted on the Google Project due to the
licensing reasons. Nothing however forces us to keep Camel Extra
issues in the Google Issue Tracker. In fact, we handle the majority of
the extra-related issues in the regular Camel Jira. We also got
release versions set up in Jira, so we can assign tasks to the given
release of Camel.
We can easily migrate issues from Camel Extra Google Issues Tracker to
Jira (I can handle this) and hide the 'Issues' panel (you can do it in
the Google Project administration setup.
Christian suggested me that the community should decide about the
future of the issues at Google Tracker, so I decided to raise this
voting. I got no binding vote anyway, so decision is up to you.
However as a person involved in the Camel Extra development and
maintenance I strongly endorse this idea :} .
Regards.
[1] http://code.google.com/a/apache-extras.org/p/camel-extra/issues/list
[2] https://issues.apache.org/jira/browse/CAMEL
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Hadrian Zbarcea <hz...@gmail.com>.
-1
Yes it would be nice/convenient. However, camel-extra is an external
project. AFAIK, the ASF is not providing hosting services for external
projects.
Hadrian
On 09/24/2012 05:12 PM, Henryk Konsek wrote:
>> +1 if we make it simple and easy for our Camel extra users to find the
>> Apache Camel JIRA.
>
> Anybody else wants to express their opinion? If not, can we assume it
> is a quiet consensus?
>
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
Hello Henryk!
Please find my comments inline...
Best,
Christian
On Sat, Sep 29, 2012 at 10:22 PM, Henryk Konsek <he...@gmail.com> wrote:
> > I assume that the outcome of the discussion at [1] will be we cannot use
> > the Apache mailing list for mail notifications from Apache Extra / Camel
> > Extra.
> > I'm not sure what the outcome will be for the documentation, we already
> > have in the Apache Confluence WIKI for Camel Extra components. May be we
> > have to move it to Camel Extra. But we will wait for the final
> decision...
>
> From my point of view, Camel Extra needs to be settled somewhere. At
> Apache or not at Apache.
>
Yes. That's what we did in the last weeks at Camel Extra with good success.
>
> My pain about the Camel Extra is that it is not equally maintained as
> regular Camel. I endorse Camel to my clients and then I need to
> explain them why Hibernate or Db4o components are not released with
> the latest Camel.
This is understandable. Than it's your job to explain that camel-hibernate
and camel-db40 are maintained by a different community. And this made a
good progress in the last weeks. So hopefully we will see the Camel Extra
releases more regularly than in the past.
> All clients/companies I worked for (including the
> one I currently work for) don't care if they use Apache or LGPL
> licensed jars. They don't get the ASF projects policies - they just
> want to use the Camel to integrate their stuff.
May be this is a bad attitude. What, if you use one of the many other Camel
components hosted at GitHub or somewhere else? As Hadrian mentioned, there
will not be a "one stop for all Camel components" solution. But as
mentioned before, for Canel Extra we made a good progress and I'm sure we
will see Camel Extra releases which are more in sync with the normal Camel
releases.
> From their point of
> view listing Hibernate component as the Camel documentation page [1]
> and then not releasing it's latest version with new version of regular
> Camel means that something is wrong with the release cycle the Camel
> itself.
>
We can make it more clear, that camel-hibernate and other components are
not part of the official Camel release and has to be released later
somewhere else. Or we can move the documentation to Camel Extra...
>
> For me (and other Camel Extra users) the most important thing is to be
> sure that Extra releases are as reliable as Standard Camel releases.
> And are in sync with them.
>
Yes. We are now in a good position to promise this.
>
> If ASF policy tells that Camel Extra stuff is not welcome at Apache
> infrastructure, we will use some other infrastructure. If Extra
> notifications or Jira tickets are problem for Apache infra guys -
> let's screw it and focus on the Camel Extra development itself.
>
It's not the Apache infra guys.
> Have a nice weekend :) .
>
You too.
>
> [1] camel.apache.org/hibernate.html
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
--
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Henryk, it's a legal issue and an important one. It is not arbitrary
that ASF projects cannot use xGPL. And believe it or not, the vast
majority of companies I interacted with do care if it's permissive
licenses or like BSD or MIT or ALv2 or something much more restrictive
like GPL or other licenses. It depends actually on a lot of factors.
Actually one of your responsibilities now as a Camel committer is to
inform yourself on the nuances of oss licensing and ideally educate your
customers as well. There are plenty here who could help.
You've got a valid point on the perception we create by hosting doc like
camel-hibernate on the apache site. I suspect that will be removed soon.
It should. Before that though, we should clarify what its new home
should be.
One more thing, the ASF infra is very accommodating. They will help us
with whatever we need... as long as it makes sense. Hosting services for
camel-extra does not.
Cheers,
Hadrian
On 09/29/2012 04:22 PM, Henryk Konsek wrote:
>> I assume that the outcome of the discussion at [1] will be we cannot use
>> the Apache mailing list for mail notifications from Apache Extra / Camel
>> Extra.
>> I'm not sure what the outcome will be for the documentation, we already
>> have in the Apache Confluence WIKI for Camel Extra components. May be we
>> have to move it to Camel Extra. But we will wait for the final decision...
>
> From my point of view, Camel Extra needs to be settled somewhere. At
> Apache or not at Apache.
>
> My pain about the Camel Extra is that it is not equally maintained as
> regular Camel. I endorse Camel to my clients and then I need to
> explain them why Hibernate or Db4o components are not released with
> the latest Camel. All clients/companies I worked for (including the
> one I currently work for) don't care if they use Apache or LGPL
> licensed jars. They don't get the ASF projects policies - they just
> want to use the Camel to integrate their stuff. From their point of
> view listing Hibernate component as the Camel documentation page [1]
> and then not releasing it's latest version with new version of regular
> Camel means that something is wrong with the release cycle the Camel
> itself.
>
> For me (and other Camel Extra users) the most important thing is to be
> sure that Extra releases are as reliable as Standard Camel releases.
> And are in sync with them.
>
> If ASF policy tells that Camel Extra stuff is not welcome at Apache
> infrastructure, we will use some other infrastructure. If Extra
> notifications or Jira tickets are problem for Apache infra guys -
> let's screw it and focus on the Camel Extra development itself.
>
> Have a nice weekend :) .
>
> [1] camel.apache.org/hibernate.html
>
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Henryk Konsek <he...@gmail.com>.
> I assume that the outcome of the discussion at [1] will be we cannot use
> the Apache mailing list for mail notifications from Apache Extra / Camel
> Extra.
> I'm not sure what the outcome will be for the documentation, we already
> have in the Apache Confluence WIKI for Camel Extra components. May be we
> have to move it to Camel Extra. But we will wait for the final decision...
>From my point of view, Camel Extra needs to be settled somewhere. At
Apache or not at Apache.
My pain about the Camel Extra is that it is not equally maintained as
regular Camel. I endorse Camel to my clients and then I need to
explain them why Hibernate or Db4o components are not released with
the latest Camel. All clients/companies I worked for (including the
one I currently work for) don't care if they use Apache or LGPL
licensed jars. They don't get the ASF projects policies - they just
want to use the Camel to integrate their stuff. From their point of
view listing Hibernate component as the Camel documentation page [1]
and then not releasing it's latest version with new version of regular
Camel means that something is wrong with the release cycle the Camel
itself.
For me (and other Camel Extra users) the most important thing is to be
sure that Extra releases are as reliable as Standard Camel releases.
And are in sync with them.
If ASF policy tells that Camel Extra stuff is not welcome at Apache
infrastructure, we will use some other infrastructure. If Extra
notifications or Jira tickets are problem for Apache infra guys -
let's screw it and focus on the Camel Extra development itself.
Have a nice weekend :) .
[1] camel.apache.org/hibernate.html
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
I assume that the outcome of the discussion at [1] will be we cannot use
the Apache mailing list for mail notifications from Apache Extra / Camel
Extra. But the discussion is still in progress and I will wait for a final
decision (which should be documented somewhere). However, we could also
create a new Forum at Nabble (or somewhere else) and forward the
issue/commit notifications to this forum. Everybody who is interested in
this notification can subscribe to this forum.
I'm not sure what the outcome will be for the documentation, we already
have in the Apache Confluence WIKI for Camel Extra components. May be we
have to move it to Camel Extra. But we will wait for the final decision...
[1]
http://mail-archives.apache.org/mod_mbox/community-dev/201209.mbox/%3CCALvzYd-h4Q=cTEgGqCNEEninhVose8uiGt2gTK22n9cMr_kVyg@mail.gmail.com%3E
Best,
Christian
On Thu, Sep 27, 2012 at 4:10 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I fail to follow the reasoning. There are plenty of camel components
> hosted by other open source projects, various individual github users and
> even by commercial companies.
>
> What does project governance have to do with anything? Bonus question: is
> your expectation that Apache Camel would be a one stop shop for all things
> Camel?
>
> Hint [1] (first two sentences). Camel-extra is not covered and not
> governed the same way.
>
> Hadrian
>
> [1] http://www.apache.org/**foundation/<http://www.apache.org/foundation/>
>
>
>
> On 09/26/2012 03:19 AM, Henryk Konsek wrote:
>
>> - Using Apache JIRA for Camel extra
>>>
>>
>> For now, I'll keep Camel Extra issues in Google Issue tracker. We
>> shouldn't have Camel Extra issues spread around two places. However it
>> will be nice if eventually we could use Jira for that.
>>
>> (- Using Issue notifications on issues@camel.apache.org for issues
>>> raised
>>> in Camel extra)
>>> - Using Commit notifications on commits@camel.apache.org for changes in
>>> Camel extra
>>>
>>
>> Yeah, since from the developer point of view it doesn't matter if
>> somebody commits to Regular Camel or Extra Camel.
>>
>> - Using the Apache Confluence WIKI for Camel extra components
>>>
>>
>> IMHO This is a must. We need uniform documentation format for all
>> Camel stuff. I can't imagine redirecting end users to another
>> documentation site.
>>
>> Camel by nature integrates technologies with various licenses. If we
>> make non-Apache components a second class citizens, will be a
>> second-class integration framework when it comes to non-Apache
>> software. And Mule users will laugh at us :) .
>>
>>
--
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I fail to follow the reasoning. There are plenty of camel components
hosted by other open source projects, various individual github users
and even by commercial companies.
What does project governance have to do with anything? Bonus question:
is your expectation that Apache Camel would be a one stop shop for all
things Camel?
Hint [1] (first two sentences). Camel-extra is not covered and not
governed the same way.
Hadrian
[1] http://www.apache.org/foundation/
On 09/26/2012 03:19 AM, Henryk Konsek wrote:
>> - Using Apache JIRA for Camel extra
>
> For now, I'll keep Camel Extra issues in Google Issue tracker. We
> shouldn't have Camel Extra issues spread around two places. However it
> will be nice if eventually we could use Jira for that.
>
>> (- Using Issue notifications on issues@camel.apache.org for issues raised
>> in Camel extra)
>> - Using Commit notifications on commits@camel.apache.org for changes in
>> Camel extra
>
> Yeah, since from the developer point of view it doesn't matter if
> somebody commits to Regular Camel or Extra Camel.
>
>> - Using the Apache Confluence WIKI for Camel extra components
>
> IMHO This is a must. We need uniform documentation format for all
> Camel stuff. I can't imagine redirecting end users to another
> documentation site.
>
> Camel by nature integrates technologies with various licenses. If we
> make non-Apache components a second class citizens, will be a
> second-class integration framework when it comes to non-Apache
> software. And Mule users will laugh at us :) .
>
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
You can follow the discussion here [1].
[1]
http://mail-archives.apache.org/mod_mbox/community-dev/201209.mbox/%3CCALvzYd-h4Q=cTEgGqCNEEninhVose8uiGt2gTK22n9cMr_kVyg@mail.gmail.com%3E
Best,
Christian
On Wed, Sep 26, 2012 at 1:29 PM, James Carman <ja...@carmanconsulting.com>wrote:
> There is some discussion about this, though. We aren't sure if it's
> the "hosting" or the "management" of the code that is the sticking
> point. The hosting is definitely out, but merely using an external
> source control system and all the other infrastructure/management
> services here at the ASF might not work either. Perhaps we need to
> talk to the board or legal-discuss?
>
> James
>
> On Wed, Sep 26, 2012 at 4:04 AM, Willem jiang <wi...@gmail.com>
> wrote:
> > +1 if we can unify the wiki and issue for Camel and Camel-Extra.
> > The reason which we setup the Camel-Extra project is we cannot host the
> code of GPL license in Apache.
> > I don't think we cannot add the document or issues into Apache Camel due
> to that kind of issue.
> >
> > Any thoughts?
> >
> >
> > On Wednesday, September 26, 2012 at 3:19 PM, Henryk Konsek wrote:
> >
> >> > - Using Apache JIRA for Camel extra
> >>
> >>
> >>
> >> For now, I'll keep Camel Extra issues in Google Issue tracker. We
> >> shouldn't have Camel Extra issues spread around two places. However it
> >> will be nice if eventually we could use Jira for that.
> >>
> >> > (- Using Issue notifications on issues@camel.apache.org (mailto:
> issues@camel.apache.org) for issues raised
> >> > in Camel extra)
> >> > - Using Commit notifications on commits@camel.apache.org (mailto:
> commits@camel.apache.org) for changes in
> >> > Camel extra
> >>
> >>
> >>
> >> Yeah, since from the developer point of view it doesn't matter if
> >> somebody commits to Regular Camel or Extra Camel.
> >>
> >> > - Using the Apache Confluence WIKI for Camel extra components
> >>
> >> IMHO This is a must. We need uniform documentation format for all
> >> Camel stuff. I can't imagine redirecting end users to another
> >> documentation site.
> >>
> >> Camel by nature integrates technologies with various licenses. If we
> >> make non-Apache components a second class citizens, will be a
> >> second-class integration framework when it comes to non-Apache
> >> software. And Mule users will laugh at us :) .
> >>
> >> --
> >> Henryk Konsek
> >> http://henryk-konsek.blogspot.com
> >
> >
> >
>
--
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by James Carman <ja...@carmanconsulting.com>.
There is some discussion about this, though. We aren't sure if it's
the "hosting" or the "management" of the code that is the sticking
point. The hosting is definitely out, but merely using an external
source control system and all the other infrastructure/management
services here at the ASF might not work either. Perhaps we need to
talk to the board or legal-discuss?
James
On Wed, Sep 26, 2012 at 4:04 AM, Willem jiang <wi...@gmail.com> wrote:
> +1 if we can unify the wiki and issue for Camel and Camel-Extra.
> The reason which we setup the Camel-Extra project is we cannot host the code of GPL license in Apache.
> I don't think we cannot add the document or issues into Apache Camel due to that kind of issue.
>
> Any thoughts?
>
>
> On Wednesday, September 26, 2012 at 3:19 PM, Henryk Konsek wrote:
>
>> > - Using Apache JIRA for Camel extra
>>
>>
>>
>> For now, I'll keep Camel Extra issues in Google Issue tracker. We
>> shouldn't have Camel Extra issues spread around two places. However it
>> will be nice if eventually we could use Jira for that.
>>
>> > (- Using Issue notifications on issues@camel.apache.org (mailto:issues@camel.apache.org) for issues raised
>> > in Camel extra)
>> > - Using Commit notifications on commits@camel.apache.org (mailto:commits@camel.apache.org) for changes in
>> > Camel extra
>>
>>
>>
>> Yeah, since from the developer point of view it doesn't matter if
>> somebody commits to Regular Camel or Extra Camel.
>>
>> > - Using the Apache Confluence WIKI for Camel extra components
>>
>> IMHO This is a must. We need uniform documentation format for all
>> Camel stuff. I can't imagine redirecting end users to another
>> documentation site.
>>
>> Camel by nature integrates technologies with various licenses. If we
>> make non-Apache components a second class citizens, will be a
>> second-class integration framework when it comes to non-Apache
>> software. And Mule users will laugh at us :) .
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>
>
>
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project
site
Posted by Willem jiang <wi...@gmail.com>.
+1 if we can unify the wiki and issue for Camel and Camel-Extra.
The reason which we setup the Camel-Extra project is we cannot host the code of GPL license in Apache.
I don't think we cannot add the document or issues into Apache Camel due to that kind of issue.
Any thoughts?
On Wednesday, September 26, 2012 at 3:19 PM, Henryk Konsek wrote:
> > - Using Apache JIRA for Camel extra
>
>
>
> For now, I'll keep Camel Extra issues in Google Issue tracker. We
> shouldn't have Camel Extra issues spread around two places. However it
> will be nice if eventually we could use Jira for that.
>
> > (- Using Issue notifications on issues@camel.apache.org (mailto:issues@camel.apache.org) for issues raised
> > in Camel extra)
> > - Using Commit notifications on commits@camel.apache.org (mailto:commits@camel.apache.org) for changes in
> > Camel extra
>
>
>
> Yeah, since from the developer point of view it doesn't matter if
> somebody commits to Regular Camel or Extra Camel.
>
> > - Using the Apache Confluence WIKI for Camel extra components
>
> IMHO This is a must. We need uniform documentation format for all
> Camel stuff. I can't imagine redirecting end users to another
> documentation site.
>
> Camel by nature integrates technologies with various licenses. If we
> make non-Apache components a second class citizens, will be a
> second-class integration framework when it comes to non-Apache
> software. And Mule users will laugh at us :) .
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Henryk Konsek <he...@gmail.com>.
> - Using Apache JIRA for Camel extra
For now, I'll keep Camel Extra issues in Google Issue tracker. We
shouldn't have Camel Extra issues spread around two places. However it
will be nice if eventually we could use Jira for that.
> (- Using Issue notifications on issues@camel.apache.org for issues raised
> in Camel extra)
> - Using Commit notifications on commits@camel.apache.org for changes in
> Camel extra
Yeah, since from the developer point of view it doesn't matter if
somebody commits to Regular Camel or Extra Camel.
> - Using the Apache Confluence WIKI for Camel extra components
IMHO This is a must. We need uniform documentation format for all
Camel stuff. I can't imagine redirecting end users to another
documentation site.
Camel by nature integrates technologies with various licenses. If we
make non-Apache components a second class citizens, will be a
second-class integration framework when it comes to non-Apache
software. And Mule users will laugh at us :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
This is what I want to figure out with the people on the right mailing list:
- Using Apache JIRA for Camel extra
(- Using Issue notifications on issues@camel.apache.org for issues raised
in Camel extra)
- Using Commit notifications on commits@camel.apache.org for changes in
Camel extra
- Using the Apache Confluence WIKI for Camel extra components
Best,
Christian
On Tue, Sep 25, 2012 at 8:57 AM, Henryk Konsek <he...@gmail.com> wrote:
> > Until this is not settled, I don't
> > want to change this. MAY BE we cannot use the the official Apache JIRA to
> > track issues at Apache extra...
>
> Ok guys, probably I don't get some nuances of the Apache politics.
> From this point of view some issues (like CAMEL-5382[1]) are illegal
> and should not be on Jira in the first place.
>
> Since I'm Apache newbie, I'll comply to your opinion. Let's stick to
> the Google Issues. I'll migrate camel-extra related issues from Jira
> to Google Issues as well.
>
> Laters.
>
> [1] https://issues.apache.org/jira/browse/CAMEL-5382
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
--
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Henryk Konsek <he...@gmail.com>.
> Until this is not settled, I don't
> want to change this. MAY BE we cannot use the the official Apache JIRA to
> track issues at Apache extra...
Ok guys, probably I don't get some nuances of the Apache politics.
>From this point of view some issues (like CAMEL-5382[1]) are illegal
and should not be on Jira in the first place.
Since I'm Apache newbie, I'll comply to your opinion. Let's stick to
the Google Issues. I'll migrate camel-extra related issues from Jira
to Google Issues as well.
Laters.
[1] https://issues.apache.org/jira/browse/CAMEL-5382
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
Hi Henryk!
Do you follow the other discussion [1]? Until this is not settled, I don't
want to change this. MAY BE we cannot use the the official Apache JIRA to
track issues at Apache extra...
[1]
http://camel.465427.n5.nabble.com/Re-Apache-Extras-notifications-was-Disable-GitHub-commenting-httpd-td5719778.html
Best,
Christian
On Mon, Sep 24, 2012 at 11:12 PM, Henryk Konsek <he...@gmail.com> wrote:
> > +1 if we make it simple and easy for our Camel extra users to find the
> > Apache Camel JIRA.
>
> Anybody else wants to express their opinion? If not, can we assume it
> is a quiet consensus?
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
--
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Henryk Konsek <he...@gmail.com>.
> +1 if we make it simple and easy for our Camel extra users to find the
> Apache Camel JIRA.
Anybody else wants to express their opinion? If not, can we assume it
is a quiet consensus?
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [VOTE] Hide 'issues' tab in the Camel-Extra Google Project site
Posted by Christian Müller <ch...@gmail.com>.
I think a [DISCUSS] subject would have been better than a [VOTE], but
however...
+1 if we make it simple and easy for our Camel extra users to find the
Apache Camel JIRA.
Best,
Christian
On Sat, Sep 15, 2012 at 10:27 PM, Henryk Konsek <he...@gmail.com> wrote:
> Hi,
>
> While working on the camel-extra stuff together with Christian, I've
> risen the proposal of removing the 'Issues' tab [1] from the Camel
> extra page. Instead of Google Issues tracker, we could put the
> information on the Camel Extra home page, telling that one should use
> Camel Jira [2] to report the issues. This will make maintenance of the
> Camel Extra issues a bit easier.
>
> Code base of Camel extra is hosted on the Google Project due to the
> licensing reasons. Nothing however forces us to keep Camel Extra
> issues in the Google Issue Tracker. In fact, we handle the majority of
> the extra-related issues in the regular Camel Jira. We also got
> release versions set up in Jira, so we can assign tasks to the given
> release of Camel.
>
> We can easily migrate issues from Camel Extra Google Issues Tracker to
> Jira (I can handle this) and hide the 'Issues' panel (you can do it in
> the Google Project administration setup.
>
> Christian suggested me that the community should decide about the
> future of the issues at Google Tracker, so I decided to raise this
> voting. I got no binding vote anyway, so decision is up to you.
> However as a person involved in the Camel Extra development and
> maintenance I strongly endorse this idea :} .
>
> Regards.
>
> [1] http://code.google.com/a/apache-extras.org/p/camel-extra/issues/list
> [2] https://issues.apache.org/jira/browse/CAMEL
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
--