Em 30-11-2012 10:38, Rafael Mendonça França escreveu:
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.
Wrong, they read. I'm a core member.
You're one core member. Where are the other ones?
- 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.
This is right. But this is more like:
- someone want a feature
- someone write the patch
- the core team discuss
- we accept or reject the feature
- Maybe someone from the core that didn't participate from the
discussion has a strong opinion about the feature, we start the
discussion again and if we agree, revert.
This is how Rails works since the beginning. And I think it is working.
I have seen lots of projects working out there in some companies without
even using any kind of SCM. All projects work. It doesn't mean that they
do everything the best possible way.
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.
You said everything, all pull requests that I reviewed and the core
agree was merged. The discussions were not, since they are only email
threads. Pull requests are the best place to discussion, we can see
the implementation details and the feature overview in one place.
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.
Rails is not a set of guessing features. We try to extract features
from real applications that we think is a good fit for the framework.
And to close this thread, I'm really sorry if the contribution
experience was not good for you in the past, but you can be sure that
there are a lot of people trying to make it better now.
Please, send a patch if you want, you may be surprised. ;)
Ok, I'll give it a try, but it will take some time before I can start
working on that. I'm under pressure right now and I don't think things
will get better in my job until next year. I just tried to git pull my
rails clone and run the tests after following this:
http://edgeguides.rubyonrails.org/development_dependencies_install.html
But it seems the test suite don't pass when the falcon patch is applied
to Ruby, which is my case:
https://github.com/rails/rails/issues/8384
So, it is not that quick either to get started contributing to Rails (it
may require an hour or two just to get the tests passing).
So, I'll post-pone this patch as it seems to be a simple one and I guess
people are not opposing against it. But it is likely that I won't try to
contribute to Rails for many more years if the patch isn't accepted
after some feedback to get it in conformance with core's taste.
Cheers,
Rodrigo.
--
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.
