Re: [fpc-other] Fork
Am 24.10.2010 20:20, schrieb Vincent Snijders: > 2010/10/24 Graeme Geldenhuys : >> On 24 October 2010 19:50, Florian Klämpfl wrote: >>> >>> Everybody gets the replys he deserves :) >> >> That's correct. :) >> > > At least you agree on some thing :-) I wondered too, I expected complaints about missing irony tags, they are sooo easy to type with the right editor :) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
2010/10/24 Graeme Geldenhuys : > On 24 October 2010 19:50, Florian Klämpfl wrote: >> >> Everybody gets the replys he deserves :) > > That's correct. :) > At least you agree on some thing :-) Vincent ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:50, Florian Klämpfl wrote: > > Everybody gets the replys he deserves :) That's correct. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Am 24.10.2010 19:48, schrieb Graeme Geldenhuys: > On 24 October 2010 19:43, Florian Klämpfl wrote: >> >> Why shows git log only a one liners? I though using git fixes this? > > God, now you're being stupid too. 'git log' if you are using the FPC > git mirror, or 'svn log' if you are using FPC's subversion repository > directly. Everybody gets the replys he deserves :) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:43, Florian Klämpfl wrote: > > Why shows git log only a one liners? I though using git fixes this? God, now you're being stupid too. 'git log' if you are using the FPC git mirror, or 'svn log' if you are using FPC's subversion repository directly. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:11, Marco van de Voort wrote: > > I don't understand what providing quick and dirty patches that How do you get to 'quick and dirty'? Not every small patch is a hack or quick or dirty. The same applies for bigger patches. If the author of the patch simply explains in the commit/patch message (git automatically includes those when you email a patch, subversion doesn't) what the patch does, and the reason for the patch, applying that patch should be easier for the person reviewing that patch. They have more detail regarding the patch and what it should do - no guessing required. But the FPC & Lazarus team set such bad examples (just review the repository history and lengths of each commit message, new contributors just follow suite. Sergei Gorelkin seems to be the exception in the FPC team - he is about the only one that seems to give (above agv) multi-line commit messages, explaining in more detail what that commit does. Jonas Maebe being second after Sergei. Learn from those two! -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Am 24.10.2010 19:37, schrieb Graeme Geldenhuys: > Just to 'svn log' or 'git log' and actually look at the history of the > FPC project and the commit messages of each commit. 99% are one > liners. Why shows git log only a one liners? I though using git fixes this? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:09, Florian Klämpfl wrote: > > Oh yes, the vcs is to blame for poor commit comment. Or maybe actually manager YOUR project better, by telling all the read/write users of your project to give better commit messages. Nobody can describe a patch very well, and the reason for the patch in a single line commit message. Just to 'svn log' or 'git log' and actually look at the history of the FPC project and the commit messages of each commit. 99% are one liners. So with such bad practices of yourself and of your team members, you are setting a terrible example. That clearly rubs off on the new contributors - they just follow the example that was set before them. Your are to blame, because you don't manage your project well, or set down some basic (logical) rules for all your team members. Having descend commit messages for a patch that explains what the patch does, and why the patch is needed, will making it so much easier for the person reviewing that patch. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
2010/10/23 Adem : > work, use git to ingrate that fix/feature after every update. > This way, you will have micro-forked FPC (or Lazarus or whatever) but it is This works very well indeed. I have +- 15 such feature branches for Lazarus IDE alone, and it takes all of 1 minute to rebase and merge them into my own work branch - after a update. > Now, if only Graeme wrote up a comprehensive (and comprehensible) howto for > doing that :) I think I've done this a few times, but here goes again. $ git checkout master $ git pull github master The 'master' branch is the branch on github that tracks the SubVersion trunk branch. $ git checkout feature1 $ git rebase master $ git checkout feature2 $ git rebase master 'feature1' and 'feature2' are branches that implement the features I need, and that are not included in Lazarus or FPC svn repositories. The rebase command resets that branch to be identical to 'master', then replays the commits on top of that. This makes the repository history linear, and looks as if I implemented those features on top of the latest commit in 'master'. $ git checkout master $ git checkout -b work Start from the 'master' branch, then create a 'work' branch off of 'master'. I'll use the 'work' branch to apply/merge all my features I want. This will be the branch I use on a day to day usage. $ git merge feature1 feature2 This now merges the 'feature1' and 'feature2' branches with the current 'work' branch. Now simply recompile FPC or Lazarus using this 'work' branch. It will then contain the local features you want, without having to bother the FPC or Lazarus team members. When it's time to sync with subversion, by pulling new updates from github, simple redo the process above. You can even place all these commands in a script or batch file to speed things up even more. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Graeme Geldenhuys said: > > Graeme's last mail where he explains he just wants to drop quick and dirty > > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, > > explains the fundamental misconception better than I could do here. > > And here I thought that is what a detailed commit log is for. Correct > me if I'm wrong, but it seems the norm of SubVersion users is to give > one liner commit comments. That is just wrong. The normal in Git > repositories, well at least git.git repo and our company repos, is to > give a much more detailed commit message. Makes applying patches a > breeze, as well as when you have no review a old commit. I don't understand what providing quick and dirty patches that are not cleansed in the bug tracker has to do with a VCS. Either SVN, GIT or etching sources into metal plates. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Am 24.10.2010 19:03, schrieb Graeme Geldenhuys: > On 22 October 2010 20:20, Marco van de Voort wrote: >> >> Graeme's last mail where he explains he just wants to drop quick and dirty >> patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, >> explains the fundamental misconception better than I could do here. > > And here I thought that is what a detailed commit log is for. Correct > me if I'm wrong, but it seems the norm of SubVersion users is to give > one liner commit comments. That is just wrong. The normal in Git > repositories, well at least git.git repo and our company repos, is to > give a much more detailed commit message. Makes applying patches a > breeze, as well as when you have no review a old commit. Oh yes, the vcs is to blame for poor commit comment. Maybe we should create a list fpc-bullshit for you? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 22 October 2010 20:20, Marco van de Voort wrote: > > Graeme's last mail where he explains he just wants to drop quick and dirty > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, > explains the fundamental misconception better than I could do here. And here I thought that is what a detailed commit log is for. Correct me if I'm wrong, but it seems the norm of SubVersion users is to give one liner commit comments. That is just wrong. The normal in Git repositories, well at least git.git repo and our company repos, is to give a much more detailed commit message. Makes applying patches a breeze, as well as when you have no review a old commit. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 2010-10-24 13:15, Marco van de Voort wrote: In our previous episode, Adem said: But, I must say I am disappointed at the lack of management skills. You should ask yourself how management skills work in a community where nobody can force work on sb else. It takes an infinite amount of patience. Yes. Forever, since it won't happen. Specially if the workpressure is increased several magnitudes because people don't bother to put in some minimal effort to present their work. That doesn't seem to help much either --as, then, it can be perceived as dumping loads of code. To conserve some of that patience for the real important things, it's probably best for a manager/leader not to enter into nit-picking discussions. I don't see why nto. It was just a suggestion. Just like why parent shouldn't involve themselves in each and every row/argument/discussion kids are having among them; or why a manager should not prematurely intervene in debates between his/her team. Obvioulsy, these are not hard and fast rules, but there's some wisdom in them --or, that's what I have come to think. It is also a major time (and nerve) saver. At times like these, I read 'Linus on kernel management style' [ http://lwn.net/Articles/105375/ ]. I don't care what Linus says. (either the Snoopy or the penguin one). But I'm pretty, pretty sure, that Linus will throw back a bad patch in your face. Sure he will. But, rarely have I seen him --or his lituenants-- pruning every single thread. Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here. Personally, I find it more useful to focus on the solution Graeme found for himself and not on the complaints which must have grown out of frustrations. I don't know what this means. Please answer to the actual quote. See his post 22 Oct 2010 @ 13:38 (about 12 posts above this) -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Adem said: > >> > >> But, I must say I am disappointed at the lack of management skills. > > You should ask yourself how management skills work in a community where > > nobody can force work on sb else. > > > It takes an infinite amount of patience. Yes. Forever, since it won't happen. Specially if the workpressure is increased several magnitudes because people don't bother to put in some minimal effort to present their work. > To conserve some of that patience for the real important things, it's > probably best for a manager/leader not to enter into nit-picking > discussions. I don't see why nto. > At times like these, I read 'Linus on kernel management style' [ > http://lwn.net/Articles/105375/ ]. I don't care what Linus says. (either the Snoopy or the penguin one). But I'm pretty, pretty sure, that Linus will throw back a bad patch in your face. > > Graeme's last mail where he explains he just wants to drop quick and dirty > > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, > > explains the fundamental misconception better than I could do here. > Personally, I find it more useful to focus on the solution Graeme found > for himself and not on the complaints which must have grown out of > frustrations. I don't know what this means. Please answer to the actual quote. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
