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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >>