Yeah I understood that. Deleting simply means it won't be available in future releases. It wouldn't suddenly disappear out of pre-existing releases.
Regards Scott On Sat, Nov 29, 2014 at 3:49 PM, Ron Wheeler <[email protected] > wrote: > On 28/11/2014 9:38 PM, Scott Gray wrote: > >> 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. >> > Your statement is generally are correct but in this context, it related to > the suggestion about (#5) deleting Asset Management from OFBiz. > > Regards >> Scott >> On 29 Nov 2014 14:51, "Ron Wheeler" <[email protected]> >> 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 < >>>> [email protected]> 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 >>>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>>>> >>>>>>>>>>>>>> <[email protected]> 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: [email protected] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
