I'm fine with the agreed upon approach, but I also wanted to clarify some of what Guillaume originally proposed because I never saw any of this mentioned in this thread.
Within ServiceMix we had already split Kernel/Karaf and other larger parts of our project (components, NMR, etc.) into separate standalone SVN, Jira, and Wiki projects. We mainly did this as a result of some painful growth experiences with maintainting documentation, multiple concurrent releases (bugfix branches vs major releases), increased user traffic, and various other issues that were encountered with having a large monolithic project structure with dozens of subprojects. I think ServiceMix and Felix are somewhat unique among Apache projects in that each has already fostered a rather large ecosystem of related sub-projects or components that have a lifecycle all their own. I don't think anyone has found a perfect solution within our (Apache) infrastructure, but I wouldn't worry about fragmenting a community because on development infrastructure organization choices. I think the essence of a well established community is largely unaffected by the organization and naming of code and artifacts Sorry for being late to the discussion, but I wanted to add my 2 cents. I think the most important thing is to keep moving forward so +1 for the current plan, and we can always reevaluate down the road if this thing takes off like we think it will. Cheers, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Apr 27, 2009 at 8:06 AM, Richard S. Hall <[email protected]>wrote: > On 4/27/09 7:36 AM, Guillaume Nodet wrote: > >> Ok, I'm not really convinced, but since it seems there is a lot of >> reluctance I think we should aim for: >> * packages in org.apache.felix.karaf >> * use existing FELIX infrastructure (mailing list, jira tracker, >> confluence space) >> >> I think we should start with the above and reconsider later if there is a >> need. >> Is everyone satisfied with the above ? >> >> > > I think this sounds fine. > > My main concern was that the reason for moving to Felix was to focus the > community on it, thus it seemed strange to then try to make it completely > separate in approach, mailing lists, infrastructure, etc., since that > approach could have been done at ServiceMix and achieved the same result, I > would think. > > -> richard > > On Mon, Apr 27, 2009 at 12:17, Karl Pauls<[email protected]> wrote: >> >> >>> I think we should start with the FELIX infra and then see whether we >>> need to create a new one when the need is there. >>> >>> About the package renaming, I'm in favour of going with >>> org.apache.felix.karaf just because it emphasizes that felix is not >>> about the framework. If we make an exception then this sends a strange >>> message IMO. >>> >>> regards, >>> >>> Karl >>> >>> On Mon, Apr 27, 2009 at 12:11 PM, Richard S. Hall<[email protected]> >>> wrote: >>> >>> >>>> On 4/27/09 6:07 AM, Guillaume Nodet wrote: >>>> >>>> >>>>> Yes, they do. The definition of a subproject is imho just something >>>>> controlled by a given TLP. >>>>> The way its infrastructure is set up has nothing to do with that. A >>>>> lot of TLP uses multiple JIRA and confluence spaces for different >>>>> reasons. >>>>> >>>>> >>>>> >>>> My point was, this subproject is apparently not going to be treated like >>>> any >>>> other Felix subproject. >>>> >>>> -> richard >>>> >>>> >>>> >>>>> On Mon, Apr 27, 2009 at 12:03, Richard S. Hall<[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On 4/27/09 5:57 AM, Guillaume Nodet wrote: >>>>>> >>>>>> >>>>>> >>>>>>> It seems the consensus for the code is to move it to >>>>>>> https://svn.apache.org/repos/asf/felix/trunk/karaf >>>>>>> So i'll go ahead and move the servicemix kernel trunk there asap. >>>>>>> >>>>>>> We still need to settle the problems of: >>>>>>> * package name: org.apache.karaf vs org.apache.felix.karaf >>>>>>> * jira issue tracker: use FELIX or create a new KARAF one >>>>>>> * web site: use FELIX or create a new KARAF one >>>>>>> >>>>>>> The package renaming to org.apache.karaf has raised a number of >>>>>>> concerns, mostly (correct me if i'm wrong) about the fact whether >>>>>>> this >>>>>>> would be frowned upong by the ASF or not. Given the number of >>>>>>> subprojects that do that since a long time, I think the answer is no. >>>>>>> Now we need to decide if we want to do this or not. >>>>>>> >>>>>>> For the issue tracker and web site, I think this is somewhat related >>>>>>> to the package renaming issue above, though the problem is a bit >>>>>>> different. I'm really opened here, but if we choose to rename the >>>>>>> packages to org.apache.karaf, it think it would make more sense to >>>>>>> have dedicated JIRA and confluence spaces. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> And is this how other projects do it too? >>>>>> >>>>>> It seems this is a subproject in name only. >>>>>> >>>>>> -> richard >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Fri, Apr 24, 2009 at 09:26, Guillaume Nodet<[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I'd like to start moving the ServiceMix Kernel code into Felix now. >>>>>>>> Given the size of the code base, I think it would be better to just >>>>>>>> move the tree into its own top level svn structure. >>>>>>>> I'd like to run the following command: >>>>>>>> >>>>>>>> svn cphttps://svn.apache.org/repos/asf/servicemix/smx4/kernel >>>>>>>> https://svn.apache.org/repos/asf/felix/karaf >>>>>>>> >>>>>>>> Any objections in doing that ? >>>>>>>> >>>>>>>> Next steps will include creating a JIRA project and moving all the >>>>>>>> issues into it (with a KARAF id), then the confluence space. >>>>>>>> >>>>>>>> -- >>>>>>>> Cheers, >>>>>>>> Guillaume Nodet >>>>>>>> ------------------------ >>>>>>>> Blog:http://gnodet.blogspot.com/ >>>>>>>> ------------------------ >>>>>>>> Open Source SOA >>>>>>>> http://fusesource.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> -- >>> Karl Pauls >>> [email protected] >>> >>> >>> >> >> >> >> >> >
