I probably handle up to 10 patches a week on trac. So we don't ignore
them we just treat them as quickly as we can.
Also, the goal for the upcoming 18.104.22.168 version is to remove bugs, not
What would very helful though, would be to help clean-up trac by
closing duplicated tickets, tickets that have been resolved, etc.
The mailing list is good for discussing enhancements or issues - but
patches should be posted to trac.
If you want a patche to make it in, it should be small, tackle one
feature only and have adequate tests.
It should also work in all of the following browsers: Safari 2 & 3,
Opera 9, IE 6 & 7 and Firefox 2 & 3
Hope this helps,
On Nov 22, 2:07 pm, Viktor Kojouharov <[EMAIL PROTECTED]> wrote:
> This is a bit off topic, but what would be the ideal process of
> submitting patches for you guys?
> It seems to me that the trac bugtracker is pretty much ignored, so
> should I send patches to this ML. And should I send multiple patches,
> or one big patch from which you can pick what you feel would be a good
> On Nov 22, 1:20 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
> > On Nov 22, 2007 11:57 AM, Viktor Kojouharov <[EMAIL PROTECTED]> wrote:
> > > I've made a ticket with an attached patch that adds a script insertion
> > > method a few months ago, right here:
> > >http://dev.rubyonrails.org/ticket/9871
> > Whoa, that's a lot of code.
> > I think the problem with this sort of functionality being in core is that a
> > lot of people have different requirements for their apps and also optimize
> > their code and asset files differently. We must take into account that most
> > of our users might not use the feature at all, and that we may be
> > introducing bloat to the framework then. I would welcome a cross-browser
> > feature for dynamic script tag with callback only if it were a few lines
> > long.
> > Rest of the core team, what are your opinions on any of this becoming a part
> > of the library? While dynamic script tag may not be so popular vs. bundling
> > scripts into one optimized, gzipped file, I still think CSS injection could
> > be a good addition. On the other hand, almost everything that can be
> > accomplished with CSS injection can also be done with classname switching...
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at