move to git.
Locked
12345678
12345678
 
|
> Strange occurrences stopped happening for me after a couple of months and
> generally stopped once all developers either stopped using git client UIs > that used settings they didn't understand or they started using the command > line… That’s my experience, too, and therefore one of my reasons to not love git so far. I’m a command line guy, but for daily „commit" work i miss the overview an the usability of a UI that I can rely on. But this is a mainly „layer 8“ problem… In my opinion, the main aspect is the decision for a different workflow for contributing and managing this project with its opportunities and drawbacks, as stated widely in this thread. Maybe it’s necessary to think about which processes and workflows maybe the ones that are expected by the current and especially future audience/clients/contributors from a state of the art, living and ongoing open source project. Martin Becker ecomify GmbH > Am 23.04.2015 um 10:28 schrieb Scott Gray <[hidden email]>: > > "I am thoroughly familiar with Git." > "Git always screws things up." > > These two statements are complete contradictions. Outcomes in git only > appear strange while you're still unfamiliar with it. > > I've been using the git-svn bridge to commit to OFBiz for about 4 years and > using a git repo on my current project for the last 18 months or so. > Strange occurrences stopped happening for me after a couple of months and > generally stopped once all developers either stopped using git client UIs > that used settings they didn't understand or they started using the command > line (which is exceedingly simple for basic workflows). > > The value of feature branches and pull requests over patches cannot be > overstated IMO. The ability to easily multi-task on features, review pull > requests, keep a real commit history for contributed features, to > collaborate outside of the main repo puts git miles ahead of svn for > collaborative incremental software development. > > Regards > Scott > > > On 20 April 2015 at 22:19, Adrian Crum <[hidden email]> > wrote: > >> I am thoroughly familiar with Git. I've used it on on three projects, and >> that is why I don't like it. >> >> I have a far easier time merging branches with Subversion. Git always >> screws things up. >> >> I don't need to be convinced of anything. I have my experience and my >> opinion. But still, I'm not opposed to switching to Git. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote: >> >>> One of the most difficult and challenging issue with branches is _merging_ >>> them. Git is a tool that is far more advanced in its feature set in that >>> area. >>> >>> It seems some of the opinions expressed against git are due to >>> unfamiliarity. The only way to be convinced is to try it on an advanced >>> level as i don't think an email thread would be enough for convincing >>> anyone of the merits. >>> >>> My 2 cents >>> >>> Taher Alkhateeb >>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <[hidden email]> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> |
|
|
On Apr 23, 2015, at 11:42 AM, Martin Becker <[hidden email]> wrote:
> Maybe it’s necessary to think about which processes and workflows maybe the ones that are expected by the current and especially future audience/clients/contributors from a state of the art, living and ongoing open source project. Exactly. I think that we are having a thorough discussion on the pros and cons of git vs svn, which is good, but we are not focusing enough, in my opinion, on the existing workflows and if/how they should change with the adoption of a new tool. For example, I guess that some of us are implying that with the new tool (git) will also come a new workflow and specifically the "Fork workflow" that is the one made easy by GitHub and similar: there is one official repo, developer fork it and then submit pull request that the committers of the official (upstream) repo can merge. However this is not the only one and it is important that we clarify this aspect: do all proponent of git also agree on one workflow? Another important aspect of the story is that, for policy/license reasons, while it is completely fine for an ASF project to use git as the primary SCM, there are things that they still cannot do (e.g. I think that merging code from pull requests is not allowed); the current git workflow that is recommended at the ASF is the following: non committers: https://git-wip-us.apache.org/docs/workflow.html committers: https://git-wip-us.apache.org/docs/committer-practices.html Jacopo |
|
|
In reply to this post by Scott Gray-3
On 04/23/2015 03:28 AM, Scott Gray wrote: > "I am thoroughly familiar with Git." > "Git always screws things up." If git always screwed things up, then those other 3 projects wouldn't be using it. ps: I realize this was a quote from Adrian, and not Scott. > These two statements are complete contradictions. Outcomes in git only > appear strange while you're still unfamiliar with it. > > I've been using the git-svn bridge to commit to OFBiz for about 4 years and > using a git repo on my current project for the last 18 months or so. > Strange occurrences stopped happening for me after a couple of months and > generally stopped once all developers either stopped using git client UIs > that used settings they didn't understand or they started using the command > line (which is exceedingly simple for basic workflows). I also had strangeness happen earlier on, when I first started. What I can surmise happened, after all these years, is that I used git in the wrong way, and git did exactly what I told it to do. But then, since I was a noob, I didn't know what I had done was wrong, only that what I was seeing was not what I expected. It's the same kind of thing when you go "rm -rf $HOME". Of course all your files are now gone, but that's not the fault of rm. > The value of feature branches and pull requests over patches cannot be > overstated IMO. The ability to easily multi-task on features, review pull > requests, keep a real commit history for contributed features, to > collaborate outside of the main repo puts git miles ahead of svn for > collaborative incremental software development. Let's not forgot that the complete project history is available offline, that the .svn files are not scattered all over(which makes grepping for stuff difficult, as you have to exclude those files from results), that you can include ancient history from previous project lifespans(I have added svn.ofbiz.org history in one of my git-svn ofbiz clones, so I can see history going back to 2003, well before the switch to apache, and even when Andrew created a new repo with the mostly current component structure). As for that last item I mentioned, if we do switch, I would *love* to include such ancient history. Then, how do you(not you Scott) thing I can commit 15 changes all at once? I do all that work in a single commit. Then I save it. Then, I use git rebase, and split the commit into smaller chunks. Woops, that's a new feature, let's change the order of the commits, moving that one first. Oh, my bad, I have a typo in a commit message, let's change that. Ok, I'm happy now, time to run all tests against every single commit(while I switch jobs and work on something else). Ok, everything passes, git svn dcommit $HASH, flood the mailing list. In the svn workflow, only a single patch can be committed at a time, and you have to manually save local work, to build up the patch history. Git actually allows me to produce more stable code, when I am splitting up single-large-commits. > Regards > Scott > > > On 20 April 2015 at 22:19, Adrian Crum <[hidden email]> > wrote: > >> I am thoroughly familiar with Git. I've used it on on three projects, and >> that is why I don't like it. >> >> I have a far easier time merging branches with Subversion. Git always >> screws things up. >> >> I don't need to be convinced of anything. I have my experience and my >> opinion. But still, I'm not opposed to switching to Git. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote: >> >>> One of the most difficult and challenging issue with branches is _merging_ >>> them. Git is a tool that is far more advanced in its feature set in that >>> area. >>> >>> It seems some of the opinions expressed against git are due to >>> unfamiliarity. The only way to be convinced is to try it on an advanced >>> level as i don't think an email thread would be enough for convincing >>> anyone of the merits. >>> >>> My 2 cents >>> >>> Taher Alkhateeb >>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <[hidden email]> 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 Scott Gray-3
On 04/23/2015 04:22 AM, Scott Gray wrote: > I'm just saying my current project has been using it for 18 months and it's > been a long time now since we've "lost" any changes. This is 15-30 devs > that were all new to git. > > In my experience most issues come from: > - Reverting merge commits and picking the wrong mainline Yeah, I've had issues here too. I generally don't do git reset HEAD^ when it's a merge, instead I do "git branch save-current; git checkout save-current; git branch -F master $HASH; git checkout master". If all went well, then I can delete that save-current branch, and continue on. > - Pushing to the wrong remote branch If caught before anyone else pulls, git push +local-ref:remote-ref can fix. > - Incorrectly handling conflicts This single item was a cause for much head-ache, at least for me. Merge conflicts, and rebase conflicts, are given different markup as well, which doesn't help the situation. Conflicts happen with both git and svn based workflows. If you attempt to commit with svn, and someone else modified the files first, svn says no. So then you pull in the upstream changes, and attempt to fix locally. It's still possible to pick the wrong code. The issue now is that when you commit back to svn, it's not recorded as a merge, there is no special text saying which files had conflict, so you are left to assume the developer meant to change the code. > - Trying to force pushes Also related, is pushing to a remote repo, that is also checked out(aka, has a $working_directory), and the remote branch being pushed to is what is checked out. > The most important thing is to stop when you mess something up and seek > help. Trying to fix things on the remote repo without understanding what > has gone wrong can make a bigger mess. When I had problems earlier on, I got very frustrated. After a bit, I realized I could abuse the garbage-collection nature of git, and create a temporary branch against HEAD, before I changed anything. Git would ensure that the content referenced by that branch would stay around, while I made mistakes. Eventually, I started to make use of reflog directly, and no longer need that temporary branch. > On second thought I'm almost hesitant to say git would be a good idea for > OFBiz because we have so many committers that would have access to the > master branch without an adequate level of git experience. I can imagine > the mess someone might make trying to rewrite history on the remote repo. The linux-kernel does not have all developers world-wide pushing to the single repo that is responsible for producing the tarballs hosted at kernel.org. Only one guy does that, Linus Torvalds. Implicit in a svn->git switch, would be finding someone willing to be that person. Which, is a whole other thread of discussion. > Regardless, I highly recommend git-svn for basic local development > or forking the git mirror if you want to go deeper. I've been saying that for years. |
|
|
In reply to this post by Ean Schuessler
An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: https://github.com/apache/ofbiz/graphs/contributors If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). On a side note, my commit count is relatively low... ie most commits with a larger number of changes. I remember working more than way before using git... perhaps with its explicit approach to saying which files to include it encourages that more (unless you use git commit -a), or perhaps for other reasons my habits have changed. I don't get nearly as fancy as what Adam described recently with his rebase approach, but to his point I find my commits being much cleaner and better organized. -David > On 22 Apr 2015, at 10:31, Ean Schuessler <[hidden email]> wrote: > > That raises another irritating thing about the JIRA SVN workflow vs GIT > pull requests. > > If you look at the contributor graph on GitHub for OFBiz you will see > that it currently has only 3 contributors. Foremost this is because the > project committers have mostly not configured their Apache addresses into > their GitHub accounts. Secondly, however, it is caused by the fact that > all JIRA committed patches will show the name of the person who merged > the patch rather than its original author. > > https://github.com/apache/ofbiz/graphs/contributors > > We can make up stories about why this is desirable but I think any honest > assessment would conclude that it is an inconvenience at best and a hazard > at worst. Eventually if these dots are not connected the origins of some > OFBiz code could become as mysterious as the early CVS commits. With the > GIT pull request workflow we would not only know who wrote the code but > would still know who performed the merge. We could also sign the commits > so that their origin is cryptographically confirmed. > > ----- Original Message ----- >> From: "Gil Portenseigne" <[hidden email]> >> Subject: Re: move to git. > >> Yes, but these are commiters contributions, i mean non-commiters one should go >> thru jira. |
|
|
On 04/23/2015 06:00 PM, David E. Jones wrote: > An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: > > https://github.com/apache/ofbiz/graphs/contributors > > If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). I only did this myself yesterday, after Ean mentioned it. I've actually been on github for a bit now. But, with my @apache.org email attached to my account, it might actually improve my standings. FYI, I believe that large spike that is at the start of my graph(I'm eigood, which is doogie backwards), is when I was committing the generics markup. > On a side note, my commit count is relatively low... ie most commits with a larger number of changes. I remember working more than way before using git... perhaps with its explicit approach to saying which files to include it encourages that more (unless you use git commit -a), or perhaps for other reasons my habits have changed. It's not just that you can selectively pick which files; git add -i allows you to selectively choose chunks. > I don't get nearly as fancy as what Adam described recently with his rebase approach, but to his point I find my commits being much cleaner and better organized. I split up my work into smaller commits(lines-per-commit is smaller), so that it allows others to review it easier. > -David |
|
|
In reply to this post by David E. Jones-2
On 04/23/2015 06:00 PM, David E. Jones wrote: > An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: > > https://github.com/apache/ofbiz/graphs/contributors > > If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). Come on, everyone. It's a competition! See if you can beat Jacopo! Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers. But, it's fun to play with gui graph libraries. |
|
|
On Apr 25, 2015, at 1:14 AM, Adam Heath <[hidden email]> wrote: > On 04/23/2015 06:00 PM, David E. Jones wrote: >> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: >> >> https://github.com/apache/ofbiz/graphs/contributors >> >> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). > > Come on, everyone. It's a competition! See if you can beat Jacopo! :-) Frankly speaking... I hates these and similar metrics (e.g. number of posts in the mailing list per author, number of commits per author etc...) because they don't say anything about the quality of the contribution but just on the amount of noise produced; and I am worried that they may induce some to post more and more, commit more and more to stay up in the ranking and this may be detrimental to the quality of the contribution. > > Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers. Right, or several commits then reverted :-) Jacopo |
|
|
According to this presentation regarding the Apache Way
http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay15.pdf (slides 30-31) all contributions are considered equal. That means the big, the small, those of minor and major importance. Nevertheless, collaborating early and often will ensure that both noise and reverts are minimised. It can't be avoided that, with all contributors being volunteers with limited time available , a change is committed (accepted by lazy consensus) whereby over a period of time increase in insights will lead to reverts of old code and to replacement by better code. Creating the JIRA issue(s) early - not just after the commit, as a notification for release notes - will help increasing the awareness of all and opens the door to share insights before the commit and not after. Give the issue its obligatory waiting period (72 hrs) before the commit and due process is ensured. 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 Sat, Apr 25, 2015 at 9:52 AM, Jacopo Cappellato < [hidden email]> wrote: > > On Apr 25, 2015, at 1:14 AM, Adam Heath <[hidden email]> wrote: > > > On 04/23/2015 06:00 PM, David E. Jones wrote: > >> An FYI for all committers: create an account on GitHub (if you don't > already have one) and add your @apache.org email address to it, and > within a few hours you'll show up in the contributor graphs. I tried this > and am now showing up there: > >> > >> https://github.com/apache/ofbiz/graphs/contributors > >> > >> If nothing else it's entertaining, I had no idea that I had this volume > of commits since OFBiz joined the ASF (750k lines added, 135k lines > removed; note that changes to lines show up in both counts). > > > > Come on, everyone. It's a competition! See if you can beat Jacopo! > > :-) > Frankly speaking... I hates these and similar metrics (e.g. number of > posts in the mailing list per author, number of commits per author etc...) > because they don't say anything about the quality of the contribution but > just on the amount of noise produced; and I am worried that they may induce > some to post more and more, commit more and more to stay up in the ranking > and this may be detrimental to the quality of the contribution. > > > > > Useless metrics are fun sometimes. Number of commits, number of lines > added/removed, don't really mean anything. I've seen stupid code that had > the same 30 lines cut and pasted 20 times, instead of making a helper > method, and of course a single line per commit can also inflate numbers. > > Right, or several commits then reverted :-) > > Jacopo |
|
For anyone who is interested and didn't read this before regarding git and svn comparisons:
https://git.wiki.kernel.org/index.php/GitSvnComparsion ----- Original Message ----- From: "Pierre Smits" <[hidden email]> To: [hidden email] Sent: Saturday, 25 April, 2015 11:23:26 AM Subject: Re: move to git. According to this presentation regarding the Apache Way http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay15.pdf (slides 30-31) all contributions are considered equal. That means the big, the small, those of minor and major importance. Nevertheless, collaborating early and often will ensure that both noise and reverts are minimised. It can't be avoided that, with all contributors being volunteers with limited time available , a change is committed (accepted by lazy consensus) whereby over a period of time increase in insights will lead to reverts of old code and to replacement by better code. Creating the JIRA issue(s) early - not just after the commit, as a notification for release notes - will help increasing the awareness of all and opens the door to share insights before the commit and not after. Give the issue its obligatory waiting period (72 hrs) before the commit and due process is ensured. 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 Sat, Apr 25, 2015 at 9:52 AM, Jacopo Cappellato < [hidden email]> wrote: > > On Apr 25, 2015, at 1:14 AM, Adam Heath <[hidden email]> wrote: > > > On 04/23/2015 06:00 PM, David E. Jones wrote: > >> An FYI for all committers: create an account on GitHub (if you don't > already have one) and add your @apache.org email address to it, and > within a few hours you'll show up in the contributor graphs. I tried this > and am now showing up there: > >> > >> https://github.com/apache/ofbiz/graphs/contributors > >> > >> If nothing else it's entertaining, I had no idea that I had this volume > of commits since OFBiz joined the ASF (750k lines added, 135k lines > removed; note that changes to lines show up in both counts). > > > > Come on, everyone. It's a competition! See if you can beat Jacopo! > > :-) > Frankly speaking... I hates these and similar metrics (e.g. number of > posts in the mailing list per author, number of commits per author etc...) > because they don't say anything about the quality of the contribution but > just on the amount of noise produced; and I am worried that they may induce > some to post more and more, commit more and more to stay up in the ranking > and this may be detrimental to the quality of the contribution. > > > > > Useless metrics are fun sometimes. Number of commits, number of lines > added/removed, don't really mean anything. I've seen stupid code that had > the same 30 lines cut and pasted 20 times, instead of making a helper > method, and of course a single line per commit can also inflate numbers. > > Right, or several commits then reverted :-) > > Jacopo |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Thanks Jacopo, from this point I was ready to jump, it was MIT!
I guess someone else already told me, just that I'm have not read it in my 1095 initial emails backlog yet :/ Jacques Le 23/04/2015 01:13, Jacopo Cappellato a écrit : > On Apr 22, 2015, at 11:41 PM, Adam Heath <[hidden email]> wrote: > >> When this happened, we had to relicense the entire project from GPL to Apache 2.0. > Grrrrr.... It was not GPL! :-) > > Jacopo > |
|
Administrator
|
In reply to this post by David E. Jones-2
Le 23/04/2015 01:54, David E. Jones a écrit :
>> On 22 Apr 2015, at 16:49, Adam Heath <[hidden email]> wrote: >> >> >> On 04/22/2015 06:13 PM, Jacopo Cappellato wrote: >>> On Apr 22, 2015, at 11:41 PM, Adam Heath <[hidden email]> wrote: >>> >>>> When this happened, we had to relicense the entire project from GPL to Apache 2.0. >>> Grrrrr.... It was not GPL! :-) >> It was something tho; I may be wrong on that, I didn't actually look it up. I do recall that switching was quite the ordeal. > It was MIT, but that wasn't the real issue with all the CLAs... the ASF requires them but they are not generally required for other users of the Apache 2 license. I was expecting you to say it, thanks David! Jacques > > This was a pain... took months of effort. Even under the ASF we don't know who all code has come from, there is no way to get a list from SVN or any other tool... not even from Jira (though that's closer, but we only have associations between those who opened issues or attached a patch or those sorts of activities, doesn't always match exactly which patch gets committed, etc... AND not all commits get linked back to the Jira issues... oh and mentioning a name in a commit, pretty useless from a reporting perspective... parsing difficulties, data cleanliness/consistency issues... nightmare). > > -David > > > |
|
Administrator
|
In reply to this post by Ean Schuessler
Le 22/04/2015 19:31, Ean Schuessler a écrit :
> That raises another irritating thing about the JIRA SVN workflow vs GIT > pull requests. > > If you look at the contributor graph on GitHub for OFBiz you will see > that it currently has only 3 contributors. Foremost this is because the > project committers have mostly not configured their Apache addresses into > their GitHub accounts. Thanks Ean for letting us know, I was unaware this was needed. I just added mine, but I'm still not in the contributors list, I guess it takes some time, or is another step, like joigning something, needed? Something I'd like to add here. Github is using the successful Freemium business model http://en.wikipedia.org/wiki/Freemium. I doubt there will ever be issues with that, but you never know, see what happened to Apache-Extra ... I know I can trust the ASF, even if, like everything else, it could disappear, that's even less likely than Github in foreseeable future. We live in a disruptive world... Jacques > Secondly, however, it is caused by the fact that > all JIRA committed patches will show the name of the person who merged > the patch rather than its original author. > > https://github.com/apache/ofbiz/graphs/contributors > > We can make up stories about why this is desirable but I think any honest > assessment would conclude that it is an inconvenience at best and a hazard > at worst. Eventually if these dots are not connected the origins of some > OFBiz code could become as mysterious as the early CVS commits. With the > GIT pull request workflow we would not only know who wrote the code but > would still know who performed the merge. We could also sign the commits > so that their origin is cryptographically confirmed. > > ----- Original Message ----- >> From: "Gil Portenseigne" <[hidden email]> >> Subject: Re: move to git. >> Yes, but these are commiters contributions, i mean non-commiters one should go >> thru jira. |
|
|
On Apr 27, 2015, at 3:16 PM, Jacques Le Roux <[hidden email]> wrote:
> Thanks Ean for letting us know, I was unaware this was needed. I just added mine, but I'm still not in the contributors list, I guess it takes some time, or is another step, like joigning something, needed? Hi Jacques, just wait, it could take some hours. Jacopo |
|
Administrator
|
In reply to this post by Adam Heath-2
Since Svn 1.7 (or 1.6?) the .svn files are no longer scattered all over but in a .svn folder at root of the WC
Jacques Le 23/04/2015 17:50, Adam Heath a écrit : > Let's not forgot that the complete project history is available offline, that the .svn files are not scattered all over |
|
Administrator
|
In reply to this post by Adam Heath-2
Le 23/04/2015 17:50, Adam Heath a écrit :
> As for that last item I mentioned, if we do switch, I would *love* to include such ancient history. That would be a plus indeed... Jacques |
|
Administrator
|
In reply to this post by Adam Heath-2
Le 23/04/2015 17:50, Adam Heath a écrit :
> Ok, everything passes, git svn dcommit $HASH, flood the mailing list. "flood the mailing list", you said it :p Jacques |
|
Administrator
|
In reply to this post by Adam Heath-2
Le 25/04/2015 01:14, Adam Heath a écrit :
> > On 04/23/2015 06:00 PM, David E. Jones wrote: >> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a >> few hours you'll show up in the contributor graphs. I tried this and am now showing up there: >> >> https://github.com/apache/ofbiz/graphs/contributors >> >> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines >> removed; note that changes to lines show up in both counts). > > Come on, everyone. It's a competition! See if you can beat Jacopo! No chances, guys, you are far behind me :D > > Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had > the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers. Yes, hence my comments about quality and quantity, big data and our world ;) > But, it's fun to play with gui graph libraries. > > What are we w/o fun? I dare to ask the question ;) Jacques PS: robots will do better... |
|
Administrator
|
In reply to this post by Pierre Smits
Le 25/04/2015 10:23, Pierre Smits a écrit :
> Creating the JIRA issue(s) early - not just after the commit, as a > notification for release notes - will help increasing the awareness of all > and opens the door to share insights before the commit and not after. Give > the issue its obligatory waiting period (72 hrs) before the commit and due > process is ensured. +1, I can't emphasize that more Jacques |
|
|
In reply to this post by Jacques Le Roux
On 04/28/2015 03:39 AM, Jacques Le Roux wrote: > Le 25/04/2015 01:14, Adam Heath a écrit : >> >> On 04/23/2015 06:00 PM, David E. Jones wrote: >>> An FYI for all committers: create an account on GitHub (if you don't >>> already have one) and add your @apache.org email address to it, and >>> within a few hours you'll show up in the contributor graphs. I tried >>> this and am now showing up there: >>> >>> https://github.com/apache/ofbiz/graphs/contributors >>> >>> If nothing else it's entertaining, I had no idea that I had this >>> volume of commits since OFBiz joined the ASF (750k lines added, 135k >>> lines removed; note that changes to lines show up in both counts). >> >> Come on, everyone. It's a competition! See if you can beat Jacopo! > > No chances, guys, you are far behind me :D > I was waiting for you to do that; I already new you were way out in front. I saw it last night. You're a machine(I mean that in the nicest way). >> >> Useless metrics are fun sometimes. Number of commits, number of >> lines added/removed, don't really mean anything. I've seen stupid >> code that had the same 30 lines cut and pasted 20 times, instead of >> making a helper method, and of course a single line per commit can >> also inflate numbers. > > Yes, hence my comments about quality and quantity, big data and our > world ;) > >> But, it's fun to play with gui graph libraries. >> >> > > What are we w/o fun? I dare to ask the question ;) > > Jacques > PS: robots will do better... Something about the 3 laws? |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |