1) What's the normal period from when a patch is submitted to when it is
reviewed or committed?
Depends. Some patches are well-tested, their motivation instantly
appeal to the reviewer, and their impact is small and well understood.
These patches are usually applied as soon as they're discovered
I've been working on improving the performance and functionality of to_xml.
Good stuff, Blair. I've taken the liberty to massively refactor the
implementation, though. Having a method going on 100+ lines of code
was a sure tell sign that it needed some love. And it never was a good
fit for base.
Well, that is why I said that, if you filter them out, you need to create
separate reports for those. I never proposed for them to be cast aside and
forgotten, but if you don't deal with this then the effect will be the other
way around: they will make regular tickets sit ignored almost indefinite
Rails Core Weekly May 29 - June 4
Dear List,
Another week has passed, here's RCW, the McCartney Edition:
This weeks kicks of with Josh Susser fixing has_and_belongs_to_many
#create method to properly populate joins with new records
:http://www.ruby-forum.com/topic/67478#new. Check out his test:
On Jun 4, 2006, at 10:43 AM, Isaac Reuben wrote:
On 6/2/06, Thibaut Barrère <[EMAIL PROTECTED]> wrote:
If all this already is available, I'll be happy to use it. If not,
would
there be some interest in it ?
Thibaut,
As a regular rails user, I'd certainly be happy if you were to pursue
thi
On 4-jun-2006, at 19:17, Kevin Clark wrote:
Precisely so. So why change a community, when you can change a
(computer)
system?
We don't want to change the community, we want to change how the
community requests new features. Those sorts of requests shouldn't be
going through trac.
There mi
On 6/2/06, Thibaut Barrère <[EMAIL PROTECTED]> wrote:
If all this already is available, I'll be happy to use it. If not, would
there be some interest in it ?
Thibaut,
As a regular rails user, I'd certainly be happy if you were to pursue
this. Would be a lot of work though, as you'd most likel
Precisely so. So why change a community, when you can change a (computer)
system?
We don't want to change the community, we want to change how the
community requests new features. Those sorts of requests shouldn't be
going through trac.
___
Rails-core
I've been using edge Rails for development. Ever since the router rewrite, Rails was broken for me on Windows. Running unit tests discovered more errors and failures than I suspected, and, since they looked win32-specific, I decided to pull up my sleeves and fix them instead of just reporting becau
With the other two debates raging on this list, I thought it might be good to breach a subject which fits in nicely with the topics being discussed; that of plugins.Feature-plugins are a great way to incubate big new features because they can easily get testing bases and are good for high-risk plug
Hi, The list would be flooded then.Setting up CI doesn't mean we should receive a mail for each and every breakage (can be
some kind of digest, or a separate mailing list like on a couple of projects around).
Additionally, most plugin breakage is intentional. If a plugin dependson implementational
On 6/4/06, Michael Koziarski <[EMAIL PROTECTED]> wrote:
> If you're overwhelmed with feature requests from a particular area, the> solution is not to force people to stop requesting. The solution is to use> Trac more effectively.Filters don't actually solve anything. If all 12 people with commit
12 matches
Mail list logo
