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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, 15 Nov 2007 07:10:28 -0800 (PST), DHH wrote:> 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. -- Jay Levitt | Boston, MA | My character doesn''t like it when they Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
At 7:10 AM -0800 11/15/07, DHH wrote:> > 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.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? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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.> 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. > > -- > Jay Levitt | > Boston, MA | My character doesn''t like it when they > Faster: jay at jay dot fm | cry or shout or hit. > http://www.jay.fm | - Kristoffer > > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 26, 2007 11:13 PM, Michael Koziarski <michael@koziarski.com> wrote:> 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). -- Cynthia Kiser cynthia.kiser@gmail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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).> 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). > > -- > Cynthia Kiser > cynthia.kiser@gmail.com > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---