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_k...@mail.gmail.com%3E Best, Christian On Thu, Sep 27, 2012 at 4:10 AM, Hadrian Zbarcea <hzbar...@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 iss...@camel.apache.org for issues >>> raised >>> in Camel extra) >>> - Using Commit notifications on comm...@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 :) . >> >> --
