Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too?
Thanks Sam On 21 Mar 2012, at 16:23, Vikas Mayur wrote: > Thanks Jacopo for your quick response. It clears my doubt. > > Regards > Vikas > > On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: > >> Hi Vikas, >> >> I am sharing my ideas about this new process (they are also based on my >> reading of various documents provided by ASF): >> >> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: >> >>> Hi Jacopo, >>> >>> I have few questions on the proposed idea for Extras. >>> >>> -- Since the projects will be hosted as Apache OFBiz Extras and not >>> officially under ASF, In future does this means these projects should >>> strictly follow the ASF license? What if user group and/or the code >>> maintainer of the project tries to change any such thing over time? >> >> No, each project will be free to decide the license; of course the ASL2.0 >> will make it easier to contribute code with Apache OFBiz, but it will not be >> a requirement. >> >>> >>> -- Will all committers from OFBiz other than the maintainer still have a >>> commit rights to Extras? I believe maintainer would be any existing >>> committer(s) or new committer(s) assigned to the project(s) in Extras. >> >> Not necessarily: the maintainer could be also a non-committer and not all >> OFBiz committers will automatically get access to the project in Extras (you >> have to accept the agreement with Google etc...); this is definitely true >> for new projects that will start from scratch; for projects that will be >> contributed by the OFBiz community (by moving components out of OFBiz) we >> will ask to the maintainer to invite each OFBiz committer to become a >> committer: the ones that will accept will be setup there >> >>> -- Will the OFBiz community in general still be keeping track of >>> development, discussions, future of these projects or any other activities? >> >> I would like something like this: the OFBiz community could encourage (not >> oblige) the external project to send status updates to the OFBiz dev list >> from time to time to keep the community updated (every month/quarter or >> based on activity or milestones reached); I guess that the best mechanism >> will be refined over time with some experience >> >>> -- Is it necessary for Apache OFBiz Extras projects to follow the release >>> policy similar to OFBiz? >> >> No >> >>> -- If no one come forward for a certain project under specialpurpose, it >>> will be moved to Attic. What if, in future someone show interest in the >>> project, will the project be moved Extras or not? >> >> Yes, we can resurrect all the code in our repository; the Attic page in >> Confluence will help to keep track of components that we remove. >> >> Regards, >> >> Jacopo >> >> >>> >>> Regards >>> Vikas >>> >>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: >>> >>>> In the last period the OFBiz project has grown a lot in shape: the >>>> implicitly accepted (or tolerated) strategy operated by the active >>>> committers was that the more features you could add to the official >>>> repository the better was: you make happy the contributors, making them >>>> feel like they are a part of something, and each committer could manage >>>> the code implemented for his/her own projects directly in the OFBiz >>>> codebase. >>>> >>>> We operated under the concept that, since the code if "free" and the >>>> author (committer or not) is willing to contribute it, then no one >>>> should/could complain if it is added to the repository, if it doesn't >>>> cause immediate problems to others; all in all it is an additional feature >>>> that may be used by someone else in the future or if not would simply stay >>>> there without causing any harm. >>>> Following this strategy we got a lot of code like for example Webslinger, >>>> seleniumxml, debian packages, all sort of specialpurpose applications >>>> etc... >>>> >>>> Since there was not a central and agreed upon roadmap, no one could really >>>> state that a contribution was not a good fit for the project: each and >>>> every committer could add what, in his own personal vision, was good for >>>> the project. >>>> >>>> The wrong assumption is that, since the code if "free" then it doesn't >>>> harm to include it. This is completely *wrong*: the code is not *free* at >>>> all because as soon as you add it to the repository then you add a future >>>> cost to the community: you all know that in the software industry the cost >>>> to maintain a piece of code is by far greater than the cost to write it; >>>> and you *have* to maintain the code unless you want to have and distribute >>>> stale code. >>>> And this is exactly what we have now: >>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to >>>> remove the Webslinger component) >>>> * stale/unused/half baked code that causes confusion and bad impression to >>>> user evaluating the quality of our product >>>> >>>> The message to all the committers is: when you add code to the repository, >>>> you are asking the community to take care of its maintenance costs >>>> forever. So please, add new code only when it is really beneficial to the >>>> project and to a large audience of committers and users. >>>> >>>> It is like feeding a wild animal at the zoo with chips: everyone knows it >>>> is bad for its health but when you are there it is so nice when it picks >>>> the food from your own hands and you cannot resist and have to feed it. >>>> >>>> OFBiz is now suffering from serious weight issues: the committers >>>> community is having an hard time to maintain the huge codebase, it is >>>> difficult to keep track of all the features in the system etc... >>>> >>>> I think it is important to start a new phase of the project and focus our >>>> energy in cleanup and consolidation of what we have. One step in this >>>> direction is for OFBiz to lose weight. >>>> >>>> In order to get the ball rolling and focus on some concrete tasks I am >>>> providing here some examples of stuff that I would like to see removed >>>> from the project. >>>> >>>> IMPORTANT: Please consider that the list is not based on what I think the >>>> perfect framework should be (so PLEASE do not reply stating what your >>>> ideal framework should have), but simply on the following considerations: >>>> * can the component be easily removed by the project? is it independent >>>> and can live outside as a plugin? >>>> * do we need all this custom code? can't we find a simpler, lighter and >>>> better way to implement this? >>>> * is this feature used by other code in the system? >>>> * is the feature functional? or is it largely incomplete? >>>> * is this an old component/code? >>>> * is this used by a lot of persons? (this is tricky to decide but you can >>>> get a feeling of it by reading the mailing lists, considering commit >>>> activity, the status of the feature etc...) >>>> >>>> DISCLAIMER: I know it will be a painful decision because each of us >>>> reading this will have a connection with some of the code listed below: >>>> several hours spent on it, great ideas that never came to a finished plan; >>>> in fact I feel the same for a few of the things in the list.... there are >>>> great ideas that didn't come to a finalization... it doesn't mean that >>>> moving them out of the project will kill them and this may actually help >>>> to get more visibility and different user group; so please when you will >>>> read it... think to the greater good of the community. >>>> >>>> Legenda for what I propose for each piece of code: >>>> * Attic: remove from code base and document the removal for future >>>> reference in this page >>>> * Extras: identify a person interested in maintaining the code as a >>>> separate project hosted as an Apache Extra project (not officially under >>>> the ASF); add a link to it from the page that will contain "OFBiz Extras" >>>> >>>> And now (drums)..... THE LIST - PART 1(but this is really a very first >>>> pass only, PART 2 will come soon with more granular - subcomponent - >>>> details): >>>> >>>> A) move framework/guiapp out of the framework; after all these years no >>>> code made advantage of it being part of the framework and it is only used >>>> by the specialpurpose/pos component (which was the component for which it >>>> was built for); so guiapp can go in the pos component >>>> >>>> B) specialpurpose/pos: move to "Extras" >>>> >>>> C) $OFBIZ_HOME/debian: move to "Attic" >>>> >>>> D) the seleniumxml code in framework/testtools: move to "Attic" >>>> >>>> E) specialpurpose/workflow: move to "Attic" >>>> >>>> F) specialpurpose/shark: move to "Attic" >>>> >>>> G) specialpurpose/ofbizwebsite: move to "Attic" >>>> >>>> H) specialpurpose/*: move several (if not all, apart ecommerce) of the >>>> components to "Extras" (if there are persons interested to become >>>> committers/maintainers) or to "Attic" >>>> >>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them >>>> to "Extras"; keep just one (or two) >>>> >>>> J) framework/appserver: move to "Extras" >>>> >>>> K) framework/jetty: move to "Extras" (or "Attic") >>>> >>>> L) framework/birt (and related dependencies/reports spread around): move >>>> to "Extras" >>>> >>>> M) framework/bi (and related dependencies - ecas/business rules and data - >>>> spread around): move to "Extras" >>>> >>>> N) framework/jcr: move back into the Jackrabbit branch until the work is >>>> completed and can replace the existing "content framework" >>>> >>>> O) framework/documents: move the content to Wiki and then move to "Attic" >>>> >>>> P) framework/datafile: (who is currently using it?) move to "Extras" or >>>> "Attic"; we could replace it with commons-csv or similar tool >>>> >>>> Q) framework/example and framework/exampleext: move to specialpurpose >>>> >>>> Kind regards, >>>> >>>> Jacopo >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
