OFBiz itself went through that on a much larger scale when joining the ASF. It took some time but it wasn't a big deal.
No users are forced to do anything other than make a choice: stick with what you have or change to what is now available. Open source users make these types of decisions on a regular basis. Regards Scott On 29 Nov 2014 14:51, "Ron Wheeler" <rwhee...@artifact-software.com> wrote: > Don't forget to get ICLAs and Corporate CLAs for the new site for each > contributor otherwise you will have trouble if you want to submit it to > Apache OFBiz in the future. > I guess that if you offer it under an Apache license without having an > ICLA /CCLA in place, you would be personally liable for any claim by > contributors in the future. > > Not sure that you can/should force any existing users to move to the new > project. > Perhaps no one is using it so #5 is not a problem but I am not sure how > you can reach all of the people who have downloaded it. > > Ron > > On 28/11/2014 7:54 PM, Scott Gray wrote: > >> Hi Adrian, >> >> Sounds like a good plan to me. I think there should probably be some sort >> of a delay in step #5 and it should ultimately be decided by a PMC vote at >> that point in time as well. I totally support the concept though. >> >> Regards >> Scott >> >> On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum < >> adrian.c...@sandglass-software.com> wrote: >> >> As has been discussed in this thread, we can spin off special purpose >>> components to their own projects - where they can form their own >>> communities and support structure. >>> >>> I am willing to use the Asset Maintenance component as a trial run. Here >>> are some of my initial thoughts, comments are welcome: >>> >>> 1. Check with the ASF legal department before doing anything. >>> 2. Create a project on a popular hosting site (like SourceForge, but it >>> could be anywhere). >>> 3. Set up initial committers. >>> 4. Notify the OFBiz mailing lists about the new project. >>> 5. Drop the Asset Maintenance component from the ASF repo. >>> >>> The component would maintain the ASL 2 license. Support for various >>> versions of OFBiz will be decided by the Asset Maintenance community. >>> >>> If the spin-off is a success, then all is good. If it fails, then the >>> Asset Maintenance component is added back to the ASF repo. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 11/28/2014 4:01 PM, Ron Wheeler wrote: >>> >>> The components not supported as part of the core and framework would not >>>> leave Apache. >>>> They become separate sub-projects under OFBiz so that they stay in the >>>> community but are released and supported separately so that there is >>>> more transparency about their state. >>>> The release of new core and framework versions gets easier. >>>> >>>> The implied warranties get clearer and the sub-communities supporting >>>> each of the non-core components are : >>>> -easier to identify >>>> - free to set their own roadmaps based on the needs and the resources >>>> - easier to join since you only need to learn a small set of code in >>>> order to contribute >>>> - do not affect the core and framework code, roadmap or release plans >>>> except when they request extensions to the core or framework through >>>> JIRA issues. >>>> >>>> The core and framework team will not have to worry about the side >>>> components unless they belong to the sub-project and can release with a >>>> full warranty. >>>> >>>> Ron >>>> >>>> >>>> On 28/11/2014 10:30 AM, gil portenseigne wrote: >>>> >>>> First I might be a bit confuse in this email, sorry for that, quite >>>>> ideas came up while writing it, some organization missing. >>>>> >>>>> Le 28/11/2014 14:31, Ron Wheeler a écrit : >>>>> >>>>> What is the downside if the non-core components are released on their >>>>>> own with a clear set of documentation that describes the state of the >>>>>> component? >>>>>> >>>>>> I guess there is none at first glance, it's quite the same idea : >>>>> - A big release with core components active, and non-core component >>>>> unactive (with included documentations) >>>>> A monolythique one, all-included... >>>>> >>>>> - A Core release, first with then optional non-core component releases >>>>> with their own documentations >>>>> A core with packages. Less heavy but more actions... not a problem >>>>> >>>>> The things that make me wonder, and that's we try to achieve for >>>>> several years with an extension management tool, are all the deviance >>>>> possible without the control of such an Apache project. >>>>> >>>>> It is Out of Apache ! The component community can build their own >>>>> component at the speed they need (often dependant on a personal >>>>> project), without the quality control. It's good for this side >>>>> community, we are already doing that in our way. But can lead to a >>>>> branch component, which can't be contributed anymore to OFBiz if >>>>> needed (for any reasons I guess). >>>>> >>>>> Why not stick with Apache OFBiz in contributing more, into >>>>> desactivated non-core component using the side community advancement, >>>>> and managing to level up these non-core quality too make them stable >>>>> and reliable into Apache OFBiz. >>>>> >>>>> Specifics devs that can't be contributed into OFBiz, will remain as >>>>> extension into the side community. >>>>> >>>>> If side community meets some deviance in his evolution, not following >>>>> Apache OFBiz way, it must not have consequences like removing these >>>>> non-core component from trunk or branches. >>>>> >>>>> That's why i like the idea to have in Apache OFBiz, release with >>>>> unactive components (which can always be used and follow the Ofbiz >>>>> way), and then everyone have the opportunity to offer other community >>>>> components to replace unactive one, or to add to the core. >>>>> >>>>> Then some questions remains : >>>>> - How can user be informed of such side communities from the OFBiz >>>>> official site ? Is that possible ? >>>>> - We tried to introduce a new tool to manage extension (which could be >>>>> a solution for the first question, becoming a tool of indexation ) to >>>>> serve this kind of purpose, but their wasn't much reactions to it. Cf >>>>> : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr >>>>> >>>>> >>>>> Gil >>>>> >>>>> >>>>> My feeling is that it is better to release a clean core and framework >>>>>> where ALL component are "warranteed" by the team to be tested and >>>>>> supported. >>>>>> Components that are not part of the core would be released on their >>>>>> own with the warranty and support specified on an individual basis. >>>>>> >>>>>> At least the user community would know where it stands if it depends >>>>>> a non-core component to run their business. >>>>>> >>>>>> I think this is preferable than releasing a big conglomeration of >>>>>> working and non-working software that the user has to sort through to >>>>>> figure out if they can make a usable OFBiz. >>>>>> >>>>>> It also simplifies the release process for the core and framework. >>>>>> >>>>>> Ron >>>>>> >>>>>> On 28/11/2014 7:18 AM, gil portenseigne wrote: >>>>>> >>>>>> Hello all ! >>>>>>> >>>>>>> I followed the discussion, a bit late : >>>>>>> >>>>>>> Le 28/11/2014 11:24, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Afterthought: we agreed about having the same setting in both the >>>>>>>> releases branches and the trunk. So if we disable a component in >>>>>>>> the releases branches it will be also in the trunk. >>>>>>>> Then, even we enable tests, we will not be aware of UI related >>>>>>>> issues and globally all those which are no covered by tests. Apart >>>>>>>> if an users enable the component and report issues. >>>>>>>> >>>>>>>> This might be a compromise, but we need our users to be aware of. >>>>>>>> So they will need to be warned in the download page IMO. >>>>>>>> >>>>>>>> I think it's a good compromise, warning is needed to ensure that >>>>>>>> >>>>>>> user is aware or possible disfunctionment within these components. >>>>>>> No tricks needed anymore to import components from trunk. Good >>>>>>> enough for me. >>>>>>> >>>>>>> My opinion is that OOTB functionnalities are usable but rarely >>>>>>> sufficient for End-User, advanced skills are needed in each project >>>>>>> to make OFBiz fit the needs. So i guess there is no harm to let >>>>>>> inactive (uncomplete or so) component at disposal for user who might >>>>>>> need them. >>>>>>> >>>>>>> Also if you remember this thread started with my idea of creating a >>>>>>>> wiki page to explain to our users the alternative strategy of using >>>>>>>> release branches rather than released packages. >>>>>>>> I'd like to have a direct link to this wiki page from the download >>>>>>>> page. This link name could be simply "alternative strategy". What >>>>>>>> do you think? >>>>>>>> >>>>>>>> Using the same method, i like the idea. >>>>>>> >>>>>>> Gil >>>>>>> >>>>>>> I will stop this thread here and will create a new thread to >>>>>>>> discuss the modality of putting back the specialpurpose components >>>>>>>> in the R13.07 branch. >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 27/11/2014 23:38, Jacques Le Roux a écrit : >>>>>>>> >>>>>>>> That sounds like a good enough solution to me >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> Le 27/11/2014 19:41, Jacopo Cappellato a écrit : >>>>>>>>> >>>>>>>>> This is a good point. We could find a way to programmatically >>>>>>>>>> enable/disable the components just for the test run: >>>>>>>>>> >>>>>>>>>> ./ant -Denable-all=true clean-all load-demo run-tests >>>>>>>>>> >>>>>>>>>> but this is just an idea; we could figure out the best way to go. >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Nov 27, 2014, at 7:14 PM, Adrian Crum >>>>>>>>>> <adrian.c...@sandglass-software.com> wrote: >>>>>>>>>> >>>>>>>>>> Be aware that disabling a component does two things: >>>>>>>>>> >>>>>>>>>>> 1. Speeds up unit tests because the disabled component is >>>>>>>>>>> excluded from them. >>>>>>>>>>> 2. Increases the chance of regressions because the disabled >>>>>>>>>>> component is not being tested. >>>>>>>>>>> >>>>>>>>>>> Adrian Crum >>>>>>>>>>> Sandglass Software >>>>>>>>>>> www.sandglass-software.com >>>>>>>>>>> >>>>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>>>>> >>>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>>>>>> <jacques.le.r...@les7arts.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes, so we need to define which are those components. So 3 >>>>>>>>>>>> >>>>>>>>>>>>> points, which should be discussed separately it seems, not >>>>>>>>>>>>> sure of the order yet but probably this one >>>>>>>>>>>>> 1) Components to move to Attic. They will be freezed but still >>>>>>>>>>>>> available in this state in Attic (in other words slowly dying) >>>>>>>>>>>>> 2) Components to disable. They will be maintained, but OOTB >>>>>>>>>>>>> will not interfere with other components (applications or >>>>>>>>>>>>> other specialpurpose) >>>>>>>>>>>>> 3) Components to keep enabled. They must be maintained and >>>>>>>>>>>>> have no interactions with other components >>>>>>>>>>>>> >>>>>>>>>>>>> Components enabled and disabled must be maintained in the same >>>>>>>>>>>> way: it is not that a group is more important than the other. >>>>>>>>>>>> Also, disabling a component doesn't mean that it will not go in >>>>>>>>>>>> a release: we could have disabled components in releases and >>>>>>>>>>>> enabled components excluded from a release or vice versa. >>>>>>>>>>>> >>>>>>>>>>>> For the point 2 we need to clarify if it could applies to >>>>>>>>>>>> >>>>>>>>>>>>> trunk also. I'd now tend to avoid differences between trunk >>>>>>>>>>>>> and branch releases, at the functionality or other levels. >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that the same settings should be maintained in the >>>>>>>>>>>> trunk and in the release branches. >>>>>>>>>>>> >>>>>>>>>>>> Jacopo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
