Quoting: they basically have to be extracted into a patch file and submitted through a Jira issue
Which is a good approach with respect to improvements of the other kind (improvements, not bug fixes) as they than can be assessed, regarding applicability in light of the direction of the project and its works, by all in the community. And not through some filtering mech of the various subsets (of controlling/directing/dictating entities) of the community before the contribution of the individual gets to the project. It is the amalgamation/aggregation in the hierarchy described (by David) that should be of more concern than the mere technical aspects of the tool applied. 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 On Tue, Apr 21, 2015 at 12:19 PM, Jacques Le Roux < [email protected]> wrote: > > Le 21/04/2015 12:02, David E. Jones a écrit : > >> On 20 Apr 2015, at 23:21, Pierre Smits <[email protected]> wrote: >>> >>> Quoting: >>> >>> We are also prepared to be assertive regarding this situation. If the >>> project >>> does not move to GIT then Brainfood is willing to participate in a >>> consortium of >>> organizations that will peer with each other to share updates to the >>> master >>> branch for their local OFBiz repository. Such an arrangement will, >>> effectively, >>> result in a distributed master repository image. >>> >>> Thanks Ean for the position of *Brainfood* in this position. It comes >>> across as 'Do it our way, or else'. You are free to make such statements >>> and when followed through there will be consequences. For all >>> participating >>> in this project. One I can see standing out clearly is: no more >>> participation in/contribution from the employees of Brainfood and from >>> the >>> other companies in that consortium back into the project. >>> >> That's not at all what I get from Ean's comments. The magic of a >> community-driven project is that people can collaborate on anything they >> want, within the scope of the main project or as side projects. If the main >> project doesn't provide something desired, then it is perfectly appropriate >> for others to collaborate on that... better than doing it totally isolated. >> >> What Ean is talking about ties in with the general idea of distributed >> source management and distributed development. The general idea is that >> there may be many forks of the main source repo, potentially with various >> branches for different improvements and changes. These are generally made >> available publicly, like public GitHub forks of other public repositories >> (though with git they can be hosted anywhere). >> >> Those who make changes can request that particular changes be pulled into >> upstream repositories and then those who maintain the upstream repos (or >> the main project repo if it bubbles up that high) can review them and pull >> the changes if desired. Those who maintain upstream repos can also look >> around for useful changes in forked repos and pull them in as desired. >> Others who run their own forks can pull in changes from peer repositories >> too. >> >> It may seem like chaos to have forks and changes spread all over the >> place... but that isn't caused by the distributed source management >> approach, it's just made visible and clear by the approach. Right now this >> exists on a large scale for OFBiz, tons of forks and changes in them, but >> they are mostly not visible or publicly available so there is no way for >> OFBiz committers to pull changes from other repos... they basically have to >> be extracted into a patch file and submitted through a Jira issue. >> >> In other words, the chaos exists and the distributed source management >> enabled by git just makes it easier to track it all and tame it a bit. >> >> On a side note, this is one of the reasons I have concerns about making >> Moqui and related projects part of the ASF: the ASF community approach >> doesn't fit very well with this distributed source management model (pull >> requests are discouraged, all contributions should go through Jira >> issues... though I don't know that this is a strict policy). >> >> -David >> > > Interesting David, it can be compared to the OFBiz-France association > effort to leverage the Nereides addons and addons manager. I let aside the > licenses issues, as long as it's no part of a released package there are no > problems. > What do you think OFBiz-France members? > > Jacques > > > >> If that is going to happen, I will say: 'I thank you for all the >>> contributions you did to the project'. And I will check in my sentiments >>> at >>> the door. I do hope that if you do you also resign totally from this >>> project. >>> >>> >>> I rather have the community comes to its decision based on sound/valid >>> arguments, not (veiled) threats. >>> >>> 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 >>> >>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <[email protected]> >>> wrote: >>> >>> ----- Original Message ----- >>>> >>>>> From: "Jacques Le Roux" <[email protected]> >>>>> Subject: Re: move to git. >>>>> Like Adrian and mostly for the same reasons, I don't believe we need >>>>> Git. >>>>> >>>>> But there is one other major reason which has already been discussed in >>>>> >>>> the >>>> >>>>> other common ASF MLs. As Taher exulted, it's possible to create local >>>>> branches. So people are able to do a lot of work alone without >>>>> >>>> exchanging before >>>> >>>>> committing or submitting. It will certainly not help to have this >>>>> possibility. >>>>> >>>> I disagree. It is useful in many situations for OFBiz developers to >>>> create >>>> a >>>> local repository that is not globally shared. Some customers may even >>>> require >>>> such a situation for security or legal reasons. >>>> >>>> Remember our recent discussion on the lack or core commits reviews. >>>>> With Git you end with commits bursts or big patches and it's then >>>>> hard to review and too late to share ideas. >>>>> >>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to >>>>> >>>> use a -1 >>>> >>>>> if necessary! >>>>> >>>> We are also prepared to be assertive regarding this situation. If the >>>> project >>>> does not move to GIT then Brainfood is willing to participate in a >>>> consortium of >>>> organizations that will peer with each other to share updates to the >>>> master >>>> branch for their local OFBiz repository. Such an arrangement will, >>>> effectively, >>>> result in a distributed master repository image. >>>> >>>> If anyone else is interested in such an arrangement please feel free to >>>> speak >>>> up and we can begin the planning process. >>>> >>>> >> >>
