OFBiz and Attitude & Trust
Locked
 
|
Jacopo,
I your posting regarding the vote to keep the PROJECTMGR in releases (see here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you addressed aspects as ' the right attitude' and 'trust them' in respect to inviting committers. In the committers role and responsibilities page (see here: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities ) we can read about the responsibilities. But words like attitude and trust are not not mentioned. Can you, as the PMC Chair, explain what the vision and expectations are regarding this right attitude and trust? 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < [hidden email]> 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 <[hidden email]> > 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 < > [hidden email] <mailto:[hidden email]>> > 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 < > >>> [hidden email] > >>> <mailto:[hidden email]>> 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 > >>> <[hidden email] > >>> <mailto:[hidden email]>> > >>> 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 < > >>> [hidden email] > >>> <mailto:[hidden email]>> 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 < > >>> > >>> [hidden email] <mailto:[hidden email]>> > >>> > >>> 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 < > >>> [hidden email] > >>> <mailto:[hidden email]>> > >>> 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: [hidden email] > >>> <mailto:[hidden email]> > >>> skype: ronaldmwheeler > >>> phone: 866-970-2435, ext 102 > >>> > >>> > >> > >> > > |
|
|
Hi Pierre,
Jacopo's first words in that email were "In my opinion". That's an extremely important point. There are no guidelines because each PMC member is free to vote however they feel would best serve the project. Any of us could provide our own personal guidelines but they would still just be personal opinions. Regards Scott On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> wrote: > Jacopo, > > I your posting regarding the vote to keep the PROJECTMGR in releases (see > here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you addressed > aspects as ' the right attitude' and 'trust them' in respect to inviting > committers. > > In the committers role and responsibilities page (see here: > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > ) we can read about the responsibilities. But words like attitude and trust > are not not mentioned. > > Can you, as the PMC Chair, explain what the vision and expectations are > regarding this right attitude and trust? > > 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > [hidden email]> 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 <[hidden email]> >> 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 < >> [hidden email] <mailto:[hidden email]>> >> 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 < >>>>> [hidden email] >>>>> <mailto:[hidden email]>> 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 >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> >>>>> 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 < >>>>> [hidden email] >>>>> <mailto:[hidden email]>> 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 < >>>>> >>>>> [hidden email] <mailto:[hidden email]>> >>>>> >>>>> 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 < >>>>> [hidden email] >>>>> <mailto:[hidden email]>> >>>>> 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: [hidden email] >>>>> <mailto:[hidden email]> >>>>> skype: ronaldmwheeler >>>>> phone: 866-970-2435, ext 102 >>>>> >>>>> >>>> >>>> >> >> |
|
|
Scott,
You are correct. Yet, you forgot to mention that Jacopo used 'we' in direct relation to the words attitude and trust. So, he is not talking about just his own feelings but about the collective perception. 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 17, 2014 at 12:09 PM, Scott Gray <[hidden email]> wrote: > Hi Pierre, > > Jacopo's first words in that email were "In my opinion". That's an > extremely important point. > > There are no guidelines because each PMC member is free to vote however > they feel would best serve the project. Any of us could provide our own > personal guidelines but they would still just be personal opinions. > > Regards > Scott > > On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> wrote: > > > Jacopo, > > > > I your posting regarding the vote to keep the PROJECTMGR in releases (see > > here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you addressed > > aspects as ' the right attitude' and 'trust them' in respect to inviting > > committers. > > > > In the committers role and responsibilities page (see here: > > > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > > ) we can read about the responsibilities. But words like attitude and > trust > > are not not mentioned. > > > > Can you, as the PMC Chair, explain what the vision and expectations are > > regarding this right attitude and trust? > > > > 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > > [hidden email]> 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 > >> > |
|
|
Pierre,
Yes, in his opinion that is what we do. It's probably a correct opinion too (in my opinion). But at the end of the day my point stands, PMC members are individuals and each have different opinions about what makes a good committer. I'm not trying to be combative, if you disagree I'm happy to discuss it. Regards Scott On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> wrote: > Scott, > > You are correct. Yet, you forgot to mention that Jacopo used 'we' in direct > relation to the words attitude and trust. So, he is not talking about just > his own feelings but about the collective perception. > > 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 17, 2014 at 12:09 PM, Scott Gray <[hidden email]> > wrote: > >> Hi Pierre, >> >> Jacopo's first words in that email were "In my opinion". That's an >> extremely important point. >> >> There are no guidelines because each PMC member is free to vote however >> they feel would best serve the project. Any of us could provide our own >> personal guidelines but they would still just be personal opinions. >> >> Regards >> Scott >> >> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> wrote: >> >>> Jacopo, >>> >>> I your posting regarding the vote to keep the PROJECTMGR in releases (see >>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you addressed >>> aspects as ' the right attitude' and 'trust them' in respect to inviting >>> committers. >>> >>> In the committers role and responsibilities page (see here: >>> >> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities >>> ) we can read about the responsibilities. But words like attitude and >> trust >>> are not not mentioned. >>> >>> Can you, as the PMC Chair, explain what the vision and expectations are >>> regarding this right attitude and trust? >>> >>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < >>> [hidden email]> 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 >>>> >> |
|
|
So, you - as any PMC member - can also elaborate on the consensus with
respect to the attitude and trustability requirements regarding potential committers (above and beyond the responsibilities, if these exist). Or - as it may be possible that I have misinterpreted the posting by Jacopo - is it just about potential committers having the right mindset towards the execution of tasks as described in the roles and responsibilities document? Meaning that they can apply due diligence before committing? And that they can make their own interests subordinate to those of the community? 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 17, 2014 at 12:28 PM, Scott Gray <[hidden email]> wrote: > Pierre, > > Yes, in his opinion that is what we do. It's probably a correct opinion > too (in my opinion). But at the end of the day my point stands, PMC > members are individuals and each have different opinions about what makes a > good committer. > > I'm not trying to be combative, if you disagree I'm happy to discuss it. > > Regards > Scott > > On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> wrote: > > > Scott, > > > > You are correct. Yet, you forgot to mention that Jacopo used 'we' in > direct > > relation to the words attitude and trust. So, he is not talking about > just > > his own feelings but about the collective perception. > > > > 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 17, 2014 at 12:09 PM, Scott Gray <[hidden email] > > > > wrote: > > > >> Hi Pierre, > >> > >> Jacopo's first words in that email were "In my opinion". That's an > >> extremely important point. > >> > >> There are no guidelines because each PMC member is free to vote however > >> they feel would best serve the project. Any of us could provide our own > >> personal guidelines but they would still just be personal opinions. > >> > >> Regards > >> Scott > >> > >> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> > wrote: > >> > >>> Jacopo, > >>> > >>> I your posting regarding the vote to keep the PROJECTMGR in releases > (see > >>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you > addressed > >>> aspects as ' the right attitude' and 'trust them' in respect to > inviting > >>> committers. > >>> > >>> In the committers role and responsibilities page (see here: > >>> > >> > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > >>> ) we can read about the responsibilities. But words like attitude and > >> trust > >>> are not not mentioned. > >>> > >>> Can you, as the PMC Chair, explain what the vision and expectations are > >>> regarding this right attitude and trust? > >>> > >>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > >>> [hidden email]> 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 > >>>> > >> > > |
|
|
From my perspective the confluence document seems to outline everything pretty well.
I think the 'trust' aspect would simply be that a voting PMC member is able to trust that a potential committer would fulfill the the outlined roles and responsibilities. The 'attitude' would simply be that the potential committer is willing to follow advice and work well with others. Neither of these things are so strange that they'd need to be further documented IMO. I can't speak for Jacopo or anyone else, that's just my interpretation. Regards Scott On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> wrote: > So, you - as any PMC member - can also elaborate on the consensus with > respect to the attitude and trustability requirements regarding potential > committers (above and beyond the responsibilities, if these exist). > > Or - as it may be possible that I have misinterpreted the posting by Jacopo > - is it just about potential committers having the right mindset towards > the execution of tasks as described in the roles and responsibilities > document? Meaning that they can apply due diligence before committing? And > that they can make their own interests subordinate to those of the > community? > > 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 17, 2014 at 12:28 PM, Scott Gray <[hidden email]> > wrote: > >> Pierre, >> >> Yes, in his opinion that is what we do. It's probably a correct opinion >> too (in my opinion). But at the end of the day my point stands, PMC >> members are individuals and each have different opinions about what makes a >> good committer. >> >> I'm not trying to be combative, if you disagree I'm happy to discuss it. >> >> Regards >> Scott >> >> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> wrote: >> >>> Scott, >>> >>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in >> direct >>> relation to the words attitude and trust. So, he is not talking about >> just >>> his own feelings but about the collective perception. >>> >>> 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 17, 2014 at 12:09 PM, Scott Gray <[hidden email] >>> >>> wrote: >>> >>>> Hi Pierre, >>>> >>>> Jacopo's first words in that email were "In my opinion". That's an >>>> extremely important point. >>>> >>>> There are no guidelines because each PMC member is free to vote however >>>> they feel would best serve the project. Any of us could provide our own >>>> personal guidelines but they would still just be personal opinions. >>>> >>>> Regards >>>> Scott >>>> >>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> >> wrote: >>>> >>>>> Jacopo, >>>>> >>>>> I your posting regarding the vote to keep the PROJECTMGR in releases >> (see >>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you >> addressed >>>>> aspects as ' the right attitude' and 'trust them' in respect to >> inviting >>>>> committers. >>>>> >>>>> In the committers role and responsibilities page (see here: >>>>> >>>> >> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities >>>>> ) we can read about the responsibilities. But words like attitude and >>>> trust >>>>> are not not mentioned. >>>>> >>>>> Can you, as the PMC Chair, explain what the vision and expectations are >>>>> regarding this right attitude and trust? >>>>> >>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < >>>>> [hidden email]> 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 >>>>>> >>>> >> >> |
|
|
Of course you can't.
Thank you for sharing your viewpoint. 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 17, 2014 at 1:11 PM, Scott Gray <[hidden email]> wrote: > From my perspective the confluence document seems to outline everything > pretty well. > > I think the 'trust' aspect would simply be that a voting PMC member is > able to trust that a potential committer would fulfill the the outlined > roles and responsibilities. The 'attitude' would simply be that the > potential committer is willing to follow advice and work well with others. > Neither of these things are so strange that they'd need to be further > documented IMO. > > I can't speak for Jacopo or anyone else, that's just my interpretation. > > Regards > Scott > > On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> wrote: > > > So, you - as any PMC member - can also elaborate on the consensus with > > respect to the attitude and trustability requirements regarding potential > > committers (above and beyond the responsibilities, if these exist). > > > > Or - as it may be possible that I have misinterpreted the posting by > Jacopo > > - is it just about potential committers having the right mindset towards > > the execution of tasks as described in the roles and responsibilities > > document? Meaning that they can apply due diligence before committing? > And > > that they can make their own interests subordinate to those of the > > community? > > > > 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 17, 2014 at 12:28 PM, Scott Gray <[hidden email] > > > > wrote: > > > >> Pierre, > >> > >> Yes, in his opinion that is what we do. It's probably a correct opinion > >> too (in my opinion). But at the end of the day my point stands, PMC > >> members are individuals and each have different opinions about what > makes a > >> good committer. > >> > >> I'm not trying to be combative, if you disagree I'm happy to discuss it. > >> > >> Regards > >> Scott > >> > >> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> > wrote: > >> > >>> Scott, > >>> > >>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in > >> direct > >>> relation to the words attitude and trust. So, he is not talking about > >> just > >>> his own feelings but about the collective perception. > >>> > >>> 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 17, 2014 at 12:09 PM, Scott Gray < > [hidden email] > >>> > >>> wrote: > >>> > >>>> Hi Pierre, > >>>> > >>>> Jacopo's first words in that email were "In my opinion". That's an > >>>> extremely important point. > >>>> > >>>> There are no guidelines because each PMC member is free to vote > however > >>>> they feel would best serve the project. Any of us could provide our > own > >>>> personal guidelines but they would still just be personal opinions. > >>>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> > >> wrote: > >>>> > >>>>> Jacopo, > >>>>> > >>>>> I your posting regarding the vote to keep the PROJECTMGR in releases > >> (see > >>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you > >> addressed > >>>>> aspects as ' the right attitude' and 'trust them' in respect to > >> inviting > >>>>> committers. > >>>>> > >>>>> In the committers role and responsibilities page (see here: > >>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > >>>>> ) we can read about the responsibilities. But words like attitude and > >>>> trust > >>>>> are not not mentioned. > >>>>> > >>>>> Can you, as the PMC Chair, explain what the vision and expectations > are > >>>>> regarding this right attitude and trust? > >>>>> > >>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > >>>>> [hidden email]> 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 > >>>>>> > >>>> > >> > >> > > |
|
|
In reply to this post by Scott Gray-2
Scott,
Am I correct in understanding that any contributor with ambitions to be a committer should interpret your 'willing to follow advice' as 'willingness to take good advice into consideration when acting within the community or dealing with issues, but don't follow bad advice blindly'? Your 'willing to follow' sounds a lot like 'must follow'. I trust that wasn't your intention... Or am I misinterpreting this? 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 17, 2014 at 1:11 PM, Scott Gray <[hidden email]> wrote: > From my perspective the confluence document seems to outline everything > pretty well. > > I think the 'trust' aspect would simply be that a voting PMC member is > able to trust that a potential committer would fulfill the the outlined > roles and responsibilities. The 'attitude' would simply be that the > potential committer is willing to follow advice and work well with others. > Neither of these things are so strange that they'd need to be further > documented IMO. > > I can't speak for Jacopo or anyone else, that's just my interpretation. > > Regards > Scott > > On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> wrote: > > > So, you - as any PMC member - can also elaborate on the consensus with > > respect to the attitude and trustability requirements regarding potential > > committers (above and beyond the responsibilities, if these exist). > > > > Or - as it may be possible that I have misinterpreted the posting by > Jacopo > > - is it just about potential committers having the right mindset towards > > the execution of tasks as described in the roles and responsibilities > > document? Meaning that they can apply due diligence before committing? > And > > that they can make their own interests subordinate to those of the > > community? > > > > 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 17, 2014 at 12:28 PM, Scott Gray <[hidden email] > > > > wrote: > > > >> Pierre, > >> > >> Yes, in his opinion that is what we do. It's probably a correct opinion > >> too (in my opinion). But at the end of the day my point stands, PMC > >> members are individuals and each have different opinions about what > makes a > >> good committer. > >> > >> I'm not trying to be combative, if you disagree I'm happy to discuss it. > >> > >> Regards > >> Scott > >> > >> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> > wrote: > >> > >>> Scott, > >>> > >>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in > >> direct > >>> relation to the words attitude and trust. So, he is not talking about > >> just > >>> his own feelings but about the collective perception. > >>> > >>> 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 17, 2014 at 12:09 PM, Scott Gray < > [hidden email] > >>> > >>> wrote: > >>> > >>>> Hi Pierre, > >>>> > >>>> Jacopo's first words in that email were "In my opinion". That's an > >>>> extremely important point. > >>>> > >>>> There are no guidelines because each PMC member is free to vote > however > >>>> they feel would best serve the project. Any of us could provide our > own > >>>> personal guidelines but they would still just be personal opinions. > >>>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> > >> wrote: > >>>> > >>>>> Jacopo, > >>>>> > >>>>> I your posting regarding the vote to keep the PROJECTMGR in releases > >> (see > >>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you > >> addressed > >>>>> aspects as ' the right attitude' and 'trust them' in respect to > >> inviting > >>>>> committers. > >>>>> > >>>>> In the committers role and responsibilities page (see here: > >>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > >>>>> ) we can read about the responsibilities. But words like attitude and > >>>> trust > >>>>> are not not mentioned. > >>>>> > >>>>> Can you, as the PMC Chair, explain what the vision and expectations > are > >>>>> regarding this right attitude and trust? > >>>>> > >>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > >>>>> [hidden email]> 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 > >>>>>> > >>>> > >> > >> > > |
Re: OFBiz and Attitude & Trust
|
|
In reply to this post by Scott Gray-2
On Oct 17, 2014, at 1:11 PM, Scott Gray <[hidden email]> wrote: > I can't speak for Jacopo or anyone else, that's just my interpretation. Thank you Scott, you have provided a good summary of my personal point of view about this topic. Jacopo |
|
|
In reply to this post by Pierre Smits
Perhaps "accept" is a better word than "follow", no one has ever questioned it in such detail.
If there's disagreement about advice given then there only needs to be a willingness to discuss the matter. Obviously there are votes if things get out of hand but it's rare for things to go that far. If committers are unwilling to approach a disagreement with an open mind then it makes life difficult for everyone. Regards Scott On 18/10/2014, at 1:04 am, Pierre Smits <[hidden email]> wrote: > Scott, > > Am I correct in understanding that any contributor with ambitions to be a > committer should interpret your 'willing to follow advice' as 'willingness > to take good advice into consideration when acting within the community or > dealing with issues, but don't follow bad advice blindly'? Your 'willing to > follow' sounds a lot like 'must follow'. I trust that wasn't your > intention... > > Or am I misinterpreting this? > > 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 17, 2014 at 1:11 PM, Scott Gray <[hidden email]> > wrote: > >> From my perspective the confluence document seems to outline everything >> pretty well. >> >> I think the 'trust' aspect would simply be that a voting PMC member is >> able to trust that a potential committer would fulfill the the outlined >> roles and responsibilities. The 'attitude' would simply be that the >> potential committer is willing to follow advice and work well with others. >> Neither of these things are so strange that they'd need to be further >> documented IMO. >> >> I can't speak for Jacopo or anyone else, that's just my interpretation. >> >> Regards >> Scott >> >> On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> wrote: >> >>> So, you - as any PMC member - can also elaborate on the consensus with >>> respect to the attitude and trustability requirements regarding potential >>> committers (above and beyond the responsibilities, if these exist). >>> >>> Or - as it may be possible that I have misinterpreted the posting by >> Jacopo >>> - is it just about potential committers having the right mindset towards >>> the execution of tasks as described in the roles and responsibilities >>> document? Meaning that they can apply due diligence before committing? >> And >>> that they can make their own interests subordinate to those of the >>> community? >>> >>> 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 17, 2014 at 12:28 PM, Scott Gray <[hidden email] >>> >>> wrote: >>> >>>> Pierre, >>>> >>>> Yes, in his opinion that is what we do. It's probably a correct opinion >>>> too (in my opinion). But at the end of the day my point stands, PMC >>>> members are individuals and each have different opinions about what >> makes a >>>> good committer. >>>> >>>> I'm not trying to be combative, if you disagree I'm happy to discuss it. >>>> >>>> Regards >>>> Scott >>>> >>>> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> >> wrote: >>>> >>>>> Scott, >>>>> >>>>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in >>>> direct >>>>> relation to the words attitude and trust. So, he is not talking about >>>> just >>>>> his own feelings but about the collective perception. >>>>> >>>>> 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 17, 2014 at 12:09 PM, Scott Gray < >> [hidden email] >>>>> >>>>> wrote: >>>>> >>>>>> Hi Pierre, >>>>>> >>>>>> Jacopo's first words in that email were "In my opinion". That's an >>>>>> extremely important point. >>>>>> >>>>>> There are no guidelines because each PMC member is free to vote >> however >>>>>> they feel would best serve the project. Any of us could provide our >> own >>>>>> personal guidelines but they would still just be personal opinions. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> >>>> wrote: >>>>>> >>>>>>> Jacopo, >>>>>>> >>>>>>> I your posting regarding the vote to keep the PROJECTMGR in releases >>>> (see >>>>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you >>>> addressed >>>>>>> aspects as ' the right attitude' and 'trust them' in respect to >>>> inviting >>>>>>> committers. >>>>>>> >>>>>>> In the committers role and responsibilities page (see here: >>>>>>> >>>>>> >>>> >> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities >>>>>>> ) we can read about the responsibilities. But words like attitude and >>>>>> trust >>>>>>> are not not mentioned. >>>>>>> >>>>>>> Can you, as the PMC Chair, explain what the vision and expectations >> are >>>>>>> regarding this right attitude and trust? >>>>>>> >>>>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < >>>>>>> [hidden email]> 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 >>>>>>>> >>>>>> >>>> >>>> >> >> |
|
|
Scott,
I can image that you would feel that 'accept' is better than 'follow' with respect to advice. But it still sounds that you want a contributor to comply to your advice. We are dealing with people here who can make sound judgement calls whether or not to accept and act accordingly. The participants within this community are not sheep. You are making more of this than it should be. We have enough mitigating procedures in place for the occasional committer that doesn't comply to responsibilities outlined in the wiki page. If you have trust issues you should propose changes to the wiki document. That way all participants in this project can increase their insights and express their viewpoint about how and when contributors should be considered and accepted or rejected by the PMC. Remember, this is a project for everybody participating. That you have trust issues and therefor reject any committer who doesn't comply to your advice, shouldn't lead to an increasing number of issues not getting resolved. That way you are stifling the growth of our project. My advice to you is to relax your viewpoint on this and any contributor showing commitment to the project. 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 Sat, Oct 18, 2014 at 11:21 AM, Scott Gray <[hidden email]> wrote: > Perhaps "accept" is a better word than "follow", no one has ever > questioned it in such detail. > > If there's disagreement about advice given then there only needs to be a > willingness to discuss the matter. Obviously there are votes if things get > out of hand but it's rare for things to go that far. If committers are > unwilling to approach a disagreement with an open mind then it makes life > difficult for everyone. > > Regards > Scott > > On 18/10/2014, at 1:04 am, Pierre Smits <[hidden email]> wrote: > > > Scott, > > > > Am I correct in understanding that any contributor with ambitions to be a > > committer should interpret your 'willing to follow advice' as > 'willingness > > to take good advice into consideration when acting within the community > or > > dealing with issues, but don't follow bad advice blindly'? Your 'willing > to > > follow' sounds a lot like 'must follow'. I trust that wasn't your > > intention... > > > > Or am I misinterpreting this? > > > > 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 17, 2014 at 1:11 PM, Scott Gray <[hidden email]> > > wrote: > > > >> From my perspective the confluence document seems to outline everything > >> pretty well. > >> > >> I think the 'trust' aspect would simply be that a voting PMC member is > >> able to trust that a potential committer would fulfill the the outlined > >> roles and responsibilities. The 'attitude' would simply be that the > >> potential committer is willing to follow advice and work well with > others. > >> Neither of these things are so strange that they'd need to be further > >> documented IMO. > >> > >> I can't speak for Jacopo or anyone else, that's just my interpretation. > >> > >> Regards > >> Scott > >> > >> On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> > wrote: > >> > >>> So, you - as any PMC member - can also elaborate on the consensus with > >>> respect to the attitude and trustability requirements regarding > potential > >>> committers (above and beyond the responsibilities, if these exist). > >>> > >>> Or - as it may be possible that I have misinterpreted the posting by > >> Jacopo > >>> - is it just about potential committers having the right mindset > towards > >>> the execution of tasks as described in the roles and responsibilities > >>> document? Meaning that they can apply due diligence before committing? > >> And > >>> that they can make their own interests subordinate to those of the > >>> community? > >>> > >>> 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 17, 2014 at 12:28 PM, Scott Gray < > [hidden email] > >>> > >>> wrote: > >>> > >>>> Pierre, > >>>> > >>>> Yes, in his opinion that is what we do. It's probably a correct > opinion > >>>> too (in my opinion). But at the end of the day my point stands, PMC > >>>> members are individuals and each have different opinions about what > >> makes a > >>>> good committer. > >>>> > >>>> I'm not trying to be combative, if you disagree I'm happy to discuss > it. > >>>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> > >> wrote: > >>>> > >>>>> Scott, > >>>>> > >>>>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in > >>>> direct > >>>>> relation to the words attitude and trust. So, he is not talking about > >>>> just > >>>>> his own feelings but about the collective perception. > >>>>> > >>>>> 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 17, 2014 at 12:09 PM, Scott Gray < > >> [hidden email] > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Hi Pierre, > >>>>>> > >>>>>> Jacopo's first words in that email were "In my opinion". That's an > >>>>>> extremely important point. > >>>>>> > >>>>>> There are no guidelines because each PMC member is free to vote > >> however > >>>>>> they feel would best serve the project. Any of us could provide our > >> own > >>>>>> personal guidelines but they would still just be personal opinions. > >>>>>> > >>>>>> Regards > >>>>>> Scott > >>>>>> > >>>>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> > >>>> wrote: > >>>>>> > >>>>>>> Jacopo, > >>>>>>> > >>>>>>> I your posting regarding the vote to keep the PROJECTMGR in > releases > >>>> (see > >>>>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you > >>>> addressed > >>>>>>> aspects as ' the right attitude' and 'trust them' in respect to > >>>> inviting > >>>>>>> committers. > >>>>>>> > >>>>>>> In the committers role and responsibilities page (see here: > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > >>>>>>> ) we can read about the responsibilities. But words like attitude > and > >>>>>> trust > >>>>>>> are not not mentioned. > >>>>>>> > >>>>>>> Can you, as the PMC Chair, explain what the vision and expectations > >> are > >>>>>>> regarding this right attitude and trust? > >>>>>>> > >>>>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < > >>>>>>> [hidden email]> 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 > >>>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > |
|
|
> I can image that you would feel that 'accept' is better than 'follow' with
> respect to advice. But it still sounds that you want a contributor to > comply to your advice. Then your interpretation is incorrect. A willingness to discuss contentious changes with an open mind is all I asked for. > We are dealing with people here who can make sound > judgement calls whether or not to accept and act accordingly. The > participants within this community are not sheep. No they aren't and I haven't said anything to imply that they are. > You are making more of this than it should be. I am? I'm just trying to answer your questions, I'm really not making anything out of this. > My advice to you is to relax your viewpoint on this and any contributor > showing commitment to the project. Are you saying we should accept contributors who aren't willing to discuss contentious changes with an open mind? That would seem strange to me. One big issue with adding more committers is that we currently have a very low commit:review ratio. Reviewing commits and dealing with any ensuing discussion is a very time consuming affair and very few existing committers and almost no contributors participate in that effort. Increasing the number of committers only increases that burden on the few reviewers we have and leads to a situation where committers can make almost any changes they like without being questioned. This potentially decreases the quality of the code base and results in a less maintainable and usable project. The problem is only exacerbated if we have lots of committers who aren't willing to discuss their work with an open mind. Regards Scott On 22/10/2014, at 1:21 am, Pierre Smits <[hidden email]> wrote: > Scott, > > I can image that you would feel that 'accept' is better than 'follow' with > respect to advice. But it still sounds that you want a contributor to > comply to your advice. We are dealing with people here who can make sound > judgement calls whether or not to accept and act accordingly. The > participants within this community are not sheep. > > You are making more of this than it should be. We have enough mitigating > procedures in place for the occasional committer that doesn't comply to > responsibilities outlined in the wiki page. > > If you have trust issues you should propose changes to the wiki document. > That way all participants in this project can increase their insights and > express their viewpoint about how and when contributors should be > considered and accepted or rejected by the PMC. > > Remember, this is a project for everybody participating. That you have > trust issues and therefor reject any committer who doesn't comply to your > advice, shouldn't lead to an increasing number of issues not getting > resolved. That way you are stifling the growth of our project. > > My advice to you is to relax your viewpoint on this and any contributor > showing commitment to the project. > > 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 Sat, Oct 18, 2014 at 11:21 AM, Scott Gray <[hidden email]> > wrote: > >> Perhaps "accept" is a better word than "follow", no one has ever >> questioned it in such detail. >> >> If there's disagreement about advice given then there only needs to be a >> willingness to discuss the matter. Obviously there are votes if things get >> out of hand but it's rare for things to go that far. If committers are >> unwilling to approach a disagreement with an open mind then it makes life >> difficult for everyone. >> >> Regards >> Scott >> >> On 18/10/2014, at 1:04 am, Pierre Smits <[hidden email]> wrote: >> >>> Scott, >>> >>> Am I correct in understanding that any contributor with ambitions to be a >>> committer should interpret your 'willing to follow advice' as >> 'willingness >>> to take good advice into consideration when acting within the community >> or >>> dealing with issues, but don't follow bad advice blindly'? Your 'willing >> to >>> follow' sounds a lot like 'must follow'. I trust that wasn't your >>> intention... >>> >>> Or am I misinterpreting this? >>> >>> 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 17, 2014 at 1:11 PM, Scott Gray <[hidden email]> >>> wrote: >>> >>>> From my perspective the confluence document seems to outline everything >>>> pretty well. >>>> >>>> I think the 'trust' aspect would simply be that a voting PMC member is >>>> able to trust that a potential committer would fulfill the the outlined >>>> roles and responsibilities. The 'attitude' would simply be that the >>>> potential committer is willing to follow advice and work well with >> others. >>>> Neither of these things are so strange that they'd need to be further >>>> documented IMO. >>>> >>>> I can't speak for Jacopo or anyone else, that's just my interpretation. >>>> >>>> Regards >>>> Scott >>>> >>>> On 17/10/2014, at 11:49 pm, Pierre Smits <[hidden email]> >> wrote: >>>> >>>>> So, you - as any PMC member - can also elaborate on the consensus with >>>>> respect to the attitude and trustability requirements regarding >> potential >>>>> committers (above and beyond the responsibilities, if these exist). >>>>> >>>>> Or - as it may be possible that I have misinterpreted the posting by >>>> Jacopo >>>>> - is it just about potential committers having the right mindset >> towards >>>>> the execution of tasks as described in the roles and responsibilities >>>>> document? Meaning that they can apply due diligence before committing? >>>> And >>>>> that they can make their own interests subordinate to those of the >>>>> community? >>>>> >>>>> 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 17, 2014 at 12:28 PM, Scott Gray < >> [hidden email] >>>>> >>>>> wrote: >>>>> >>>>>> Pierre, >>>>>> >>>>>> Yes, in his opinion that is what we do. It's probably a correct >> opinion >>>>>> too (in my opinion). But at the end of the day my point stands, PMC >>>>>> members are individuals and each have different opinions about what >>>> makes a >>>>>> good committer. >>>>>> >>>>>> I'm not trying to be combative, if you disagree I'm happy to discuss >> it. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 17/10/2014, at 11:19 pm, Pierre Smits <[hidden email]> >>>> wrote: >>>>>> >>>>>>> Scott, >>>>>>> >>>>>>> You are correct. Yet, you forgot to mention that Jacopo used 'we' in >>>>>> direct >>>>>>> relation to the words attitude and trust. So, he is not talking about >>>>>> just >>>>>>> his own feelings but about the collective perception. >>>>>>> >>>>>>> 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 17, 2014 at 12:09 PM, Scott Gray < >>>> [hidden email] >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Pierre, >>>>>>>> >>>>>>>> Jacopo's first words in that email were "In my opinion". That's an >>>>>>>> extremely important point. >>>>>>>> >>>>>>>> There are no guidelines because each PMC member is free to vote >>>> however >>>>>>>> they feel would best serve the project. Any of us could provide our >>>> own >>>>>>>> personal guidelines but they would still just be personal opinions. >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> On 17/10/2014, at 10:55 pm, Pierre Smits <[hidden email]> >>>>>> wrote: >>>>>>>> >>>>>>>>> Jacopo, >>>>>>>>> >>>>>>>>> I your posting regarding the vote to keep the PROJECTMGR in >> releases >>>>>> (see >>>>>>>>> here: http://ofbiz.markmail.org/message/maha6pwlatlxbb64 ) you >>>>>> addressed >>>>>>>>> aspects as ' the right attitude' and 'trust them' in respect to >>>>>> inviting >>>>>>>>> committers. >>>>>>>>> >>>>>>>>> In the committers role and responsibilities page (see here: >>>>>>>>> >>>>>>>> >>>>>> >>>> >> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities >>>>>>>>> ) we can read about the responsibilities. But words like attitude >> and >>>>>>>> trust >>>>>>>>> are not not mentioned. >>>>>>>>> >>>>>>>>> Can you, as the PMC Chair, explain what the vision and expectations >>>> are >>>>>>>>> regarding this right attitude and trust? >>>>>>>>> >>>>>>>>> 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 Thu, Oct 2, 2014 at 3:22 PM, Jacopo Cappellato < >>>>>>>>> [hidden email]> 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 >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> |
|
|
Scott,
I thank you for your patience and eloquence to explain your viewpoint as a PMC Member regarding the subject to every participant in this community. For sure, the willingness of every participant in this community to discuss contentious or controversial issues with an open mind (and with the best interest of the project at heart) is something that will have the consensus of all within this community. We understand that you are expressing only your viewpoint and concerns as only one member of the PMC. I wonder: is this low commit:review ratio you're talking of supported by any kind of numbers? And is this complaint/concern you're expressing not the result of the code of conduct for committers, or lack thereof? Why is this now - while we are discussing how to get more committers - a reason for concern? And is this a concern of all PMC Members? We have had very little complaints about such code commits up to now. And if there were any, these issues were resolved quite fast. Isn't it so that committers review code patches by contributors? And that it is part of the responsibilities of committers. But we also know that committers review committed bugfixes by other committers seldomly. But we trust committers to do the right thing when committing changes, don't we? Are you now saying that the PMC is regarding this as something to be concerned about? And that all within this community should be concerned about this? That current committers don't apply due diligence when it comes to committing changes? And that we must have some kind of super-committer policing the committers? With as a result of not having enough super-committers, the entire PMC feels that we must accept that not more eligible contributors are invited to be a committer? I wonder, given that you say that you don't speak for any of the other PMC Members - except Jacopo, can each of the other PMC members share her or his viewpoint on this? The controversy regarding commits I can think of (at the top of my head) is that the PMC allows major extensions (improvements) to be committed without prior review. The other controversy I can think of is that, while you are trying to explain at great lengths how cautionary the PMC is with respect to inviting new committers (and new PMC members), a contributor with only 178 postings in the user ml, 114 in the dev ml, and about 11 patches submitted and 2 publications in a period of 6 years makes it to become both committer and PMC member within the last 3 months of those 6 years.. Though welcome the addition is, this contradicts anything of the concerns you expressed. Again, I understand and accept that you are expressing only your viewpoint. So again, I invite every other PMC Member to share her or his viewpoint as well. So that the entire community can learn how this issue, this controversy is regarded in the entire PMC. As always, and discussing with an open mind, Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
|
|
I wonder if some of this could be solved by breaking the project into
sub-projects. This would allow the "super-committers" to focus on those projects where the risk of incorrect code being submitted is high or where the impact of coding missteps would have the biggest impact on the overall stability and reliability of the entire suite. The projects where code errors are more easily detected or have only local impact could be tested and reviewed by people with different skills. It would also encourage a clear delineation between projects which would reduce the scope of the impact of code errors. It would also attract more reviewers and contributors since the scope of one's involvement would be clearer and would allow people to get active in areas that interest them. At the moment it seems that the project is too big and too complex so that the current committers have too many areas to watch and are unsure about how to attract and vet new people. It might also make the process of fiddling with the core much cleaner. If a committer on a sub-project needs to have a change to the core, they would have to request this and there would be a discussion about the impact on the core and other dependent projects. It appears that this might be missing in the current setup and some of the "trust" issues have come about from experience where changes made to support a particular business case have had impacts that the contributor did not anticipate. Ron On 21/10/2014 9:27 PM, Pierre Smits wrote: > Scott, > > I thank you for your patience and eloquence to explain your viewpoint as a > PMC Member regarding the subject to every participant in this community. > > For sure, the willingness of every participant in this community to discuss > contentious or controversial issues with an open mind (and with the best > interest of the project at heart) is something that will have the consensus > of all within this community. > > We understand that you are expressing only your viewpoint and concerns as > only one member of the PMC. > > I wonder: is this low commit:review ratio you're talking of supported by > any kind of numbers? And is this complaint/concern you're expressing not > the result of the code of conduct for committers, or lack thereof? Why is > this now - while we are discussing how to get more committers - a reason > for concern? And is this a concern of all PMC Members? > > We have had very little complaints about such code commits up to now. And > if there were any, these issues were resolved quite fast. Isn't it so that > committers review code patches by contributors? And that it is part of the > responsibilities of committers. But we also know that committers review > committed bugfixes by other committers seldomly. But we trust committers to > do the right thing when committing changes, don't we? > > Are you now saying that the PMC is regarding this as something to be > concerned about? And that all within this community should be concerned > about this? That current committers don't apply due diligence when it comes > to committing changes? And that we must have some kind of super-committer > policing the committers? With as a result of not having enough > super-committers, the entire PMC feels that we must accept that not more > eligible contributors are invited to be a committer? > > I wonder, given that you say that you don't speak for any of the other PMC > Members - except Jacopo, can each of the other PMC members share her or his > viewpoint on this? > > The controversy regarding commits I can think of (at the top of my head) is > that the PMC allows major extensions (improvements) to be committed without > prior review. > > The other controversy I can think of is that, while you are trying to > explain at great lengths how cautionary the PMC is with respect to inviting > new committers (and new PMC members), a contributor with only 178 postings > in the user ml, 114 in the dev ml, and about 11 patches submitted and 2 > publications in a period of 6 years makes it to become both committer and > PMC member within the last 3 months of those 6 years.. > > Though welcome the addition is, this contradicts anything of the concerns > you expressed. > > Again, I understand and accept that you are expressing only your viewpoint. > So again, I invite every other PMC Member to share her or his viewpoint as > well. So that the entire community can learn how this issue, this > controversy is regarded in the entire PMC. > > As always, and discussing with an open mind, > > Best regards, > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Pierre Smits
How is it that you are able to extract so many paragraphs out of the few sentences I wrote?
What are you trying to achieve here? As far as I can tell you're the only one who has questions about how a contributor becomes a committer. How much detail is required for something that requires a nomination and then a vote? It's a pretty straightforward process. I'll try and respond quickly to sentences posed at questions but I'd really rather not continue to this spiral into deeper and deeper discussion. > I wonder: is this low commit:review ratio you're talking of supported by > any kind of numbers? it isn't but it's historically been the case and I haven't noticed it change. Feel free to look up some numbers if you like. > And is this complaint/concern you're expressing not > the result of the code of conduct for committers, or lack thereof? No, it's a community issue, code review is an important part of open-source and it doesn't require any special access to perform. > Why is > this now - while we are discussing how to get more committers - a reason > for concern? It always been a concern of mine, nothing new in it. I didn't know we were discussing how to get more committers, the thread started out with you querying some of Jacopo's wording. > And is this a concern of all PMC Members? I have no idea, we don't hold secret meetings to discuss such things. > Isn't it so that > committers review code patches by contributors? Of course the committer that intends to commit the patch reviews it. But who reviews the committer? > But we also know that committers review > committed bugfixes by other committers seldomly. But we trust committers to > do the right thing when committing changes, don't we? It's not about doing the "right thing", it's about reviewing each others work to ensure quality. Reviews are not about catching a committer intentionally doing something wrong, that's a silly idea. > Are you now saying that the PMC is regarding this as something to be > concerned about? No, I'm saying it is something I'm concerned about. > And that all within this community should be concerned > about this? I guess so. > That current committers don't apply due diligence when it comes > to committing changes? You're stretching a long bow on that one and I never said anything like that. This is one of the frustrating parts of discussing anything with you, you like to take small statements and make outrageous claims based on them. No one commits perfect code and code review is an important part of open source. > And that we must have some kind of super-committer > policing the committers? Not at all, anyone can review a commit, there is no hierarchy in this community dictating that one must somehow be superior to another in order to question them. Surely this thread is proof of that? > With as a result of not having enough > super-committers, the entire PMC feels that we must accept that not more > eligible contributors are invited to be a committer? The bow stretches further and further. I have no idea how the entire PMC feels. I was merely stating that I think it is a bigger problem than a lack of committers. > I wonder, given that you say that you don't speak for any of the other PMC > Members - except Jacopo, can each of the other PMC members share her or his > viewpoint on this? I've quite clearly stated a few times in this thread that I don't speak for Jacopo. That statement feels like you're trying to troll me when I'm taking time out to discuss your questions with you and I don't appreciate it. > The other controversy I can think of is that, while you are trying to > explain at great lengths how cautionary the PMC is with respect to inviting > new committers (and new PMC members), a contributor with only 178 postings > in the user ml, 114 in the dev ml, and about 11 patches submitted and 2 > publications in a period of 6 years makes it to become both committer and > PMC member within the last 3 months of those 6 years.. You've obviously spent some time doing some serious counting there. To what end? Do you have some issue with the outcome of those votes? Keep in mind however that a few numbers don't in themselves mean anything. The value of a contribution can't be measured by how many emails were sent. On 22/10/2014, at 2:27 pm, Pierre Smits <[hidden email]> wrote: > Scott, > > I thank you for your patience and eloquence to explain your viewpoint as a > PMC Member regarding the subject to every participant in this community. > > For sure, the willingness of every participant in this community to discuss > contentious or controversial issues with an open mind (and with the best > interest of the project at heart) is something that will have the consensus > of all within this community. > > We understand that you are expressing only your viewpoint and concerns as > only one member of the PMC. > > I wonder: is this low commit:review ratio you're talking of supported by > any kind of numbers? And is this complaint/concern you're expressing not > the result of the code of conduct for committers, or lack thereof? Why is > this now - while we are discussing how to get more committers - a reason > for concern? And is this a concern of all PMC Members? > > We have had very little complaints about such code commits up to now. And > if there were any, these issues were resolved quite fast. Isn't it so that > committers review code patches by contributors? And that it is part of the > responsibilities of committers. But we also know that committers review > committed bugfixes by other committers seldomly. But we trust committers to > do the right thing when committing changes, don't we? > > Are you now saying that the PMC is regarding this as something to be > concerned about? And that all within this community should be concerned > about this? That current committers don't apply due diligence when it comes > to committing changes? And that we must have some kind of super-committer > policing the committers? With as a result of not having enough > super-committers, the entire PMC feels that we must accept that not more > eligible contributors are invited to be a committer? > > I wonder, given that you say that you don't speak for any of the other PMC > Members - except Jacopo, can each of the other PMC members share her or his > viewpoint on this? > > The controversy regarding commits I can think of (at the top of my head) is > that the PMC allows major extensions (improvements) to be committed without > prior review. > > The other controversy I can think of is that, while you are trying to > explain at great lengths how cautionary the PMC is with respect to inviting > new committers (and new PMC members), a contributor with only 178 postings > in the user ml, 114 in the dev ml, and about 11 patches submitted and 2 > publications in a period of 6 years makes it to become both committer and > PMC member within the last 3 months of those 6 years.. > > Though welcome the addition is, this contradicts anything of the concerns > you expressed. > > Again, I understand and accept that you are expressing only your viewpoint. > So again, I invite every other PMC Member to share her or his viewpoint as > well. So that the entire community can learn how this issue, this > controversy is regarded in the entire PMC. > > As always, and discussing with an open mind, > > Best regards, > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com |
|
|
In reply to this post by Pierre Smits
I am not speaking for Scott, but I want to clarify something here.
Many times these discussions imply that there is some kind of hierarchy in the community - with the PMC being in charge. As has been stated before, the PMC has very little authority, and the hierarchy that is implied in these discussions goes against the spirit of this community - where we are all peers. So, the PMC does not "allow" things, nor does it "prohibit" things. At most, the PMC will advise - and that advice carries with it the collective experience of its members. But, like any advice, it can be ignored. I know there are some in the community who would like to see the PMC take on a statist role and exercise more control over the community, but that is not going to happen. Regarding commit review: There are no metrics for commit review other than the messages on the dev mailing list. When you see a reply to a commit message, that reply is a de-facto commit review. Looking through the dev mailing list history will give you a good sense of the review activity. Even then, the metric is not accurate because commits might be reviewed without generating a reply. Personally, I try to review framework commits. My free time is very limited, so I need to prioritize what I review. From my perspective, a regression introduced in an application (where it affects only one application) is not as serious as a regression introduced in the framework (where it affects ALL applications). This is my review strategy based on my preference - it has nothing to do with the PMC. The PMC does not tell me what to review and how much to review. So, when you say things like: "the PMC allows major extensions (improvements) to be committed without prior review" - you are misunderstanding how this community works. The PMC does not "allow" or "prohibit" commits. If there is a concern about a commit, the PMC will offer advice about that commit. That advice can be ignored. If anyone strongly objects to the commit, then the commit can be vetoed by a PMC member - in which case the commit SHOULD be reverted (this depends on the cooperation of the committer). There was one case of a committer who refused to revert a vetoed commit, and threatened a commit war if anyone else tried to revert it. That resulted in a year-long discussion, and eventually the committer grudgingly agreed to let someone else revert the commit. That episode resulted in hurt feelings and it seriously undermined the cooperation in the community. I mention it because I want to stress the importance of mutual cooperation - without it, the community breaks down. It also illustrates the self-imposed limitations the PMC has - the PMC did not "kick out" the uncooperative committer, but instead continued to plead for common sense and cooperation. So, that is how this community works. We are all volunteers, we are all members of a minarchist community, and we all need to compromise and get along with each other for the benefit of the common good. Adrian Crum Sandglass Software www.sandglass-software.com On 10/22/2014 2:27 AM, Pierre Smits wrote: > Scott, > > I thank you for your patience and eloquence to explain your viewpoint as a > PMC Member regarding the subject to every participant in this community. > > For sure, the willingness of every participant in this community to discuss > contentious or controversial issues with an open mind (and with the best > interest of the project at heart) is something that will have the consensus > of all within this community. > > We understand that you are expressing only your viewpoint and concerns as > only one member of the PMC. > > I wonder: is this low commit:review ratio you're talking of supported by > any kind of numbers? And is this complaint/concern you're expressing not > the result of the code of conduct for committers, or lack thereof? Why is > this now - while we are discussing how to get more committers - a reason > for concern? And is this a concern of all PMC Members? > > We have had very little complaints about such code commits up to now. And > if there were any, these issues were resolved quite fast. Isn't it so that > committers review code patches by contributors? And that it is part of the > responsibilities of committers. But we also know that committers review > committed bugfixes by other committers seldomly. But we trust committers to > do the right thing when committing changes, don't we? > > Are you now saying that the PMC is regarding this as something to be > concerned about? And that all within this community should be concerned > about this? That current committers don't apply due diligence when it comes > to committing changes? And that we must have some kind of super-committer > policing the committers? With as a result of not having enough > super-committers, the entire PMC feels that we must accept that not more > eligible contributors are invited to be a committer? > > I wonder, given that you say that you don't speak for any of the other PMC > Members - except Jacopo, can each of the other PMC members share her or his > viewpoint on this? > > The controversy regarding commits I can think of (at the top of my head) is > that the PMC allows major extensions (improvements) to be committed without > prior review. > > The other controversy I can think of is that, while you are trying to > explain at great lengths how cautionary the PMC is with respect to inviting > new committers (and new PMC members), a contributor with only 178 postings > in the user ml, 114 in the dev ml, and about 11 patches submitted and 2 > publications in a period of 6 years makes it to become both committer and > PMC member within the last 3 months of those 6 years.. > > Though welcome the addition is, this contradicts anything of the concerns > you expressed. > > Again, I understand and accept that you are expressing only your viewpoint. > So again, I invite every other PMC Member to share her or his viewpoint as > well. So that the entire community can learn how this issue, this > controversy is regarded in the entire PMC. > > As always, and discussing with an open mind, > > Best regards, > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > |
Re: OFBiz and Attitude & Trust
Administrator
|
In reply to this post by Scott Gray-2
Le 22/10/2014 08:17, Scott Gray a écrit : > it's a community issue, code review is an important part of open-source and it doesn't require any special access to perform. A very important point, thanks to highlight that Scott! jacques PS: sorry if I tore too much parts apart, I just want to highlight it even more! |
Re: OFBiz and Attitude & Trust
|
|
Hi Jacques, i felt the same !
So +1 ! Gil Le 22/10/2014 11:59, Jacques Le Roux a écrit :
--
|
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |