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