Hi Hans, Of course you do not have to agree. But, like you implied earlier: let's put it to the vote and see what the outcome will. I assume that you will adhere/comply to the result as well.
Regards, Pierre Op 19 maart 2012 13:15 schreef Hans Bakker <mailingl...@antwebsystems.com>het volgende: > Jacopo, > > I appreciate you reply and effort, can however not agree with you. Perhaps > for you good reasoning, not for me. > > Regards, > Hans > > > > On 03/19/2012 05:08 PM, Jacopo Cappellato wrote: > >> 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 >>>> >>>> >>> > >
