In our previous episode, Alexander Klenin said: > > not cooperating, and just throw raw patches to core, and then trying to > > blackmail core into accepting them by raising noise on the maillists) > > To be honest, I was responsible for at least half the noise in this thread. > Also, what do you mean by "raw" patches?
The diffs of his working repo, with unnecessarily refactoring and formatting removed so that it makes the job on the reviewer easy. > Do you want a "cooking" model similar to the one used in git.git development? > That would be good, but practically impossible to do using svn. > > > The first principle of working in a team is assuming that all code is good, > > unless proven otherwise. > > Don't you violate this principle by assuming Hans-Peter's code is bad? I didn't assume, I looked at it. It's hard not to, since his commit messages roll over the IRC channel. I never expected Hans-Peter to really come up with something in the first try, but I more or less expected it would be a scheme like: 1. A new developer first wilde ambitions plan fails because ideas are too unfocussed, on a too big scale, too idealistic and requiring too much up front commitment. 2. The first effort fails, but parts of it that do work are cleaned up and integrated. The developer keeps working and from time to time, finds some subsystem he is interested in, starts maintaining it and gaining experience. 3. After an year, or two, he offers a patch with a certain rewrite or a feature branch that covers the more realistic part of his original ideas, and it gets incorporated, and he stays maitnaining it. The problem with Hans-Peter is that 1 happened more or less, but the second part didn't because he didn't want to compromise and stick to the FPC core teams rules. Moreover the plans were awfully unfocussed, and tried to delegate quite some of the work and responsibility to core beforehand. (by requiring every step to be merged in before he had anything working, based on just principles. Worse he didn't even make it easy for Core to merge it) IMHO, he should have toned down a bit, and continued working in a branch to achieve something tangible with as minimal possible intrusion. That's how you get things done. Not by letting your self get dragged into all kinds of refactorings because "otherwise I can't carry out my real plans". In short : "Don't blame the tools, work with what you have to do the job". One can hardly expect core to radically change the philosophy of the project for every would-be developer that thinks he has an idea. People keep blaming core in these threads because they are supposed to be against HP's changes. While that may be true, such meanings can change if you show something tangible, preferably if it can be incorporated easily. And that has happened before. Moreover, opinions differe with time. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
