Merging Better Nested Set?

Hi,

Now that acts_as_nested_set has been moved to a plugin, there has been
talk on the Better Nested Set mailing list of merging our work into
the official rails plugin. Before I put a patch together, I wanted to
ask if the core team would be receptive to this. Is the official
acts_as_nested_set plugin simply there for backwards compatibility, or
does the core team want to see it beefed up and improved?

Krishna

Now that acts_as_nested_set has been moved to a plugin, there has been
talk on the Better Nested Set mailing list of merging our work into
the official rails plugin. Before I put a patch together, I wanted to
ask if the core team would be receptive to this. Is the official
acts_as_nested_set plugin simply there for backwards compatibility, or
does the core team want to see it beefed up and improved?

I think our position is that we'd prefer to keep the current plugins
as-is, but encourage people to start new derivative plugins that can
see further development, which then doesn't have to be backwards
compatible.

Am I the only person saddened by this? (Judging by the lack of other
responses to the thread, the answer may well be "yes". If so, please
indicate your continued non-sadness by, um, not responding, I guess...)

IIRC, this policy wasn't really discussed much when it was adopted - it
sort of just got announced as "we think we're going in that direction" and
then nobody (else) objected. Obviously, the core team can do whatever it
wants, but I'd love to at least see some debate about it.

I understand the reticence to "bless" a particular plugin that's no longer
part of core. On the other hand, as Rails matures, there's an awful lot of
functionality that either starts to or ceases to align with the core team's
needs and interests, and it's only natural that various plugins move in and
out of core. Yet by freezing them and forcing all development to continue
as a project fork, you're effectively squandering their mindshare. And
these certainly aren't the last plugins you'll later decide aren't a good
fit for core.

In some sense, that may be what you want - it was withering away in core,
so let a thousand flowers bloom and all that. Yet, to argue from
absurdity, I haven't seen anyone suggest that Rails would be improved by
freezing 1.2.6, and calling 2.0 something else. If you're spinning
something off because the core team's not interested in maintaining it, yet
there IS an active group of interested maintainers, something seems wrong.

I'm also jaded from seeing the same thing happen at a corporate level - big
company likes technology, big company buys technology, technology is now
only small part of big company and quickly gets subsumed. It is, in a way,
a disincentive to being made part of core; you'll get a lot of mindshare
early on, but later, you can be just as quickly abandoned, worse off than
you were before (unless you consider a name change to be "no big deal", in
which case, again, I point you to the "rename Rails" argument).

I wish I could enunciate my objection better, but for lack of that, I'll
just repeat: Something seems wrong. There oughta be a better way.

The specific question is:

Do you expect continued development by the core team of the acts_as_nested_set plugin?

But here are the more general questions about plugins and rails core:

I'm a bit confused about which plugins are going to be officially supported by the core team as rails goes forward.

I'm not taking any position right now on which should be but if the code is in the rails subversion repository then the only people who can make commits are the core team.

Are there a set of plugins which should continue to work for the 1.2.x series but which are deprecated for 2.x?

Are there a set of plugins which should continue to work for the 2.x series (extracted from code which was in core in the 1.2.x series) but which will be deprecated for 3.0?

Is the core team trying to head in a direction so that there are no plugins in the rails repository for future rails versions -- instead having the plugin hosting ecosystem be distributed outside the core rails repository?

Right now there are about 21 plugins in the rails repository (link to trac view below):

  http://dev.rubyonrails.org/browser/plugins

and another 4 in the legacy directory.

In the last three months only seven plugins have seen changesets:

  exception_notification
  token_generator
  acts_as_list
  in_place_editing
  acts_as_tree
  auto_complete
  acts_as_nested_set

There are four that haven't been touched in 2 years:

  localization
  deadlock_retry
  ssl_requirement
  scriptaculous_slider

and another 5 that haven't been touched in the last year.

  upload_progress
  javascript_test
  account_location
  continuous_builder
  http_authentication

How many of these plugins work with 2.0 and is new functionality planned for any of them?

In some sense, that may be what you want - it was withering away in core,
so let a thousand flowers bloom and all that. Yet, to argue from
absurdity, I haven't seen anyone suggest that Rails would be improved by
freezing 1.2.6, and calling 2.0 something else. If you're spinning
something off because the core team's not interested in maintaining it, yet
there IS an active group of interested maintainers, something seems wrong.

I guess I don't see this as a huge issue. The mistake was probably
adding it to the framework in the first place, it clearly wasn't
particularly well tested, nor was it fully featured. If the two
alternatives are:

* Ship unmaintained code while better stuff is available
* Provide the old code to people who depend on it, but let a thousand
flowers bloom.

If there's an obvious successor to any of these plugins, we can update
the README to tell people what they should be installing.

My first choice would be to allow, even encourage, the group who does want to maintain and extend nested set functionality for Rails to add their improvements to the official rails nested set plugin. That would be the easiest way for anyone needing that sort of fundamental data structure/modeling support to find a community consensus solution to the problem.

If that is too fraught, then nominating a successor (better nested set? it is what I use and have been fairly happy with) in the nested set README would be a decent second choice. What I would not like to see happen is the standard scenario where there are 10 plugins for doing XXX, but everyone uses Y - or used to. The new cool tool is Z but you have to have been hanging out listening to the discussion of XXX for you to know that the wind is blowing towards Z (and that you should ignore Y as ‘good in its day’ but on it’s way out).

My first choice would be to allow, even encourage, the group who does want
to maintain and extend nested set functionality for Rails to add their
improvements to the official rails nested set plugin. That would be the
easiest way for anyone needing that sort of fundamental data
structure/modeling support to find a community consensus solution to the
problem.

Part of the problem is that the current members of the core team
simply don't use nested_set enough to make good decisions about what
patches should and shouldn't be applied. This same problem applies
to picking maintainers for the successor-plugin. I think we're
better off with alternative plugins gaining organic acceptance rather
than having us make some arbitrary decision to bless a given plugin,
even though we don't use it.

If it becomes 'obvious' to everyone concerned that there's a single
better option, then we can reference it.

Sometimes plugins become obvious like this (will_paginate), other
times they're far from clear (all the i18n/l10n plugins).