Hi Hans, please see inline:
On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote: > Hi Jacopo, > > Thank you for the effort you spend with OFBiz the last few months. I > generally agree that sure we have to cut the dead wood in the system. > Components and functions which are not used or only halfway implemented sure, > sounds like a good idea to move them out. > > However the reasons you list as 'high maintenance' i do not agree with. Only > with file changes there is work, otherwise it is pretty limited. Removing > half baked code sure, lets remove it. > > The 'not complete' reasons do not apply to several applications and functions > you want to remove because they are complete, like asset maintenance, LDAP, > POS, e-commerce, cmssite(demo for the content component perhaps better to > integrate it with ecommerce), projectmgr and scrum. The "not complete" is not the only motivation: I have also considered if they seem to be "used" and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs. Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited. > Also moving the JCR function out is not a good idea however when not improved > in the next few months using the content manager, i would agree to a removal. Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. > Then I was even more surprised, because reporting is a pretty weak point in > OFBiz, to remove the Birt integration and data warehouse entities. I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then "publish it to OFBiz" from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening. > I cannot agree with the removal of these components, Birt integration and JCR > (in the short term) > Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community. > Some other proposals: > 1. I would like to push for more junit tests and use even this as a measure > to keep a component in the system or not. (cobertura minimum percentage?) This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should be removed as well. > 2. To have a lead committer appointed for every component in the system who > will check incoming patches and will commit them, to relieve Jacques of some > work. I don't like very much this because it implies some sort of "ownership" over code. > 3. List functions/tasks with every committer, if a committer does not have a > function/task or is not active for a year, put him on the emeritus list, if > he gets active again put him back as a committer on his request. This to get > a real committers (and contributors, see next point) list. > 4. Also list contributors who have a function/task assigned either for > creating documents, reporting errors or supply patches, list the > contributions he/she did so we can keep up if he/she could be nominated to be > a committer. These last 2 points are probably off topic here (please discuss them in another thread) but I will provide my quick feedback because they are interesting: * I like the idea of point #4 for helping us to keep track of future candidates for being committers; we could also keep track of commit revisions where they patches have been submitted * I don't see the need for such a formal process for #3: it may be interesting to formalize who is active (with commits or reviews etc...) and who is not but it is already quite evident from the lists because we are a small group; this would also add some unnecessary overhead on the community: keep track of contributions, vote to move them to emeritus (contact infra to revoke commit rights?), and back if they want to come back (contact infra to regrant commit rights?) * when we talk about "contributions and commits" as a means to evaluate how much a contributor is helping the project then I would like to stress an important point, that was not considered until now: the contributions/commits must be inline with the current roadmap and priorities chosen by the community; otherwise, even if committer X is committing a huge number of code on a component she is working on for some personal interest, but not solicited by the community, then it would not be considered a "top contributor" Thanks for your comments. Kind regards, Jacopo > > Thanks again for your activity, keep up the good work! > > Regards, > Hans > > > On 03/18/2012 04:10 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 >> > >
