Gary, I'd say never, most of the core prefer not to :)
On Thu, Nov 29, 2012 at 8:42 PM, Gary Weaver <garyswea...@gmail.com> wrote: > And, just for record, I don't like Cucumber ;) >> > > I didn't like it either, but these guys make it look easy, at least to me > :) : https://github.com/gregbell/active_admin/tree/master/features > > I think it depends on what it is being used for. I'd rather be writing > rspecs though. When is Rails going to give up and just use rspec? :) > > > > On Thu, Nov 29, 2012 at 5:06 PM, Rafael Mendonça França < > rafaelmfra...@gmail.com> wrote: > >> 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. >> > > -- > 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. > -- At. Carlos Antonio -- 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.
