Grin, That is like playing footbal (any kind) without the ball, and trying to sell it as an attractive alternative.
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 Fri, Oct 3, 2014 at 5:07 PM, Ron Wheeler <[email protected]> wrote: > It is a bit hard to "market" a module that is being dropped in 13.07.01. > > > On 03/10/2014 5:48 AM, Scott Gray wrote: > >> Do you have a link to the discussion they had Pierre? It would be >> interesting to read more of the context. Although even with one active >> contributor, it sounds like it is still doing better than our projectmgr >> component which has none. >> >> And yes it is quite true that projects have a decent amount of >> flexibility in what they can and cannot do. I was simply saying that >> community diversity is a major factor in considering top-level project >> proposals and commonly (but apparently not always) in sub-projects as well, >> I think the reasons for this are self explanatory but yes exceptions are >> obviously also made sometimes. >> >> I just simply don't believe that our current approach could be so >> inhibiting that the component just sits there with no consistently active >> contributors. Maybe the component needs more marketing? Perhaps those >> with an interest in the component could consider writing some blog posts or >> mentioning it in relevant social media, forums, mailing lists etc., writing >> additional documentation may help too. Perhaps you (Pierre) could consider >> contributing some of the customizations you mentioned having made. My >> point is that there is much that could be done by anyone in the community >> who cares enough to do it. Not every problem can be laid solely at the >> feet of the PMC (IMO very few actually can, but we obviously disagree on >> that). >> >> Regards >> Scott >> >> On 3/10/2014, at 9:45 pm, Pierre Smits <[email protected]> wrote: >> >> That does work for other top level projects under the ASF umbrella. >>> Recently a discussion is started in the mailing list of Apache Directory >>> server to adopt a new - external - component as a sub project (the do >>> everything in sub projects), that has only 1 committer and 1 contributor. >>> There you also can't talk about having a great adoption within the >>> community of that project, because it isn't there yet. But there are >>> sentiments in favour of it, as it will expand the feature set of the >>> works >>> of the project and the visibility of the project itself. >>> >>> When you look at the CouchDb project, you'll see that they have dedicated >>> mailing lists for various themes. You'll see that anything is possible >>> under the ASF umbrella when you take a closer look. >>> >>> The Apache way is not to restricting people willing to do stuff, but to >>> enable them. And often you need to promote to get the attention of >>> contributors. Downplaying etc. does the opposite. >>> >>> 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 Fri, Oct 3, 2014 at 10:27 AM, Scott Gray <[email protected]> >>> wrote: >>> >>> Currently, the connection between individual modules and the people who >>>>> >>>> care is a bit fuzzy and has resulted in decisions being taken by people >>>> who >>>> do not have a real interest in the particular modules that are being >>>> dropped. They have no way to connect with the interested parties or >>>> even to >>>> be sure about who they are. >>>> >>>>> One of the values of sub-projects is that you capture groups that have >>>>> a >>>>> >>>> narrow interest in particular areas but are not able to commit to the >>>> entire project. >>>> >>>> We have mailing lists and jira to gauge interest in a specific >>>> component. >>>> Code contributions in particular are very useful in determining >>>> interest, >>>> unless you're suggesting that the component is perfect and no further >>>> work >>>> is required. Everything in OFBiz has room for improvement and a lack of >>>> contributions is very much an indicator of a lack of interest in my >>>> opinion >>>> and experience with this project. >>>> >>>> It doesn't make any sense to create sub-projects in the hope that >>>> someone >>>> might show up and start community building. The ASF doesn't work that >>>> way >>>> for top-level projects and by the DB Project link you sent earlier >>>> implies >>>> they don't work that way for sub-projects either. A community must >>>> exist >>>> around a given component before it can have any hope of standing on its >>>> own. >>>> >>>> Regards >>>> Scott >>>> >>>> On 3/10/2014, at 7:50 pm, Ron Wheeler <[email protected]> >>>> wrote: >>>> >>>> Are there a lot of outstanding JIRA issues that users want fixed? >>>>> It is not inconceivable that a module works as required. >>>>> I am not sure that measuring the usefulness of a module by the number >>>>> of >>>>> >>>> bugs or deficiencies found recently is accurate. >>>> >>>>> It seems to have been tested with the trunk as the core OFBiz has >>>>> >>>> evolved. >>>> >>>>> It appears that it may need some testing with the ccore 13.07.01 >>>>> Release >>>>> >>>> before PROJECTMGR can be either said to work as is with 13.07.01 or >>>> released as a new version of PROJECTMGR that does work with 13.07.01. >>>> >>>>> If there was a sub-project with a following, there would be a group of >>>>> >>>> people who want it to work and would be prepared to do what was >>>> required to >>>> keep the module functioning. >>>> >>>>> It would be quite clear to the people interested in PROJECTMGR that it >>>>> >>>> was their responsibility to make sure that it was functional with >>>> 13.07.01. >>>> >>>>> Currently, the connection between individual modules and the people who >>>>> >>>> care is a bit fuzzy and has resulted in decisions being taken by people >>>> who >>>> do not have a real interest in the particular modules that are being >>>> dropped. They have no way to connect with the interested parties or >>>> even to >>>> be sure about who they are. >>>> >>>>> One of the values of sub-projects is that you capture groups that have >>>>> a >>>>> >>>> narrow interest in particular areas but are not able to commit to the >>>> entire project. >>>> >>>>> The people working on the release of the core also have a clear project >>>>> >>>> management group in each sub-project to consult when core functionality >>>> will affect individual modules or when planning a release and want to >>>> let >>>> the sub-project teams know that they must take some action in order to >>>> keep >>>> their module functional. >>>> >>>>> It is not inconceivable that some sub-projects will die due to lack of >>>>> >>>> interest. >>>> >>>>> PROJECTMGR seems to have some life in it but without a formal >>>>> >>>> sub-project structure it is hard to judge except from ML discussions and >>>> recent activity. >>>> >>>>> Ron >>>>> >>>>> On 02/10/2014 3:02 PM, Scott Gray wrote: >>>>> >>>>>> Surely the first step in considering a specialized component for >>>>>> >>>>> sub-project creation would be the level of activity surrounding the >>>> component? >>>> >>>>> Looking at the history of the projectmgr component I see 12 commits in >>>>>> >>>>> the last TWO years 8 of which were global changes that coincidentally >>>> happened to touch on that component (translation work, global >>>> refactorings >>>> etc.). This leaves only 4 commits specific to the component and even >>>> those >>>> are minor UI adjustments. >>>> >>>>> To be considered as a potential sub-project I would expect to see a >>>>>> >>>>> hive of activity around that component with contributors specializing >>>> in >>>> solid contributions to further enhance it. "Build it and they will >>>> come" >>>> is not a valid approach to sub-project creation. >>>> >>>>> If this component is so important to some of you, why are you not >>>>>> >>>>> contributing to its enhancement? >>>> >>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 3/10/2014, at 2:56 am, Ron Wheeler <[email protected] >>>>>> > >>>>>> >>>>> wrote: >>>> >>>>> Of course, I see a lot of benefit in the Apache approach of >>>>>>> >>>>>> sub-projects but perhaps the current group of committers should take >>>> some >>>> time to consider this and talk to the Apache Mentors assigned to the >>>> project as well as some of the project chairpersons from projects where >>>> sub-projects are in use. >>>> >>>>> One of the advantages of being an Apache project is that there are >>>>>>> >>>>>> many things for which there is an "Apache Way" and there are people >>>> in the >>>> broader Apache community that can provide information and guidance. >>>> >>>>> To Jacopo's point about trust. >>>>>>> I may trust someone to do one thing but not another. >>>>>>> I may trust someone with a critical task that I would not entrust to >>>>>>> >>>>>> another person who might be technically capable of doing it. >>>> >>>>> As a project manager, I may trust someone to work on a particular part >>>>>>> >>>>>> of an application but not on the data access. >>>> >>>>> For the project to grow, the people working on the framework are going >>>>>>> >>>>>> to have to get used to the idea that total strangers will be >>>> committing >>>> code to the project. >>>> >>>>> The sub-project structure allows this to happen in a controlled way. >>>>>>> >>>>>>> It also allows sub-projects to attract the "right" mix of people >>>>>>> which >>>>>>> >>>>>> would be a totally different set of skills than the Framework project >>>> would >>>> want. >>>> >>>>> Each sub-project will develop a team personality based on the >>>>>>> >>>>>> sub-project's mission and the type of people required to implement the >>>> mission. >>>> >>>>> I would expect the framework sub-project to be "hard core" technical >>>>>>> >>>>>> people who know a lot about databases, security, entity modeling >>>> whereas >>>> the e-Commerce team will have people who are very knowledgeable about >>>> taxation, payment system integration, shopping cart design, user >>>> experience, and end-user documentation. >>>> >>>>> The Project Management sub-project will attract people who know a lot >>>>>>> >>>>>> about billing for consulting companies, accounting firms and legal >>>> offices >>>> as well project management, workflow, issue tracking, user interfaces, >>>> web >>>> services, etc. >>>> >>>>> I would expect some overlap since many of the people here are very >>>>>>> >>>>>> senior and have skills in multiple areas but I suspect that most new >>>> people >>>> will start in one sub-project and "cut their teeth" there before joining >>>> another. >>>> >>>>> If it is done right it also makes everyone's job a lot easier and >>>>>>> >>>>>> should reduce the amount of ML traffic for each person. >>>> >>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> On 02/10/2014 9:22 AM, Jacopo Cappellato wrote: >>>>>>> >>>>>>>> In my opinion we should avoid reconsidering the idea of creating >>>>>>>> >>>>>>> committers with limited access; instead I would prefer to invite >>>> committers >>>> when we trust them as individuals, when they have demonstrated the right >>>> attitude and skills to work in our community etc... and demonstrate >>>> enough >>>> technical skills for the work they have to do; even if it is limited to >>>> a >>>> subset of the OFBiz codebase they will get full access to the repos but >>>> of >>>> course they will limit their field of action to the area they know, >>>> without >>>> requiring us to enforce commit rights limitations. As I said this can >>>> only >>>> work if we trust them 100% as persons at first. >>>> >>>>> Jacopo >>>>>>>> >>>>>>>> On Oct 2, 2014, at 2:30 PM, Jacques Le Roux < >>>>>>>> >>>>>>> [email protected]> wrote: >>>> >>>>> That's an interesting idea. >>>>>>>>> >>>>>>>>> Now it also means more administration and we are already a bit >>>>>>>>> >>>>>>>> sparse on the volunteering front. >>>> >>>>> A simpler solution the OFBiz project used was to allow write access >>>>>>>>> >>>>>>>> to only parts of the repo. >>>> >>>>> This was before the Apache era. We gave up this way of doing because >>>>>>>>> >>>>>>>> it was not the Apache way. >>>> >>>>> I have not read it all yet but for instance I read in >>>>>>>>> >>>>>>>> https://community.apache.org/newcommitter.html >>>> >>>>> <<There may be extraordinary cases where we want limited >>>>>>>>> >>>>>>>> work-related commit access. This will be resolved during the vote >>>> discussion. >> >>>> >>>>> I don't know how technically this is possible in OFBiz trunk and >>>>>>>>> >>>>>>>> branches, apart maybe asking the infra team? Which would most >>>> probably >>>> faces a veto... >>>> >>>>> Jacques >>>>>>>>> >>>>>>>>> Le 01/10/2014 16:46, Ron Wheeler a écrit : >>>>>>>>> >>>>>>>>>> The sub-project is a very useful Apache tool for helping projects >>>>>>>>>> >>>>>>>>> grow. >>>> >>>>> http://db.apache.org/newproject.html is interesting reading. >>>>>>>>>> http://ant.apache.org/antlibs/ very minimal description about Ant >>>>>>>>>> >>>>>>>>> sub-projects but we all use their work. >>>> http://lucene.472066.n3.nabble.com/Close-of-Apache- >>>> Lucene-s-Open-Relevance-sub-project-td4141160.html >>>> a note about the official closure of a sub-project - very clear about >>>> why >>>> and what closure means. >>>> >>>>> http://en.wikipedia.org/wiki/Apache_Ivy another popular >>>>>>>>>> >>>>>>>>> sub-project. Description implies that it started in incubation and >>>> graduated to a top-level package and then became a sub-project of Ant. >>>> http://icodebythesea.blogspot.ca/2009/04/apache-servicemix- >>>> kernel-subproject.html >>>> is an example of a sub-project moving between two top-level projects. >>>> >>>>> The sub-project structure allows for more specialization within the >>>>>>>>>> >>>>>>>>> project resources so that people who are wizards with databases, >>>> kernels, >>>> etc get to worry about data access, performance, scalability, >>>> reliability, >>>> security while others who have more domain interest get to worry about >>>> features, usability, graphic design, workflow, reporting without >>>> getting in >>>> each other's hair. >>>> >>>>> It also ensures a clearer demarcation between framework, core ERP >>>>>>>>>> >>>>>>>>> and modules. >>>> >>>>> I suspect that it would clean up project communication since people >>>>>>>>>> >>>>>>>>> could subscribe to the sub-project lists that pertained to their >>>> interests. >>>> >>>>> It might be easier for the existing community to accept new >>>>>>>>>> >>>>>>>>> committers if the new people were part of a sub-project and were >>>> not >>>> committing to the particular codebase (framework, core, etc.) that the >>>> current committers are working on. >>>> >>>>> It probably would help clarify the documentation since there would >>>>>>>>>> >>>>>>>>> be a much clearer separation of framework from core from modules >>>> since each >>>> sub-project would have its own section in the project documentation. >>>> >>>>> Each sub-project would have a much better defined target audience >>>>>>>>>> >>>>>>>>> so writing docs would be a bit simpler and the language and >>>> terminology >>>> could be more relevant to the target audience. >>>> >>>>> Ron >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 01/10/2014 10:17 AM, Pierre Smits wrote: >>>>>>>>>> >>>>>>>>>>> Ron, >>>>>>>>>>> >>>>>>>>>>> In the past there was a WIKI page decribing who was interested >>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>> who was willing to work on what. I don't know whether that page >>>> still >>>> exists. >>>> >>>>> In the past we also had a system of having committers dedicated >>>>>>>>>>> >>>>>>>>>> and committed to a subset of the trunk. This should still be >>>> feasible. But >>>> for that you need more committers. And to get more committers, this >>>> project >>>> needs to solicit and accept more. >>>> >>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>>>>>>>> Services & Solutions for Cloud- >>>>>>>>>>> Based Manufacturing, Professional >>>>>>>>>>> Services and Retail & Trade >>>>>>>>>>> http://www.orrtiz.com <http://www.orrtiz.com/> >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler < >>>>>>>>>>> >>>>>>>>>> [email protected] <mailto:rwheeler@artifact- >>>> software.com>> >>>> wrote: >>>> >>>>> A defined method of deciding what moves from the trunk to a >>>>>>>>>>> release would solve this. >>>>>>>>>>> Back to my previous comment about 1 person to test and 1 >>>>>>>>>>> person >>>>>>>>>>> >>>>>>>>>> to >>>> >>>>> fix bugs (could be the same person I suppose) would be a good >>>>>>>>>>> starting minimum. >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> On 01/10/2014 2:56 AM, Pierre Smits wrote: >>>>>>>>>>> >>>>>>>>>>> The excuse of using PROJECTMgr in an older branch (12.x, >>>>>>>>>>> the >>>>>>>>>>> latest stable >>>>>>>>>>> release) and testing it against trunk and therefor not >>>>>>>>>>> including it in a >>>>>>>>>>> release of a newer branch, is a lame one. >>>>>>>>>>> >>>>>>>>>>> We are diligent about this, meaning that we do follow up >>>>>>>>>>> against any >>>>>>>>>>> potential new release branch in order to be able to >>>>>>>>>>> migrate >>>>>>>>>>> >>>>>>>>>> to >>>> >>>>> the newer >>>>>>>>>>> branch when there is something released. >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> *ORRTIZ.COM <http://ORRTIZ.COM> <http://www.orrtiz.com>* >>>>>>>>>>> Services & Solutions for Cloud- >>>>>>>>>>> Based Manufacturing, Professional >>>>>>>>>>> Services and Retail & Trade >>>>>>>>>>> http://www.orrtiz.com >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato < >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> The fact that someone is using it in an older branch >>>>>>>>>>> and >>>>>>>>>>> testing it in >>>>>>>>>>> trunk is not enough to guarantee it works well with >>>>>>>>>>> >>>>>>>>>> 13.07; >>>> >>>>> the trunk and >>>>>>>>>>> 13.07 are very different codebases. >>>>>>>>>>> Additionally, the "projectmgr" component has 0 unit >>>>>>>>>>> >>>>>>>>>> tests; >>>> >>>>> I am not sure >>>>>>>>>>> about about its stability, but for example comments in >>>>>>>>>>> code like the >>>>>>>>>>> following don't make me feel super confident: >>>>>>>>>>> >>>>>>>>>>> <!-- temporary disabled because it caused a db lock >>>>>>>>>>> >>>>>>>>>> with the >>>> >>>>> checkProjectMembership in projectpermission services --> >>>>>>>>>>> >>>>>>>>>>> One more point to note: since the component has not >>>>>>>>>>> been >>>>>>>>>>> in the 13.07 >>>>>>>>>>> branch, it didn't undergo the 1-year long >>>>>>>>>>> stabilization >>>>>>>>>>> phase where only >>>>>>>>>>> bug-fixes are backported: for example, one month ago, >>>>>>>>>>> >>>>>>>>>> with >>>> >>>>> revision >>>>>>>>>>> 1618313, it was modified by a big commit to replace a >>>>>>>>>>> series of Freemarker >>>>>>>>>>> built-ins operation that we decided to not backport to >>>>>>>>>>> 13.07 but only keep >>>>>>>>>>> in the trunk. >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> On Sep 30, 2014, at 11:19 PM, Ron Wheeler >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> So, as far as is known from Pierre's testing, >>>>>>>>>>> there >>>>>>>>>>> >>>>>>>>>> is >>>> >>>>> no work required >>>>>>>>>>> >>>>>>>>>>> to "stabilize and bug fix" the module prior to >>>>>>>>>>> including >>>>>>>>>>> it in 13.07.01? >>>>>>>>>>> >>>>>>>>>>> Anyone else have any comments on the work required >>>>>>>>>>> >>>>>>>>>> to >>>> >>>>> include it in >>>>>>>>>>> >>>>>>>>>>> 13.07.01? >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> On 30/09/2014 5:13 PM, Pierre Smits wrote: >>>>>>>>>>> >>>>>>>>>>> Ron, All, >>>>>>>>>>> >>>>>>>>>>> We use the latest released branch, meaning >>>>>>>>>>> 12.x. >>>>>>>>>>> We don't expose our >>>>>>>>>>> customers to an unstable unreleased branch, >>>>>>>>>>> that >>>>>>>>>>> is still undergoing >>>>>>>>>>> significant changes. >>>>>>>>>>> >>>>>>>>>>> But, we test our solutions against trunk. This >>>>>>>>>>> enables us to identify >>>>>>>>>>> issues and register them in JIRA. And supply >>>>>>>>>>> patches when workload >>>>>>>>>>> >>>>>>>>>>> allows >>>>>>>>>>> >>>>>>>>>>> it. >>>>>>>>>>> >>>>>>>>>>> So yes, PROJECTMGR, SCRUM, etc work also in >>>>>>>>>>> >>>>>>>>>> r13.x >>>> >>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> *ORRTIZ.COM <http://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 10:22 PM, Ron Wheeler >>>>>>>>>>> < >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> Are you using it with a 12.04 or 13.xx? >>>>>>>>>>> What work is required to get it into >>>>>>>>>>> 13.07? >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> On 30/09/2014 3:06 PM, Pierre Smits wrote: >>>>>>>>>>> >>>>>>>>>>> Yes, I also have a vested interest in >>>>>>>>>>> keeping this (PROJECTMGR) in the >>>>>>>>>>> releases. It is part of our ORRTIZ:COM >>>>>>>>>>> solution portfolio for our >>>>>>>>>>> customers >>>>>>>>>>> and we use it internally. And I have >>>>>>>>>>> contributed to the improvement >>>>>>>>>>> >>>>>>>>>>> of the >>>>>>>>>>> >>>>>>>>>>> component. >>>>>>>>>>> >>>>>>>>>>> We, at ORRTIZ:COM, even use an >>>>>>>>>>> extension >>>>>>>>>>> to the code base to ensure >>>>>>>>>>> >>>>>>>>>>> that >>>>>>>>>>> >>>>>>>>>>> it >>>>>>>>>>> also works for fixed price and >>>>>>>>>>> internal >>>>>>>>>>> projects. This extension >>>>>>>>>>> >>>>>>>>>>> includes >>>>>>>>>>> >>>>>>>>>>> generating the gl transactions >>>>>>>>>>> regarding >>>>>>>>>>> the cost price of each hour >>>>>>>>>>> registered regarding a project. >>>>>>>>>>> >>>>>>>>>>> We also use the LDAP component to >>>>>>>>>>> >>>>>>>>>> connect >>>> >>>>> to our directory server >>>>>>>>>>> >>>>>>>>>>> (Apache >>>>>>>>>>> >>>>>>>>>>> Directory Server). >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> *ORRTIZ.COM <http://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 4:39 PM, Ron >>>>>>>>>>> >>>>>>>>>> Wheeler >>>> >>>>> <rwheeler@artifact-software. >>>>>>>>>>> >>>>>>>>>>> com >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> It would be for me since it is one >>>>>>>>>>> >>>>>>>>>> of >>>> >>>>> the components that I want to >>>>>>>>>>> >>>>>>>>>>> use. >>>>>>>>>>> >>>>>>>>>>> Perhaps the more knowledgeable >>>>>>>>>>> >>>>>>>>>> people >>>> >>>>> might want to share a bit more >>>>>>>>>>> >>>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>> the background of the feature. >>>>>>>>>>> Is it in 12.xx.xx? >>>>>>>>>>> >>>>>>>>>>> Is it currently in the 13.07 >>>>>>>>>>> branch >>>>>>>>>>> and therefor currently part of >>>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> 13.07 versions that people have >>>>>>>>>>> put >>>>>>>>>>> >>>>>>>>>> in >>>> >>>>> production or is it just in >>>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> trunk that people are putting into >>>>>>>>>>> production? >>>>>>>>>>> >>>>>>>>>>> What are the issues that need to >>>>>>>>>>> be >>>>>>>>>>> addressed before it is >>>>>>>>>>> >>>>>>>>>>> "stabilized >>>>>>>>>>> >>>>>>>>>>> and >>>>>>>>>>> bug fixed"? >>>>>>>>>>> Do any of these issues pose a >>>>>>>>>>> significant risk to the stability >>>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> rest of the functionality? >>>>>>>>>>> >>>>>>>>>>> Is anyone using it in production? >>>>>>>>>>> >>>>>>>>>> What >>>> >>>>> are their opinions of the >>>>>>>>>>> >>>>>>>>>>> state of >>>>>>>>>>> >>>>>>>>>>> the code and the degree of risk? >>>>>>>>>>> >>>>>>>>>>> Is anyone prepared to take on the >>>>>>>>>>> >>>>>>>>>> task >>>> >>>>> of getting it "stabilized and >>>>>>>>>>> >>>>>>>>>>> bug >>>>>>>>>>> >>>>>>>>>>> fixed" to a point where it can be >>>>>>>>>>> safely included? >>>>>>>>>>> What is the estimate of the >>>>>>>>>>> minimum >>>>>>>>>>> effort required? >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 30/09/2014 9:58 AM, Mike wrote: >>>>>>>>>>> >>>>>>>>>>> Why not deploy it as another >>>>>>>>>>> hot-deploy component? Is it >>>>>>>>>>> >>>>>>>>>>> considered a >>>>>>>>>>> >>>>>>>>>>> "core" ERP component? >>>>>>>>>>> >>>>>>>>>>> On Tue, Sep 30, 2014 at 2:59 >>>>>>>>>>> AM, >>>>>>>>>>> Pierre Smits < >>>>>>>>>>> >>>>>>>>>>> [email protected] <mailto:[email protected] >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> 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://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 < >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>> -- >>>>> Ron Wheeler >>>>> President >>>>> Artifact Software Inc >>>>> email: [email protected] >>>>> skype: ronaldmwheeler >>>>> phone: 866-970-2435, ext 102 >>>>> >>>>> >>>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
