On Jan 7, 2008 1:35 AM, R. Rajesh Jeba Anbiah <[EMAIL PROTECTED]> wrote: > > 1. You're trying to get the acceptance of the community by slamming & > misinterpreting the user. While this cabal nature might help you to be > popular among the cult, this won't help you in real world.
If I am misinterpreting what you are saying, I would love to be corrected. I am willing to accept when I am wrong. > 2. I'm/I wasn't complaining anything. I was just suggesting that open > svn branch and Wiki model would help better Correct me if I'm wrong, but a common theme in your posts is that there needs to be a wiki and there needs to be a way for changes to happen faster. A wiki was an unmitigated disaster in the past, so why would anyone want to go back to that unless they were some kind of masochist. In my experience, asking for the same thing over and over again despite being told it's not going to happen is "complaining". Again, show me that I'm wrong and I'll agree with you. > 3. I'm not a framework critic nor a fan boy. If there is/will be any > better framework, I'll be happy to adopt that. I prefer CakePHP for > some of the projects and plain PHP for some other projects. I don't believe I said that you were some kind of framework critic, so I don't see how that's relevant to this discussion. You complained about how long it takes in your opinion to get 'simple' fixes done. I pointed out what the proper way to go about getting fixes done. > 4. For CakePHP, I still believe that Wiki model would be really > helpful as for now, majority of good information available on CakePHP > are partially through self promotional blogs. A centralized Wiki would > be helpful for the developers/users and for the CakePHP itself. "Self promotional blogs". Like mine, perhaps? It's probably disingenious of me to try and claim that my blog is not self-promoting, but the purpose of the blog isn't to make me look smart. It's to try and share stuff that I've come across and maybe help spark some discussion. > Django like credit in Wiki might help, if anyone wants to be > credited for the contribution. Here's what I think about a CakePHP wiki: USELESS unless someone maintains them and makes sure that whatever being posted is accurate. I believe that there is a project coming out very shortly that combines the best of the documentation with the best of a wiki: the CakePHP cookbook. Again, others will correct me if I'm wrong. > 5. Look at the recent changeset, not all commits are based on tickets. > Not all commits even don't need tickets. I'm not complaining on any of > my tickets I agree that not all commits need tickets, because sometimes those changes are driven by the core team itself. Again, I didn't say that all commits are based on tickets. But if someone outside the core team finds a bug, it needs to be submitted via a ticket. > 6. Open svn branch would again be helpful for the developers. I'm not > saying that allowing open access for all svn branches--but to allow > access only for a single branch. Selective merging is really easy with > diff tools. Again, I fail to see how this helps anything other than a programmer's bruised ego. What you are asking for is a complete change from the current development structure, where programmers who have been judged by their peers are given access to relevant branches. Is it arbitrary? Sure. Is it elitist? Probably? Is it unfair to frustrated programmers who want to see bugs fixed faster? Absolutely. Submit patches with your tickets to increase the chances of a bug actually being fixed. Also, don't forget that the ugly spectre of intellectual property can rear it's head as well. All contributers are asked to sign a CLA that declares you are not violating anyone's intellectual property in the code you've committed to the repository. An open svn branch would not have that restriction, and I wouldn't touch any code coming out of that with a ten foot pole. Again, it's about QUALITY, not SPEED. > The quality of the open branch svn will not just be based on unit > tests and perception of core team, but would also be based on real > life situations/projects--which would be more helpful for the > developers. One person's "real life situation" is another person's "edge case". I totally understand where you are coming from, but what you are advocating is a "kitchen sink" system where everybody throws whatever features they think are critical into the framework. I think it would be far better to have the core tight, with as little functionality as needed to meet the overall goals of the framework and then provide an infrastructure to allow people to add their own things in. As I see it, this ability already exists through the helper / behaviour / component architecture that is in place. Let me ask this question, which I think is probably the most important one: If you were a developer wanting to use CakePHP, what branch would you want to use: 1) 1.1.x stable, which has fallen far behind in features and has no new code being contributed as far as I can tell 2) 1.2.x beta, all sorts of new features and quite stable for production use 3) cakephp-open, which is your proposed open svn branch full of all sorts of unvetted code -- Chris Hartjes Internet Loudmouth Motto for 2008: "Moving from herding elephants to handling snakes..." @TheKeyBoard: http://www.littlehart.net/atthekeyboard --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
