There are some patches in the pipeline like [Ticket
7584](http://dev.rubyonrails.org/ticket/7584) which modify
functionality that is going to be extracted to a plugin. I suggest we
tag these 'pluginize' and make a report so people extracting things
like scaffolding can check there for updates, but the core doesn't
need to deal with them.
How do people feel about that? Should the tickets be closed, as well
as tagged? I'm not sure the best way to keep those tickets out of the
patch count but still indicate that it hasn't been dealt with.
Definitely!! Same applies for Pagination: there were more than 20 tickets for it before the cleanup. Now there are still some, lingering for 6 months or even more.
#rails-contrib:
13:47 < nextangler> I think we're just killing dynamic scaffold, actually
13:48 < nextangler> the non-rest static scaffold has already been killed
13:48 < kevinclark> ah
13:49 < kevinclark> so, that decides that ticket, but in general
13:49 < kevinclark> can we get a place to collect patches for things that core
isn't going to maintain, but might be wrapped into an
extraction?
13:49 < kevinclark> though I know the # of reports is already dizzying
13:49 < nextangler> I think we should just treat that as regular patches. Like
the pagination thing.
13:50 < nextangler> Extraction plugins should live at something like
plugins/legacy on the official rails svn
13:50 < kevinclark> ah, we can just change the "Component" setting to plugins
I think we shouldn't close patches that address a real problem. Patches can be closed if they don't apply anymore or are crap. In all cases the authors should be redirected to the plugin effort.