See below: On Tue, Sep 30, 2014 at 9:58 AM, Mike <mz4whee...@gmail.com> wrote:
> Why not deploy it as another hot-deploy component? Is it considered a > "core" ERP component? > > I do not know about whether or not it is 'core', but the idea of deploying it as a hot-deploy component has merit. As I read Jacopo's remarks, it isn't so much a concern about whether or not the component in question ought to be included in OFBiz at all, but rather the concern is of the risk of including it at a late date in the release cycle (just before a scheduled release). As a developer, I know there would be major pushback by the development team against any manager asking to include a new 'feature' shortly before a scheduled release. We have a feature freeze in a release cycle for a reason. For any new feature, there needs to be a dialog between at least the senior developers and the management, and the users, about what the feature is, how it ought to work, &c., and that is a dialog that can not be rushed if you want a good product; if you work on adding a new feature even months before a release date, I can guarantee it will not be well thought out/designed/implemented. Even if the component being considered at the moment is 'reasonably' well conceived and much work has gone into developing it, if it has never been part of the 13.07 release, including it so close to the scheduled release is a recipe for 'problems', and possibly some sleepless nights and ulcers for whoever has to make it work. In my shop, we have a whole separate system on which new and proposed features are developed and tested thoroughly before that code is even considered for inclusion in our production systems. It is a test bed on which all interested parties can see new features in operation, in the context of the application, and learn about what is practicable and desirable. Sometimes, after working with it on dev, they see that trying to fully implement and deploy the new feature would be foolish and unnecessary; and this before major development effort has been invested. And sometimes, we collectively learn that the new feature is practicable and desirable, and at that point, we already have a prototype that can be used to quickly develop it to a point where it can be deployed to production. Jacopo does say that "It would be better to discuss its inclusion in the upcoming new release branch where it could be stabilized and bug fixed." Myself, I would take that a step further in suggesting, borrowing from Mike's suggestion, that it ought to be available as something that can be used in a hot-deploy sandbox as it were: a method that, conceptually facilitates those interested in it to work with it, test in in their release, &c., but in such a way that it can not damage anything else in the application. It may be useful to look at how R handles these issues. There is R-core, and an R-core team, that is part of the main distribution (all packages included in an installation of it), and then there is CRAN (similar in concept to CPAN, for any Perl programmers out there - I hope it isn't considered blasphemy to talk about Perl in this forum ;-) ), to which all members of the R community can contribute their packages; analogous to components in the context of an application like OFBiz. CRAN has a QA protocol, which must be passed in order for an R package to be added to CRAN; something that assures users that their system will not be trashed if they instal a package available from CRAN. And, sometimes, the R core team decides that one of the packages on CRAN is so important and useful that they decide to add it to core (this doesn't happen often, but it does happen). So then, in the context of OFBiz, the first question becomes, can the hot-deploy support be used in a manner similar to a snadbox that protext the rest of the system from badly behaved code (NB: I am not implying anything about the code in the component in question now, but rather thinking in general terms for any new component anyone may want to contribute)? And then, the question becomes, what protocol can be used for promoting components from the 'sandbox' to incorporation into the 'core release'; whatever you want to call it? Cheers Ted > On Tue, Sep 30, 2014 at 2:59 AM, Pierre Smits <pierre.sm...@gmail.com> > wrote: > > > Jacopo, > > > > Back then there were already strong objections to excluding components > from > > the release. I recall that Hans also wanted to keep the SCRUM component > in > > the release, as well as there were proponents for BIRT and other > > components. > > > > These are good additions to the feature set of OFBiz and may be in use > > already by community members. It would be best that you solicit the > advice > > of the entire community before a decision on excluding components from > any > > release is taken. This affects more participants in this project than > just > > you and the committers. > > > > Regards, > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > On Tue, Sep 30, 2014 at 11:49 AM, Jacopo Cappellato < > > jacopo.cappell...@hotwaxmedia.com> wrote: > > > > > Ok, got it. > > > The release process that the OFBiz community is following is based on a > > > feature freeze phase, that for the 13.07 branch started more than one > > year > > > ago, during which only bug fixes are backported. > > > This is done in order to stabilize the branch before an official > release > > > is done. Since the "projectmgr" component has never been part of the > > 13.07 > > > branch then it may be unsafe to include it now just before the release > is > > > issued. It would be better to discuss its inclusion in the upcoming new > > > release branch where it could be stabilized and bug fixed. > > > > > > Regards, > > > > > > Jacopo > > > > > > -- R.E.(Ted) Byers, Ph.D.,Ed.D. t...@merchantservicecorp.com
