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 <rwhee...@artifact-software.com> 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 <jacques.le.r...@les7arts.com> >> 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 >>>>> <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 >>>>> >>>>> >>>> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
