move to git.
Locked
123456
... 8
123456
... 8
 
|
On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <[hidden email]> wrote:
>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. >> >> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. > > I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo |
Administrator
|
In reply to this post by Pierre Smits
That's indeed what needs to be discussed and that why I asked OFBiz-France members opinions
Jacques Le 21/04/2015 12:52, Pierre Smits a écrit : > Sharing those improvements as patches attached to JIRA issues is a way > better mechanism for exposure and review than through the distributed and > competing search/find tools of today (Google et all) into all the > distributed repositories or forks. > > Best regards, > > Pierre. > > Op dinsdag 21 april 2015 heeft Sharan Foga <[hidden email]> het > volgende geschreven: > >> Hi All >> >> I've been looking at some of what OFBiz France has done regarding addons >> for OFBiz . I think there are a lot of useful things that have been >> contributed by the community in general (not only OFBiz France) that are >> either sitting in forks or addons or just in Jira that haven't really been >> visible to the community. >> >> Making them visible gives the community more freedom and choice - whatever >> tool is used. >> >> Thanks >> Sharan >> >> >> >> On 21.4.2015 12:19, Jacques Le Roux wrote: >> >>> Le 21/04/2015 12:02, David E. Jones a écrit : >>> >>>> On 20 Apr 2015, at 23:21, Pierre Smits <[hidden email]> 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 <[hidden email]> >>>>> wrote: >>>>> >>>>> ----- Original Message ----- >>>>>>> From: "Jacques Le Roux" <[hidden email]> >>>>>>> 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. >>>>>> >>>>>> >>>> |
|
|
In reply to this post by Jacopo Cappellato-5
Everyone is missing the point I am trying to make.
I said, "***IF*** Jacopo said something like..." As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: > On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <[hidden email]> wrote: > >>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. >>> >>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. >> >> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. > > In fact I didn't express my opinion or preference. > At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. > In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. > > Jacopo > |
|
Administrator
|
Thanks for clarification Adrian,
I did not think about the Release Manager role Jacques Le 21/04/2015 12:59, Adrian Crum a écrit : > Everyone is missing the point I am trying to make. > > I said, "***IF*** Jacopo said something like..." > > As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be > obvious. > > I hope that clarifies my true meaning. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: >> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <[hidden email]> wrote: >> >>>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If >>>> Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having >>>> this discussion, it would just happen because the need for the switch is obvious. >>>> >>>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. >>> >>> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git >>> and they would like to see OFBiz using it as well. >> >> In fact I didn't express my opinion or preference. >> At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. >> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to >> review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. >> >> Jacopo >> > |
|
|
In reply to this post by Adrian Crum-3
@Adrian: I didn't miss your point! Opted not to respond, as I saw nothing
wrong with/in the assertion/point you posted. 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:59 PM, Adrian Crum < [hidden email]> wrote: > Everyone is missing the point I am trying to make. > > I said, "***IF*** Jacopo said something like..." > > As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage > the OFBiz project, then the need to switch to something else would be > obvious. > > I hope that clarifies my true meaning. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: > >> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >> Switching the main repo to Git does not add anything to the project >>>> itself. As I said before, Subversion handles our simple needs just fine. If >>>> Jacopo said something like, "Managing our releases is impossible with >>>> Subversion, we really need to switch to Git" - then we wouldn't be having >>>> this discussion, it would just happen because the need for the switch is >>>> obvious. >>>> >>>> But Jacopo is not saying that, and we don't have a problem using >>>> Subversion to manage the project. >>>> >>> >>> I don't remember Jacopo proposed to move to Git, it was Hans, then >>> Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using >>> Git and they would like to see OFBiz using it as well. >>> >> >> In fact I didn't express my opinion or preference. >> At Hotwax we use Git for all our projects and we are happy with it. But >> this doesn't mean that svn is bad or old or not a good tool for OFBiz. >> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs >> git" as mere tools, it would be more interesting and useful to >> review/discuss the contribution/commit workflows that these tools can >> enable and see if there is a room for a better workflow for the project. >> >> Jacopo >> >> |
|
|
In reply to this post by Adrian Crum-3
On Apr 21, 2015, at 12:59 PM, Adrian Crum <[hidden email]> wrote:
> Everyone is missing the point I am trying to make. > > I said, "***IF*** Jacopo said something like..." > > As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. > > I hope that clarifies my true meaning. > > Adrian Crum It was clear to me since your first message but I have replied to Jacques as I was starting to feel dragged (or, in the context of git, I should say "pulled") into the mix :-) Jacopo |
|
|
As far as I can see it, this whole discussion regarding GIT vs SVN (move to
GIT), is dependent on and blocked by the perceptions of (and viewpoints on) the (in)clarity surrounding how we (as the contributing community) deal with code-changing contributions (CTR vs RTC/patches vs dumps). If we don’t deal with that first, I see blockers on the road forward every time we reiterate this GIT vs SVN discussion. Like it there were before and are now. It seems we (all) need a realignment and/or re-acceptance of our G & C (of the GRC) in that area first. 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 1:22 PM, Jacopo Cappellato < [hidden email]> wrote: > On Apr 21, 2015, at 12:59 PM, Adrian Crum < > [hidden email]> wrote: > > > Everyone is missing the point I am trying to make. > > > > I said, "***IF*** Jacopo said something like..." > > > > As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to > manage the OFBiz project, then the need to switch to something else would > be obvious. > > > > I hope that clarifies my true meaning. > > > > Adrian Crum > > It was clear to me since your first message but I have replied to Jacques > as I was starting to feel dragged (or, in the context of git, I should say > "pulled") into the mix :-) > > Jacopo > > |
|
Administrator
|
In reply to this post by Pierre Smits
That's an important point indeed Pierre.
One thing we need to clarify is how "Git at the ASF" https://git-wip-us.apache.org/ allows to search between branches and forks, compared to svn and patches in Jira Of course we could add our own policy and tools It doesn't mean I'm for using Git, it's only to allow comparing the alternatives. I have invested in using Jira and I'd really miss it... Jacques Le 21/04/2015 12:52, Pierre Smits a écrit : > Sharing those improvements as patches attached to JIRA issues is a way > better mechanism for exposure and review than through the distributed and > competing search/find tools of today (Google et all) into all the > distributed repositories or forks. > > Best regards, > > Pierre. > > Op dinsdag 21 april 2015 heeft Sharan Foga <[hidden email]> het > volgende geschreven: > >> Hi All >> >> I've been looking at some of what OFBiz France has done regarding addons >> for OFBiz . I think there are a lot of useful things that have been >> contributed by the community in general (not only OFBiz France) that are >> either sitting in forks or addons or just in Jira that haven't really been >> visible to the community. >> >> Making them visible gives the community more freedom and choice - whatever >> tool is used. >> >> Thanks >> Sharan >> >> >> >> On 21.4.2015 12:19, Jacques Le Roux wrote: >> >>> Le 21/04/2015 12:02, David E. Jones a écrit : >>> >>>> On 20 Apr 2015, at 23:21, Pierre Smits <[hidden email]> 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 <[hidden email]> >>>>> wrote: >>>>> >>>>> ----- Original Message ----- >>>>>>> From: "Jacques Le Roux" <[hidden email]> >>>>>>> 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. >>>>>> >>>>>> >>>> |
|
|
In reply to this post by Jacques Le Roux
Hi all,
First to clarify things, OFBiz-france association goal is to promote Apache OFBiz into french speaking audience by giving references (information, classifications and links) to extensions (documentations, addons, patchs or packaged solution), maybe hosting some high quality not contributable extensions. Helping extensions' owner improving their quality to convert its into OFBiz contribution if possible, or referencing them for easy sharing of classified solutions. Creating a tool integrated into Apache OFBiz too manage and share anyone devs by implementing a new extension manager (http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr without success for now :) ) Nereide Leverage of addon solutions, like you introduce is just an illustration of this process. Nereide as a member of the association will give as example some instance of extensions, hoping that other contribution and contributor will come (and be welcome). I think that this git solution of *creating a consortium [...]* is quite different (even if i do not understand all the ins and out of it) and might be more comparable to ofbizextra effort, to give the ability for everyone to develop and share using a dedicated tool. And because everything which is committed into Apache OFBiz project has to be validated, and development within Integrators Projects do not have the same rythm/pace, ofbizextra was created to store and share unfinished/specific/not ready quality wise devs and this has to be out of Apache OFBiz. My personal opinion is (i'm not a git user), that SVN seems quite sufficient for Apache OFBiz needs. I remind me reading that there is already a git repository of the trunk branch so, if true, it can be used by contributor too make their devs using it. I'm not relevent evaluating git usage, but i do not feel a real problem using SVN. In every case, contribution will have to be given within Jira to get into the project. Best Regards Gil On 21/04/2015 12:19, Jacques Le Roux wrote: > > Le 21/04/2015 12:02, David E. Jones a écrit : >>> On 20 Apr 2015, at 23:21, Pierre Smits <[hidden email]> 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 <[hidden email]> >>> wrote: >>> >>>> ----- Original Message ----- >>>>> From: "Jacques Le Roux" <[hidden email]> >>>>> 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. >>>> >> >> |
|
|
In reply to this post by Pierre Smits
I agree it is important to consider the current situation and the possible workflows before discussing the tools.
Currently we do the following: * trunk is where all development happens * most of the commits to trunk are done following the Commit Then Review workflow; sometimes, for more complex or controversial changes, we follow the Review Then Commit workflow; sometimes we create experimental branches that are then merged into the trunk * release branches are stabilization branches: snapshots of the trunk at a given point of time, then (mostly) only backporting of bugs are done * a new release branch is approximately created every year * release branches are actively maintained for 3-4 years When we discuss version control systems (e.g. svn, git) for OFBiz, we should also consider the following questions: * is the current workflow the best for OFBiz and its ecosystem? * if we want to change the workflow, which one we would be the best? For example: Forking Workflow, Gitflow Workflow, Feature Branch Workflow etc... * is the new workflow compatible with the ASF guidelines and rules? * what is the best tool for the new workflow? e.g. git, svn Regards, Jacopo On Apr 21, 2015, at 2:11 PM, Pierre Smits <[hidden email]> wrote: > As far as I can see it, this whole discussion regarding GIT vs SVN (move to > GIT), is dependent on and blocked by the perceptions of (and viewpoints on) > the (in)clarity surrounding how we (as the contributing community) deal > with code-changing contributions (CTR vs RTC/patches vs dumps). > > If we don’t deal with that first, I see blockers on the road forward every > time we reiterate this GIT vs SVN discussion. Like it there were before and > are now. > > It seems we (all) need a realignment and/or re-acceptance of our G & C (of > the GRC) in that area first. > > 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 1:22 PM, Jacopo Cappellato < > [hidden email]> wrote: > >> On Apr 21, 2015, at 12:59 PM, Adrian Crum < >> [hidden email]> wrote: >> >>> Everyone is missing the point I am trying to make. >>> >>> I said, "***IF*** Jacopo said something like..." >>> >>> As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to >> manage the OFBiz project, then the need to switch to something else would >> be obvious. >>> >>> I hope that clarifies my true meaning. >>> >>> Adrian Crum >> >> It was clear to me since your first message but I have replied to Jacques >> as I was starting to feel dragged (or, in the context of git, I should say >> "pulled") into the mix :-) >> >> Jacopo >> >> |
|
|
In reply to this post by Pierre Smits
Comments inline.
> From: "Pierre Smits" <[hidden email]> > Subject: Re: move to git. > Quoting: > We are also prepared to be assertive regarding this situation. <SNIP> > 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. > > 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 believe what I said was "we'll do it our way even if you continue to do it your way". I'm not sure what the "or else" part of my message was. I would ask you to explain that to me but I'm not sure its important to the discussion. > I rather have the community comes to its decision based on sound/valid > arguments, not (veiled) threats. There were no threats in my message. A threat might read like "no participation in/contribution from {insert group here} will be allowed if they try to do something without my permission". The Apache Way is to "be nice" and I think it would be nice if people could pursue their own ideas about how to improve the project as long as they do not coerce other members. |
|
|
In reply to this post by David E. Jones-2
Comments inline.
> From: "David E. Jones" <[hidden email]> > Subject: Re: move to git. > 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. Precisely so. With GIT the chaos stays at its source until other players decide it is worth pulling into their copies of the world. With SVN you get the chaos of every committer whether you want it or not. (Note: this includes Brainfood's chaos for anyone who wants to mischaracterize my comments as an attack) > 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). At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire. |
|
|
Quoting:
At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire. If we want to explore that path, I suggest we do that in a separate thread. 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 3:35 PM, Ean Schuessler <[hidden email]> wrote: > Comments inline. > > > From: "David E. Jones" <[hidden email]> > > Subject: Re: move to git. > > > 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. > > Precisely so. With GIT the chaos stays at its source until other players > decide > it is worth pulling into their copies of the world. With SVN you get the > chaos > of every committer whether you want it or not. (Note: this includes > Brainfood's > chaos for anyone who wants to mischaracterize my comments as an attack) > > > 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). > > At Apachecon, Apache's engineering and corporate leadership advised me > that we > could move to using OFBiz to manage our issues instead of JIRA if we so > desire. > |
|
Administrator
|
Le 21/04/2015 16:00, Pierre Smits a écrit :
> Quoting: > > At Apachecon, Apache's engineering and corporate leadership advised me that > we > could move to using OFBiz to manage our issues instead of JIRA if we so > desire. > > > If we want to explore that path, I suggest we do that in a separate thread. Please don't, so we would not only move to Git and/or Maven and/or Moqui but while doing so we would also compete with Jira? :-o Jacques > > 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 3:35 PM, Ean Schuessler <[hidden email]> wrote: > >> Comments inline. >> >>> From: "David E. Jones" <[hidden email]> >>> Subject: Re: move to git. >>> 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. >> Precisely so. With GIT the chaos stays at its source until other players >> decide >> it is worth pulling into their copies of the world. With SVN you get the >> chaos >> of every committer whether you want it or not. (Note: this includes >> Brainfood's >> chaos for anyone who wants to mischaracterize my comments as an attack) >> >>> 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). >> At Apachecon, Apache's engineering and corporate leadership advised me >> that we >> could move to using OFBiz to manage our issues instead of JIRA if we so >> desire. >> |
|
|
In reply to this post by Jacopo Cappellato-5
On 21/04/2015 6:55 AM, Jacopo Cappellato wrote:
> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <[hidden email]> wrote: > >>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. >>> >>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. >> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. > In fact I didn't express my opinion or preference. > At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. > In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. > > Jacopo I think that this is a very good summary of the issue. It appears to me that there is a fundamental shift of philosophy that "Move to git" is discussing rather than a tool switch. With git it is much easier to develop parallel "products". I could chose to follow Jacopo's public repo or Ean's rather than the "official" OFBiz repo if I felt that they were doing things that I liked that were not being committed to the OFBiz repo. I could take changes from more than one repo if I felt that I could handle the integration workload and maintain a blended product. I could make changes and request that any other repo that wanted to have them, take them but I have no guarantee that Jacopo, Ean or OFBiz would accept them. I could use the Apache JIRA to document my patch or not. Clearly a JIRA issue would get more discussion and might cause me to revise my "contribution" or make it more likely to be accepted if the concensus is that it is a "good thing". I could create my own issue tracking system and invite others to look there for my ideas. Each one of the versions could have its own release schedule. This is substantially different that the current situation and I think that Jacopo's suggested course of action of looking at the proposal as a question of workflow is a good idea. Underlying this discussion, there is a dissatisfaction with the workflow expressed by people who are not committers (in general). There are a lot of private forks of OFBiz already but most of the ones that show up here are based on the OFBiz trunk and are produced by committers who contribute back some of their local changes. In some ways, moving to a more distributed system, does help make OFBiz stronger. The keepers of the OFBiz repo have control as they do now about what changes get incorporated into the OFBiz "trunk". Others can continue to use the contributions to the trunk but are still able to use "improvements" from other repos that have been rejected by the community. There are licensing issues that I would have to deal with as a maintainer of a private repo if I start to include work from non-Apache repos since I can not be quite so sure that the contributions to the private repo have been released to me under an Apache license. I am not advocating a shift to git, just trying to support Jacopo's suggestion of looking at workflow first with a slight addition of extending the discussion to project management philosophy since that seems to be a key motivation underlying the suggestion to move. Ron -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Jacques Le Roux
Tough time ahead Jacques, these were exactly the 4 major subjects
informally discussed in Austin. It also shows that programmers like to change the world of the end-users, however forget to improve themselves the way they work.... Regards, Hans On 21/04/15 21:23, Jacques Le Roux wrote: > Le 21/04/2015 16:00, Pierre Smits a écrit : >> Quoting: >> >> At Apachecon, Apache's engineering and corporate leadership advised >> me that >> we >> could move to using OFBiz to manage our issues instead of JIRA if we so >> desire. >> >> >> If we want to explore that path, I suggest we do that in a separate >> thread. > > Please don't, so we would not only move to Git and/or Maven and/or > Moqui but while doing so we would also compete with Jira? :-o > > Jacques |
|
|
In reply to this post by Pierre Smits
I am not sure that this should come as a surprise or a real difference
in the current state. It is possible for anyone to fork the project. With git it could be easier to contribute back changes from this fork. Of course, the code bases could diverge to a point where sharing updates becomes too complex for both sides. The real issue is whether there is sufficient dissatisfaction with the current workflow and product direction for another community of like-minded committers to build to a size capable of managing a "better" fork. Ron On 21/04/2015 2:21 AM, Pierre Smits 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. > > 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 <[hidden email]> wrote: > >> ----- Original Message ----- >>> From: "Jacques Le Roux" <[hidden email]> >>> 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. >> -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Gil Portenseigne
On 04/21/2015 08:09 AM, Gil portenseigne wrote: > > In every case, contribution will have to be given within Jira to get > into the project. > This is not the case even today. I see changes in the svn log that have no jira issue. |
|
Administrator
|
In reply to this post by Hans Bakker
Le 21/04/2015 17:53, Hans Bakker a écrit :
> It also shows that programmers like to change the world of the end-users, however forget to improve themselves the way they work.... Are you insinuating that I'm fossilised and against changes in order to improve the way I work? If so you are wrong! Jacques PS: I will be totally off for 3 days for personal reasons, so don't expect more posts from me before Sunday evening... Have fun... |
|
|
In reply to this post by Adam Heath-2
Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
Le 21 avril 2015 23:00:26 UTC+02:00, Adam Heath <[hidden email]> a écrit : > >On 04/21/2015 08:09 AM, Gil portenseigne wrote: >> >> In every case, contribution will have to be given within Jira to get >> into the project. >> > >This is not the case even today. I see changes in the svn log that >have >no jira issue. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |