An example why it is not that fast to start contributing to Rails:
just tried running bundle from master branch:
Bundler could not find compatible versions for gem "multi_json":
In snapshot (Gemfile.lock):
multi_json (1.2.0)
In Gemfile:
rails (>= 0) ruby depends on
multi_json (~> 1.3) ruby
Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
I don't mind spending time contributing to code when I have some free
time if the code won't be just rejected. But assuming that I would be
able to start contributing with code faster than writing "huge" messages
is wrong.
Em 30-11-2012 09:23, Rodrigo Rosenfeld Rosas escreveu:
Em 29-11-2012 20:06, Rafael Mendonça França escreveu:
We can't accept a feature without know what are the impacts in the
codebase.
In the application I maintain I don't need code to understand the
impact of some feature. I don't understand why that would be different
for Rails maintainers.
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.
My perception is that although this list is called rails-core it seems
core members don't actually read it. Otherwise it would be easy to
achieve a consensus about approving this feature or not before
implementing it.
It seems to me that you're suggesting that Rails development is much
more like an anarchy. Listening to Aaron in some podcasts also seems
to indicate that this is the case as well. This is how I'm
understanding development happen on Rails core:
- a core member wants a feature
- he writes the change, commit it and push it
- another core member don't like the change and revert the commit
- some other core member liked the change and revert the commit that
has been reverted
How is that sane? In what point prior discussion became invaluable?
This is not how I manage my teams/softwares and I'm pretty sure this
is not how most projects out there work.
Would be more waste 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.
You should be able to understand the impact in complexity that such a
simple feature like that would have in the code base beforehand. If it
happens that you don't like my change, I'd expect you to show me how
you think such feature should be implemented instead. But it wouldn't
be rejected. At some point the implementation would conform to what
the core-team expect it to look like.
Also, what is the difference of writing 10 huge emails and get the
feature reject?
Getting the feature rejected is not the issue. Spending time on
developing the feature that got rejected is. I don't consider my
e-mails huge (they are not small) but I see that for today's standards
where people got used to Twitter (I can't use it) my messages may seem
huge. But I don't spend much time writing messages as I would spend to
start contributing to any big open-source code. See, last time I
contributed to Rails was several years ago, much has changed since
then and I'd need to read tons of instructions and code before I
started to contribute again. Additionally, AR is inside Rails
repository. That means that I can't just point to AR master in my
Gemfile for instance, but this is a separate issue, let me get back to
the subject.
In the end I just don't mind discussing features, but I do mind
writing code that won't ever see the light of the day just because
people can't discuss them up-front. This is similar to the Refinements
discussion in the Ruby-core list. It started with code, that code has
been merged to trunk even before the discussion started. I'm pretty
sure Charles Nutter was able to tell the performance impacts and had
more insights about that feature just looking at the proposed feature
description without starting coding it. If this discussion had started
before the feature being implemented the first implementation would
probably be much more aligned to the final specs and with less effort.
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.
No, I won't. First, I don't have a problem. I use PG and I have no
plans to support other DB vendor. But it crossed my mind the idea that
maybe some open-source software could benefit from a common API to add
support for deferrable unique constraints because some very common use
cases (ordered tree/list) would require that and just asked here if
there was such an interest in that feature.
But if I were to support that in some OSS project and I knew
beforehand that this feature isn't going to be accepted in AR I
wouldn't use all code that I wrote to make a patch to Rails. I would
rather use a much simpler approach:
module ARExtensions
def add_deferrable_unique_index(table_name, columns, options={})
(add_index table_name, columns, options.merge(unique: true);
return) unless db_supports_deferrable_constraint?
name = options[:name] || ['idx', table_name, columns,
'unique'].flatten.join('_')
execute "alter table #{table_name} add constraint #{name} unique
(#{columns.join ', '}) deferrable"
end
private
def db_supports_deferrable_constraint?
# TODO: code to detect database and version here - would return
true for PG and false for MySQL
end
end
Then just include that module in your migration classes when you need
add_deferrable_unique_index. Much simpler to write than writing a
patch to AR with docs and tests.
If you don't want to scratch your itch and provide a patch, I'm
sorry, but don't expect we to accept.
Ok, I get the message, just don't expect me to contribute to Rails if
I have to submit the code before discussing it.
And, just for record, I don't like Cucumber ;)
Me neither :) But I had to try to convince you, maybe you were a
Cucumber fan, who knows? ;)
On Thu, Nov 29, 2012 at 7:27 PM, Rodrigo Rosenfeld Rosas
<rr.ro...@gmail.com <mailto: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 <mailto: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.
