We can't accept a feature without know what are the impacts in the codebase.
This is valid for everyone, either the core members. I can say that I want this feature and accept it, but nothing stops the core members to revert it. And don't expect me to defend your feature, since you should be the interested. Would be more wast of time if we accept it now and, when you come up with the code, we rejected it because it add more complexity in the framework that we want. Also, what is the difference of writing 10 huge emails and get the feature reject? I think is the same. With working code you have more chances. And, as I said in my last email, either if we don't accept, you will have working code that solves your problem. If you don't want to scratch your itch and provide a patch, I'm sorry, but don't expect we to accept. And, just for record, I don't like Cucumber ;) Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Thu, Nov 29, 2012 at 7:27 PM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com > wrote: > Well, then we have a real problem here. I don't start coding anything > before discussing them. I consider it a waste of time (in the case the > feature has been rejected). > > So I don't think how I could ever contribute to Rails. I won't ever write > a patch before getting it accepted first. I've done it once after some > previous discussion and after the issue became totally abandoned with no > feedback I decided that I wouldn't ever do it again. Too much effort to > code to get it rejected or ignored later. > > I don't understand why code is needed to discuss a feature or a new API. > Some people have a hard work trying to get RSpec to read as plain English > but if you try to spec your requested API in plain English, since it is not > code, people won't even consider it. > > Just pretend my feature requests are Cucumber features ;) > > Em 29-11-2012 15:03, Rafael Mendonça França escreveu: > > Rodrigo, sorry but I think you misunderstood. I don't use MySQL, actually > I even don't like it. I prefer to use PostgreSQL. If you take 10 minutes > you can see a lot of pull requests adding features for PostgreSQL in Rails. > > What I said is that I don't think the feature as it was implemented is a > good fit for core. I've been using database constraints but I've always > used SQL to create them. > > Also I don't like to discuss features without seeing the code. I need to > see how the feature was implemented to say if I would accept or not. It > don't need to be a full patch but something to, at least, make explicit > what are the benefits and the drawbacks of adding a feature to the > framework. > > We should always look after the cost of maintainability. Add a new > feature to Rails is as easy as pressing a green button. Discuss it is even > easier. Maintain it is not. I prefer to put into Rails features that I want > to maintain in the future and I believe that are good for the framework. > This is how Rails work since the beginning. > > I'm not saying that I don't believe in your proposed feature, neither > that I don't want constraints in the framework. But, without seeing the > code I can't discuss anything. > > That said, lets see that patch. At least, if it is not accepted, you > can easily create a plugin that you can maintain and don't need to worry if > it will break in the next Rails release. > > Rafael Mendonça França > http://twitter.com/rafaelfranca > https://github.com/rafaelfranca > > > > On Thu, Nov 29, 2012 at 2:19 PM, Rodrigo Rosenfeld Rosas < > rr.ro...@gmail.com> wrote: > >> Em 29-11-2012 09:42, Rodrigo Rosenfeld Rosas escreveu: >> >> Em 29-11-2012 09:21, Gary Weaver escreveu: >> ... >> >> If the Rails community can't convince itself about the importance of >> basic things in ACID databases like transactions, foreign keys and other >> constraints than I think I'm out of luck with regards to deferrable >> constraints... :( (yes, when I talk about transactions I mean the huge >> amount of Rails applications out there running MySql with MyISAM engine, >> that used to be the default one until recently in 5.5 when the InnoDB is >> now the default one). >> >> >> Sorry, but I've just became aware of this video and didn't resist posting >> it here :) I'm hoping Rails core members that still use MySQL could open >> their minds after watching this video: >> >> Why Not MySQL? >> http://www.youtube.com/watch?v=1PoFIohBSM4 >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
