move to git.
Locked
12345
... 8
12345
... 8
 
|
As always, thanks for the feedback ;)
On Mon, 2015-04-20 at 23:07 +0200, Pierre Smits wrote: > Thanks for what, Christian? > > Ah.... It seems you're misunderstanding me as I might have been a bit to > brief. I have commit privileges in other projects. I don't have that > privilege in this project. > > By the way, I have seen your recent git coalescence/aggregation regarding > various issues into one big-sized patch. Affecting multiple components. > This is, I surmise, the result of the way Git is utilised as a change > integration tool from various private development branches before > submitting patches/promoted. Which is a bit harder to achieve in SVN. > > At the moment I am not certain whether to llike or dislike the end result > (the patch in question). > > 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 Mon, Apr 20, 2015 at 10:26 PM, Christian Carlow < > [hidden email]> wrote: > > > Thanks Pierre, > > > > I switched to git because committer privileges don't have to be granted > > before non-committers have access to development freedoms such as branch > > creations for conveniencies such as patch creation. Such a system seems > > to promote more open source collaboration. > > > > On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote: > > > I have currently multiple local development branches in our SVN and they > > > are SVN based and they are all of the same bases at > > > https://svn.apache.org/repos/asf/ofbiz. > > > > > > And yes, I have commit privileges. > > > > > > 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 Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow < > > > [hidden email]> wrote: > > > > > > > SVN allows for a local branching? Believing git only allows this was > > > > the main reason for my recent switch. Are commit privileges not > > > > necessary for the creation of such an svn branch as is the case with > > > > git? > > > > > > > > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote: > > > > > If we only want GIT for multiple local development branches, then we > > are > > > > > doing for the wrong reasons. SVN doesn't hinder you in doing that > > today. > > > > > > > > > > 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 Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux < > > > > > [hidden email]> wrote: > > > > > > > > > > > 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. 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! > > > > > > > > > > > > Jacques > > > > > > > > > > > > > > > > > > Le 20/04/2015 09:53, Adrian Crum a écrit : > > > > > > > > > > > >> I don't agree that "all major contributors are using git." > > > > > >> > > > > > >> Personally, I find Git to be an overly complicated solution to a > > > > simple > > > > > >> problem. It frequently does bizarre things that no one > > understands, > > > > and you > > > > > >> are left with things being mysteriously reverted for unknown > > reasons. > > > > > >> > > > > > >> This isn't a -1 vote though. I'm just making it clear that I will > > be > > > > > >> dragged kicking and screaming into using it. > > > > > >> > > > > > >> Adrian Crum > > > > > >> Sandglass Software > > > > > >> www.sandglass-software.com > > > > > >> > > > > > >> On 4/20/2015 5:38 AM, Hans Bakker wrote: > > > > > >> > > > > > >>> As discussed at apachecon in Austin, i propose to switch from > > svn to > > > > git > > > > > >>> for the ofbiz repository. The main reason being that all major > > > > > >>> contributors are using git and contributions are cumbersome, > > further, > > > > > >>> git allows for better branching and merging. > > > > > >>> > > > > > >>> Regards, > > > > > >>> Hans > > > > > >>> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > |
|
|
In reply to this post by Jacques Le Roux
----- 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 Adrian Crum-3
I used to be in the same boat; in the early days, I would blame git for
losing my work. "Damn you frigging piece of software!" However, I also realized that the linux-kernel was using it to do much more complex things than I was, so I toiled on. It took me a long time, but I was finally able to figure out how to make use of git's features. The main thing that keeps you from losing work, is to commit *everything* to git. If you leave *anything* in your $working_tree, not committed, then yes, sometimes things get confused. But once you have everything committed to git, there are certain things that git helps you with, with regard to keeping copies of stuff around. == # git config --global rerere.enabled true # (echo adfadsfasdf; date) > new-file # git branch before-new-file # git add new-file # git commit -m "This is my cool new file, yipee!" # git log # git checkout before-new-file # git branch -f master before-new-file # git checkout master # ls new-file # hmm, where did it go? # git reflog # hmm, seems to show the commit from above # git log trunk # commit is gone # git log trunk@{1} # this shows the commit, and the file == This is just one of the powerful features that git has. I have rerere enabled locally, but don't use it often. I enabled it long ago, because I saw that it keeps copies of all my rebasing and branching, so that I can feel safer about having this safety net. Also, I when back in time, and found an older copy of the previous ofbiz svn tree, and "underlayed" it into the current git-svn checkout, so I have git history going all the way back to 2003. On 04/20/2015 02:53 AM, Adrian Crum wrote: > I don't agree that "all major contributors are using git." > > Personally, I find Git to be an overly complicated solution to a > simple problem. It frequently does bizarre things that no one > understands, and you are left with things being mysteriously reverted > for unknown reasons. > > This isn't a -1 vote though. I'm just making it clear that I will be > dragged kicking and screaming into using it. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 4/20/2015 5:38 AM, Hans Bakker wrote: >> As discussed at apachecon in Austin, i propose to switch from svn to git >> for the ofbiz repository. The main reason being that all major >> contributors are using git and contributions are cumbersome, further, >> git allows for better branching and merging. >> >> Regards, >> Hans |
|
|
On 04/20/2015 07:12 PM, Adam Heath wrote: > I used to be in the same boat; in the early days, I would blame git > for losing my work. "Damn you frigging piece of software!" > > However, I also realized that the linux-kernel was using it to do much > more complex things than I was, so I toiled on. It took me a long > time, but I was finally able to figure out how to make use of git's > features. > > The main thing that keeps you from losing work, is to commit > *everything* to git. If you leave *anything* in your $working_tree, > not committed, then yes, sometimes things get confused. But once you > have everything committed to git, there are certain things that git > helps you with, with regard to keeping copies of stuff around. > > == > # git config --global rerere.enabled true > # (echo adfadsfasdf; date) > new-file > # git branch before-new-file > # git add new-file > # git commit -m "This is my cool new file, yipee!" > # git log > # git checkout before-new-file > # git branch -f master before-new-file > # git checkout master > # ls new-file # hmm, where did it go? > # git reflog # hmm, seems to show the commit from above > # git log trunk # commit is gone > # git log trunk@{1} # this shows the commit, and the file > == > Gah, too many git features. git rerere is a feature to cache rebase resolutions; the feature being discussed here is not the same thing. > This is just one of the powerful features that git has. I have rerere > enabled locally, but don't use it often. I enabled it long ago, > because I saw that it keeps copies of all my rebasing and branching, > so that I can feel safer about having this safety net. > > Also, I when back in time, and found an older copy of the previous > ofbiz svn tree, and "underlayed" it into the current git-svn checkout, > so I have git history going all the way back to 2003. > > On 04/20/2015 02:53 AM, Adrian Crum wrote: >> I don't agree that "all major contributors are using git." >> >> Personally, I find Git to be an overly complicated solution to a >> simple problem. It frequently does bizarre things that no one >> understands, and you are left with things being mysteriously reverted >> for unknown reasons. >> >> This isn't a -1 vote though. I'm just making it clear that I will be >> dragged kicking and screaming into using it. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 4/20/2015 5:38 AM, Hans Bakker wrote: >>> As discussed at apachecon in Austin, i propose to switch from svn to >>> git >>> for the ofbiz repository. The main reason being that all major >>> contributors are using git and contributions are cumbersome, further, >>> git allows for better branching and merging. >>> >>> Regards, >>> Hans > |
|
|
In reply to this post by Jacques Le Roux
On 04/20/2015 04:12 AM, Jacques Le Roux wrote: > 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. 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. > I take exception to this; I believe you are referring to my commit bursts, in times past. Aka, 10-15 commits get added to svn in under a minute. Git allows me to create a new feature, initially as a single large commit(or several large commits). Then, using the rebase feature, I pull out very small changes, that are easy to understand, and digest. I then might commit those as completely separate fixes/feature-additions, which then get reviewed. I then wait a bit, and rebase my big work on top of the new trunk. Eventually, I get the history to such a point that I feel that the series of commits are an easy to understand progression. At that point, I commit the entire set to svn. Note, that I run the entire set of test cases(as they exist at that point) against each and every single commit, before I send them off. Having each commit separate, allows for each change to be looked at in isolation. If they were all combined into one, then it would be much more difficult to review. If the number of commits at once is the problem, then I don't follow. Spreading each commit out over several hours still won't cause anything to get reviewed. |
|
|
In reply to this post by Ean Schuessler
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. > |
|
|
Some have argumented in this and other threads that SVN is dead and Git is
the new king, and that is why the change is warranted. Here are some insights into numbers: http://programmers.stackexchange.com/questions/136079/are-there-any-statistics-that-show-the-popularity-of-git-versus-svn . If you feel that SVN should address the GIT features, I suggest you join [hidden email]. or [hidden email] and collaborate there to get it improved. Yes, SVN is an Apache project called Apache Subversion. 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 8:21 AM, 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. > > 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. >> > > |
Administrator
|
In reply to this post by Ean Schuessler
Le 21/04/2015 02:08, Ean Schuessler a écrit :
> ----- 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. What about https://github.com/apache/ofbiz ? > Some customers may even require > such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques > >> 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 Adam Heath-2
That wasn't what happened to me. Here are the steps I took and the outcome:
1. Git pull to update my local copy. 2. Make changes to 4 files. 3. Stash push. 4. Pull to get latest repo changes. 5. Stash pop. 6. Commit - 4 files changed. 7. Push - dozens of files changed. !!!??? 8. Check commit log - 4 files changed. Why did my push change dozens of files I didn't touch? Basically, several days of other people's work were reverted by my push. My local copy says I changed only 4 files, but a diff of the repo before and after my push shows that many more files were changed. Even the Git gurus couldn't figure that out. Meanwhile, the unintended changes had to be fixed by hand. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 1:12 AM, Adam Heath wrote: > I used to be in the same boat; in the early days, I would blame git for > losing my work. "Damn you frigging piece of software!" > > However, I also realized that the linux-kernel was using it to do much > more complex things than I was, so I toiled on. It took me a long time, > but I was finally able to figure out how to make use of git's features. > > The main thing that keeps you from losing work, is to commit > *everything* to git. If you leave *anything* in your $working_tree, not > committed, then yes, sometimes things get confused. But once you have > everything committed to git, there are certain things that git helps you > with, with regard to keeping copies of stuff around. > > == > # git config --global rerere.enabled true > # (echo adfadsfasdf; date) > new-file > # git branch before-new-file > # git add new-file > # git commit -m "This is my cool new file, yipee!" > # git log > # git checkout before-new-file > # git branch -f master before-new-file > # git checkout master > # ls new-file # hmm, where did it go? > # git reflog # hmm, seems to show the commit from above > # git log trunk # commit is gone > # git log trunk@{1} # this shows the commit, and the file > == > > This is just one of the powerful features that git has. I have rerere > enabled locally, but don't use it often. I enabled it long ago, because > I saw that it keeps copies of all my rebasing and branching, so that I > can feel safer about having this safety net. > > Also, I when back in time, and found an older copy of the previous ofbiz > svn tree, and "underlayed" it into the current git-svn checkout, so I > have git history going all the way back to 2003. > > On 04/20/2015 02:53 AM, Adrian Crum wrote: >> I don't agree that "all major contributors are using git." >> >> Personally, I find Git to be an overly complicated solution to a >> simple problem. It frequently does bizarre things that no one >> understands, and you are left with things being mysteriously reverted >> for unknown reasons. >> >> This isn't a -1 vote though. I'm just making it clear that I will be >> dragged kicking and screaming into using it. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 4/20/2015 5:38 AM, Hans Bakker wrote: >>> As discussed at apachecon in Austin, i propose to switch from svn to git >>> for the ofbiz repository. The main reason being that all major >>> contributors are using git and contributions are cumbersome, further, >>> git allows for better branching and merging. >>> >>> Regards, >>> Hans > |
|
In reply to this post by Jacques Le Roux
Hi Jacques and all,
I think that sharing more than anything is a reason why git has an advantage. The distributed system means that every developer is a repository and therefore you can have endless chains of code propagation up to a committer. Just imagine a scenario like the following - A team is composed of people working on a major task - Two of the members (A and B) have their own sub-teams - There is exchange of code between the sub-teams, the major team and the project committer. Furthermore, the sub-teams need to pull updated data from the main repository of the project. So you have two integrators at the sub-team level and one integrator at the top team level plus a project committer. Sometimes, I want to pull code from the sub-team. Sometimes I want to pull code from the _other_ team. Then maybe I want to _merge_ work from both teams and run all tests. Then I want to clean the commit log with "git rebase" to cleanup the history into major commits to submit to the project committer. Now the project owner does not know / trust me but he knows / trusts you. And you in turn trust me so you can accept my commits. I cannot imagine how to implement the above without a distributed source code management system. Furthermore, it's important to note that ofbiz is not a closed proprietary project with a sacred repository hidden in the vault of some company. You _need_ contributions from others and you need to make it very easy and accessible. You need to have the ability for people to form teams and sub-teams to support you and your project by collaborating with each other without needing a committer. This is one of the main reasons for the massive success of the Linux Kernel where each of Linus Torvald's lieutenants is a committer for a sub-system with his/her own people they trust and work closely with. Some of this stuff is briefly shown in here http://www.git-scm.com/about/distributed I hope what I wrote is resonating with you and you're willing to give this idea a chance Taher Alkhateeb On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux < [hidden email]> wrote: > Le 21/04/2015 02:08, Ean Schuessler a écrit : > >> ----- 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. >> > > What about https://github.com/apache/ofbiz ? > > Some customers may even require >> such a situation for security or legal reasons. >> > > People can do what they want with OFBiz code on their side, sharing with > the community is something else (and often harder) > > Jacques > > >> 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. >> >> |
|
Administrator
|
In reply to this post by Adam Heath-2
Le 21/04/2015 02:26, Adam Heath a écrit : > > On 04/20/2015 04:12 AM, Jacques Le Roux wrote: >> 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. 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. >> > > I take exception to this; I believe you are referring to my commit bursts, in times past. Aka, 10-15 commits get added to svn in under a minute. > > Git allows me to create a new feature, initially as a single large commit(or several large commits). Then, using the rebase feature, I pull out > very small changes, that are easy to understand, and digest. I then might commit those as completely separate fixes/feature-additions, which then > get reviewed. I then wait a bit, and rebase my big work on top of the new trunk. > > Eventually, I get the history to such a point that I feel that the series of commits are an easy to understand progression. At that point, I commit > the entire set to svn. > > Note, that I run the entire set of test cases(as they exist at that point) against each and every single commit, before I send them off. > > Having each commit separate, allows for each change to be looked at in isolation. If they were all combined into one, then it would be much more > difficult to review. > > If the number of commits at once is the problem, then I don't follow. Spreading each commit out over several hours still won't cause anything to > get reviewed. > > before being committed Jacques |
|
Administrator
|
In reply to this post by Adam Heath-2
Le 21/04/2015 02:14, Adam Heath a écrit : > > On 04/20/2015 07:12 PM, Adam Heath wrote: >> I used to be in the same boat; in the early days, I would blame git for losing my work. "Damn you frigging piece of software!" >> >> However, I also realized that the linux-kernel was using it to do much more complex things than I was, so I toiled on. It took me a long time, but >> I was finally able to figure out how to make use of git's features. Dare I point the linux-kernel and OFBiz are somehow different? We have 18 active committers, I guess linux-kernel has (much?) more... I read it's even organised in a hierarchy http://stackoverflow.com/questions/4166530/how-to-manage-a-hierarchy-of-committers-like-linux-kernel-dev I believe Git was created because Linus needed to delegate but still have the control... Why do we need to switch form Svn to Git is my question? I prefer to focus on other fields in OFBiz like "OFBiz : open or in progress" https://issues.apache.org/jira/issues/?filter=12311912# "Patch Available in OFBiz" https://issues.apache.org/jira/issues/?filter=12314132 >> >> The main thing that keeps you from losing work, is to commit *everything* to git. If you leave *anything* in your $working_tree, not committed, >> then yes, sometimes things get confused. But once you have everything committed to git, there are certain things that git helps you with, with >> regard to keeping copies of stuff around. >> >> == >> # git config --global rerere.enabled true >> # (echo adfadsfasdf; date) > new-file >> # git branch before-new-file >> # git add new-file >> # git commit -m "This is my cool new file, yipee!" >> # git log >> # git checkout before-new-file >> # git branch -f master before-new-file >> # git checkout master >> # ls new-file # hmm, where did it go? >> # git reflog # hmm, seems to show the commit from above >> # git log trunk # commit is gone >> # git log trunk@{1} # this shows the commit, and the file >> == >> > > Gah, too many git features. git rerere is a feature to cache rebase resolutions; the feature being discussed here is not the same thing. > Well, so I need to dive deep in Git, but what for? Do I really miss that as an OFBiz committer? I hope you see my preferences... Jacques >> This is just one of the powerful features that git has. I have rerere enabled locally, but don't use it often. I enabled it long ago, because I >> saw that it keeps copies of all my rebasing and branching, so that I can feel safer about having this safety net. >> >> Also, I when back in time, and found an older copy of the previous ofbiz svn tree, and "underlayed" it into the current git-svn checkout, so I have >> git history going all the way back to 2003. >> >> On 04/20/2015 02:53 AM, Adrian Crum wrote: >>> I don't agree that "all major contributors are using git." >>> >>> Personally, I find Git to be an overly complicated solution to a simple problem. It frequently does bizarre things that no one understands, and >>> you are left with things being mysteriously reverted for unknown reasons. >>> >>> This isn't a -1 vote though. I'm just making it clear that I will be dragged kicking and screaming into using it. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 4/20/2015 5:38 AM, Hans Bakker wrote: >>>> As discussed at apachecon in Austin, i propose to switch from svn to git >>>> for the ofbiz repository. The main reason being that all major >>>> contributors are using git and contributions are cumbersome, further, >>>> git allows for better branching and merging. >>>> >>>> Regards, >>>> Hans >> > > |
|
Administrator
|
In reply to this post by taher
Le 21/04/2015 10:19, Taher Alkhateeb a écrit : > Hi Jacques and all, > > I think that sharing more than anything is a reason why git has an > advantage. The distributed system means that every developer is a > repository and therefore you can have endless chains of code propagation up > to a committer. Just imagine a scenario like the following > > - A team is composed of people working on a major task > - Two of the members (A and B) have their own sub-teams > - There is exchange of code between the sub-teams, the major team and the > project committer. Furthermore, the sub-teams need to pull updated data > from the main repository of the project. > > So you have two integrators at the sub-team level and one integrator at the > top team level plus a project committer. Sometimes, I want to pull code > from the sub-team. Sometimes I want to pull code from the _other_ team. > Then maybe I want to _merge_ work from both teams and run all tests. Then I > want to clean the commit log with "git rebase" to cleanup the history into > major commits to submit to the project committer. Now the project owner > does not know / trust me but he knows / trusts you. And you in turn trust > me so you can accept my commits. > > I cannot imagine how to implement the above without a distributed source > code management system. Furthermore, it's important to note that ofbiz is > not a closed proprietary project with a sacred repository hidden in the > vault of some company. You _need_ contributions from others and you need to > make it very easy and accessible. You need to have the ability for people > to form teams and sub-teams to support you and your project by > collaborating with each other without needing a committer. This is one of > the main reasons for the massive success of the Linux Kernel where each of > Linus Torvald's lieutenants is a committer for a sub-system with his/her > own people they trust and work closely with. Some of this stuff is briefly > shown in here http://www.git-scm.com/about/distributed > > I hope what I wrote is resonating with you and you're willing to give this > idea a chance OK, you kind of answered to my questions to Adam, I need to re-read carefully... Jacques > > Taher Alkhateeb > > On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux < > [hidden email]> wrote: > >> Le 21/04/2015 02:08, Ean Schuessler a écrit : >> >>> ----- 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. >>> >> What about https://github.com/apache/ofbiz ? >> >> Some customers may even require >>> such a situation for security or legal reasons. >>> >> People can do what they want with OFBiz code on their side, sharing with >> the community is something else (and often harder) >> >> Jacques >> >> >>> 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 taher
Taher,
Nothing in your reply is new or different. People have been doing that for years with Subversion. Git did not invent local repositories. Connecting a local Git repository to the OFBiz Subversion repository is a problem for some, that is why we are having this discussion. So far, two proposals have been made: 1. Switch the OFBiz project to Git. 2. Host a separate Git repo that is a copy of the OFBiz Subversion repo. How those proposals affect OFBiz developers: 1. Subversion users must switch to Git clients and learn Git. 2. Git users can access the project through the Git repo, Subversion users continue using Subversion with the main OFBiz repo. 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. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 9:19 AM, Taher Alkhateeb wrote: > Hi Jacques and all, > > I think that sharing more than anything is a reason why git has an > advantage. The distributed system means that every developer is a > repository and therefore you can have endless chains of code propagation up > to a committer. Just imagine a scenario like the following > > - A team is composed of people working on a major task > - Two of the members (A and B) have their own sub-teams > - There is exchange of code between the sub-teams, the major team and the > project committer. Furthermore, the sub-teams need to pull updated data > from the main repository of the project. > > So you have two integrators at the sub-team level and one integrator at the > top team level plus a project committer. Sometimes, I want to pull code > from the sub-team. Sometimes I want to pull code from the _other_ team. > Then maybe I want to _merge_ work from both teams and run all tests. Then I > want to clean the commit log with "git rebase" to cleanup the history into > major commits to submit to the project committer. Now the project owner > does not know / trust me but he knows / trusts you. And you in turn trust > me so you can accept my commits. > > I cannot imagine how to implement the above without a distributed source > code management system. Furthermore, it's important to note that ofbiz is > not a closed proprietary project with a sacred repository hidden in the > vault of some company. You _need_ contributions from others and you need to > make it very easy and accessible. You need to have the ability for people > to form teams and sub-teams to support you and your project by > collaborating with each other without needing a committer. This is one of > the main reasons for the massive success of the Linux Kernel where each of > Linus Torvald's lieutenants is a committer for a sub-system with his/her > own people they trust and work closely with. Some of this stuff is briefly > shown in here http://www.git-scm.com/about/distributed > > I hope what I wrote is resonating with you and you're willing to give this > idea a chance > > Taher Alkhateeb > > On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux < > [hidden email]> wrote: > >> Le 21/04/2015 02:08, Ean Schuessler a écrit : >> >>> ----- 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. >>> >> >> What about https://github.com/apache/ofbiz ? >> >> Some customers may even require >>> such a situation for security or legal reasons. >>> >> >> People can do what they want with OFBiz code on their side, sharing with >> the community is something else (and often harder) >> >> Jacques >> >> >>> 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. >>> >>> > |
|
Administrator
|
Le 21/04/2015 11:08, Adrian Crum a écrit : > Taher, > > Nothing in your reply is new or different. People have been doing that for years with Subversion. Git did not invent local repositories. > > Connecting a local Git repository to the OFBiz Subversion repository is a problem for some, that is why we are having this discussion. > > So far, two proposals have been made: > > 1. Switch the OFBiz project to Git. > 2. Host a separate Git repo that is a copy of the OFBiz Subversion repo. > > How those proposals affect OFBiz developers: > > 1. Subversion users must switch to Git clients and learn Git. > 2. Git users can access the project through the Git repo, Subversion users continue using Subversion with the main OFBiz repo. > > 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. I have been using a Git repo for a custom project. I simply put the OFBiz .svn in the Git working copy and repo et voilà. I had the best of both world, I could easily backport my contributions in OFBiz. It's also very convenient for other reasons. I must admit it's not available for non committers who have to create patches, nothing new.. Jacques > > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 4/21/2015 9:19 AM, Taher Alkhateeb wrote: >> Hi Jacques and all, >> >> I think that sharing more than anything is a reason why git has an >> advantage. The distributed system means that every developer is a >> repository and therefore you can have endless chains of code propagation up >> to a committer. Just imagine a scenario like the following >> >> - A team is composed of people working on a major task >> - Two of the members (A and B) have their own sub-teams >> - There is exchange of code between the sub-teams, the major team and the >> project committer. Furthermore, the sub-teams need to pull updated data >> from the main repository of the project. >> >> So you have two integrators at the sub-team level and one integrator at the >> top team level plus a project committer. Sometimes, I want to pull code >> from the sub-team. Sometimes I want to pull code from the _other_ team. >> Then maybe I want to _merge_ work from both teams and run all tests. Then I >> want to clean the commit log with "git rebase" to cleanup the history into >> major commits to submit to the project committer. Now the project owner >> does not know / trust me but he knows / trusts you. And you in turn trust >> me so you can accept my commits. >> >> I cannot imagine how to implement the above without a distributed source >> code management system. Furthermore, it's important to note that ofbiz is >> not a closed proprietary project with a sacred repository hidden in the >> vault of some company. You _need_ contributions from others and you need to >> make it very easy and accessible. You need to have the ability for people >> to form teams and sub-teams to support you and your project by >> collaborating with each other without needing a committer. This is one of >> the main reasons for the massive success of the Linux Kernel where each of >> Linus Torvald's lieutenants is a committer for a sub-system with his/her >> own people they trust and work closely with. Some of this stuff is briefly >> shown in here http://www.git-scm.com/about/distributed >> >> I hope what I wrote is resonating with you and you're willing to give this >> idea a chance >> >> Taher Alkhateeb >> >> On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Le 21/04/2015 02:08, Ean Schuessler a écrit : >>> >>>> ----- 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. >>>> >>> >>> What about https://github.com/apache/ofbiz ? >>> >>> Some customers may even require >>>> such a situation for security or legal reasons. >>>> >>> >>> People can do what they want with OFBiz code on their side, sharing with >>> the community is something else (and often harder) >>> >>> Jacques >>> >>> >>>> 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
> 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 > 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. >> |
|
Administrator
|
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. >>> > > |
|
|
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 < [hidden email]> 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
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. >>>> >> >> |
|
|
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. >>>>> >>>>> >>> >>> > -- Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |