This sounds good. But then, what do I know? I am still willing to pitch in on documentation, once I wrap my head around the project (or a potential sub-project). For now it's a matter of free time and all that ...
On 14-10-01 07:46 AM, Ron Wheeler wrote: > 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 >> <rwhee...@artifact-software.com >> <mailto:rwhee...@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 < >> jacopo.cappell...@hotwaxmedia.com >> <mailto:jacopo.cappell...@hotwaxmedia.com>> 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 >> <rwhee...@artifact-software.com >> <mailto:rwhee...@artifact-software.com>> >> 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 < >> rwhee...@artifact-software.com >> <mailto:rwhee...@artifact-software.com>> 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 < >> >> pierre.sm...@gmail.com <mailto: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://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 >> >> <mailto: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 >> >> >> >> >> >> -- Ron Wheeler >> President >> Artifact Software Inc >> email: rwhee...@artifact-software.com >> <mailto:rwhee...@artifact-software.com> >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> > >