move_to :plugins
Pratik
if we're just waiting for someone to do it :) Are those plugins going
to be inside rails repository ?
--
Cheers!
- Pratik
http://m.onkey.org
Josh Peek
Some will be moved into the official plugin repo while others will be
completely deprecated and just put in legacy plugins waiting some some
new owner to adopt them.
Michael Koziarski
> if we're just waiting for someone to do it :) Are those plugins going
> to be inside rails repository ?
We have a list of 'things to pluginize' floating around somewhere.
I'll see if I can find it, and get them into trac tickets. As for
maintenance, the versions that get pulled out as plugins are basically
frozen, and won't be updated.
If people are passionate about the particular area, then they can
start their own plugins, and maintain them outside of the rails
repository. One of the motivations for doing this seperation is that
it tends to be functionality that's not used by most contributors, so
the current batch of rails-maintainers aren't really the best people
to evaluate patches, or enhancement requests.
--
Cheers
Koz
Matt Palmer
> If people are passionate about the particular area, then they can
> start their own plugins, and maintain them outside of the rails
> repository.
On this topic, has anyone considered a single place to manage tickets and
possibly SVN access for plugins? I'm thinking something in the style of
trac-hacks.org (which is the "go-to place" for all Trac plugins).
If it's never been tried before, I'd be willing to try and get something
setup to see if anyone actually uses it.
- Matt
Michael Koziarski
> I'll see if I can find it, and get them into trac tickets. As for
> maintenance, the versions that get pulled out as plugins are basically
> frozen, and won't be updated.
Before I post the trac tickets, I thought I'd post them here for
further discussion. Just rememer that just because something's in a
plugin, doesn't mean it's dead. The features that we're thinking of
'pluginizing' are as follows:
ActionView::Helpers::JavaScriptMacrosHelper
ActionView::Helpers::ScriptaculousHelper
ActionController::Macros
country and state select
acts_as_*
Now that last one is bound to be a little more controversial, but just
because it's moving out to a plugin doesn't mean that it'll cease to
be maintained. We currently have:
acts_as_list
acts_as_nested_set
acts_as_tree
Of those three, acts_as_nested_set basically doesn't work,
acts_as_tree isn't widely used and it seems strange to make a special
case for acts_as_list... Maintaining an ordered association is hardly
an edge case, but acts_as_list could definitely be better, and moving
it to a plugin seems a great way to encourage some experimentation.
--
Cheers
Koz
Pratik
maintain/develop all these plugins and add a few ppl as contibutors ?
From what I've seen, plugins living in rails svn tend to have slower
development cycle. And this way, you being a core member, can show
your authorita whenever needed.
-Pratik
James Adam
>
> Koz, how about you setup rubyforge project for ex-rails plugins to
> maintain/develop all these plugins and add a few ppl as contibutors ?
> From what I've seen, plugins living in rails svn tend to have slower
> development cycle. And this way, you being a core member, can show
> your authorita whenever needed.
>
> -Pratik
I think there's definitely some merit in this idea. While it would
certainly be possible to host all these plugins in the existing Rails
SVN repository, that can only really act as a bottleneck for
development, if only in terms of authorizing commit access.
That said, how will people react to the non-Trac mechanisms that
RubyForge has for issue tracking?
--
* J *
~
Pratik
can donate a lovely lighthouse page ;-)
Basically, idea behind my suggestion is to keep all these plugins
under the same roof, outside official rails repository, and with a
core member(s) as the admin of the project.
Mislav Marohnić
Well, may be instead of trac/rubyforge's dodgy issue tracking, Rick
can donate a lovely lighthouse page ;-)
Errtheblog guys and me are using Lighthouse and Warehouse for classic_pagination, will_paginate, acts_as_textiled and other plugins ( http://err.lighthouseapp.com/projects/466-plugins/overview). It has proven great, so I support this idea.
Basically, idea behind my suggestion is to keep all these plugins
under the same roof, outside official rails repository, and with a
core member(s) as the admin of the project.
Definitely. I also think that any member of the Rails community should be given commit access to a certain plugin on request if that plugin doesn't have an active maintainer. Maintainers should be also allowed to grant commit access to fellow maintainers. As long as everyone's responsible, this shouldn't get out of hand and it would be a great incubator for ideas and features while speeding up the dev cycle.
Michael Koziarski
> given commit access to a certain plugin on request if that plugin doesn't
> have an active maintainer. Maintainers should be also allowed to grant
> commit access to fellow maintainers. As long as everyone's responsible, this
> shouldn't get out of hand and it would be a great incubator for ideas and
> features while speeding up the dev cycle.
I think the best bet is for the 'will_paginate' style approach. We'll
keep a plugin in the rails repository which has the existing
functionality, and take patches to fix any glaring bugs. However new
and exciting developments can happen elsewhere.
The plugin ecosystem is a real strength of our community, delivering
new features and experiments at a pace which a single project could
never match. I don't see any reason to have an 'official' successor
until they've proven themselves with a large and happy user base.
Market forces and all that...
--
Cheers
Koz
Chris Wanstrath
> On 8/16/07, Pratik <prati...@gmail.com> wrote:
> >
> > Well, may be instead of trac/rubyforge's dodgy issue tracking, Rick
> > can donate a lovely lighthouse page ;-)
>
> Errtheblog guys and me are using Lighthouse and Warehouse for
> classic_pagination, will_paginate, acts_as_textiled and other plugins (
> http://err.lighthouseapp.com/projects/466-plugins/overview).
> It has proven great, so I support this idea.
I'd be happy to give anyone who wants to maintain an extracted plugin
access to svn://errtheblog.com/svn/plugins and the corresponding
Lighthouse account. We've got a purdy Warehouse setup at
plugins.require.errtheblog.com, too.
--
Chris Wanstrath
http://errfree.com // http://errtheblog.com
coral
organised in a handy way. We work on projects in a team, so I write an
email to one of my mates, add a screenshot and add wrike to CC. And
here it is - the issue is created in the system and we track it
together. All our stuff is in one place and everybody knows what each
one is working on.