On 7/9/12 2:08 PM, Matt Benson wrote: > I am still thinking this through... Commons policy permits any Apache > committer to start a sandbox component, but IMO it is tacitly implied > that the associated code come directly from the committer/s, or from > another Apache project. This implies that this development would > either: > > - take place in the Incubator, probably sponsored by the Camel PMC, > with the stated hope of graduating as a Commons subproject, OR > - be created as a Camel subproject, with the Camel PMC handling the IP > clearance, THEN Camel developers copying the code to the Commons > sandbox (this feels a little unwieldy, though, TBH)
I have no problem with this, if that is what the Camel guys want to do. Saves us a little work managing IP clearance (and mentoring new committer(s)) > > Alternatively, it's possible that the Commons PMC would decide that > having other Apache committers (e.g. Camel, CXF, etc.) manage > *contributed* IP in the sandbox is okay. If existing Commons > developers are interested, then we have precedent to handle this type > of contribution in the sandbox (CSV) without further worry. The other > TLPs' committers would still be encouraged to participate, of course. > Any comments from the rest of Commons on either point? No problem with this either. Any ASF committer can become a Commons committer just by asking and we should welcome Camel or other people getting sandbox components (and contributors) ready for Commons proper. > > >From the IP perspective, the letter of foundation law requires that > the contribution be made via the IP clearance (sofware grant) process > [1]. Right. Unless the code has been contributed in patches directly to Camel (or here, in the sandbox), a grant will be required, either here or in Camel. +1 for the component in any case. Sounds like a useful component with a good start. Phil > > Matt > > [1] http://incubator.apache.org/ip-clearance/index.html > > On Mon, Jul 9, 2012 at 3:29 PM, Scott England-Sullivan > <[email protected]> wrote: >> Matt is correct. I will ping my coworkers and see who would be available to >> help out and we will go from there. >> >> Thanks, >> Scott ES >> >> On Jul 9, 2012, at 2:19 PM, Matt Benson <[email protected]> wrote: >> >>> If Scott were an Apache committer (he is not), that would be true. ;) >>> Instead, the situation is more complicated. Is this component part >>> of the current Camel codebase? If so (or even if not?), perhaps one >>> or more of the Camel committers would care to manage the code in the >>> Commons sandbox, from which point you, Scott, could participate as a >>> contributor (if the key one). >>> >>> Matt >>> >>> On Mon, Jul 9, 2012 at 3:15 PM, Luc Maisonobe <[email protected]> wrote: >>>> On 09/07/2012 22:12, Scott England-Sullivan wrote: >>>>> Hello, >>>> Hi Scott, >>>> >>>>> I have developed a new component for the Apache Camel project written >>>>> using >>>>> pure Java JMS APIs (the current component is a Spring JMS wrapper). There >>>>> have been requests made to make the API pulled out of the Camel component >>>>> and to place them in a commons project for use by other projects (CXF) >>>>> that >>>>> are looking to move away from the Spring JMS API. >>>>> >>>>> As such I am looking for guidance on where to start. The guides reference >>>>> contributing to current standing projects but not on how to create a >>>>> submission for a new commons project, namely, commons-jms. >>>>> >>>>> Any help or pointers would be appreciated. >>>> You should probably start the component in the commons sandbox and from >>>> them gather a small community before being promoted to commons proper. >>>> >>>> best regards, >>>> Luc >>>> >>>>> Thanks in advance, >>>>> Scott ES >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
