On Thursday 21 April 2005 09:28, Bèr Kessels wrote:
But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now.
I've been reading both sides of this thread with interest, and after thinking about it, I'm mostly with Bèr on this issue. He expresses concerns that crossed my mind from the very first post on this thread. One of the best things about Drupal is that by the time a module makes it into the "Releases" page on drupal.org, it's ready for production use. If people want things on a faster schedule, the Sandbox system and the HEAD CVS branch are a great way to get your hands on early code. The drupal.org site has a better visibility into CVS (for non-technical people) than many other open source project sites, in my opinion. Kudos to the site designers for that! One possibility might be to create Project nodes on drupal.org earlier in the life cycle of a new module, and have a way for code that is still in a Sandbox to show up as a link from an associated Project, but on a page that's separate from the stable/released download pages. This would have the added benefit of helping contributed-module coders (like myself) recruit "alpha testers" earlier in the development cycle. Drupal's single greatest strength, IMO, is its well-thought-out architecture. Well-thought-out architectures don't often happen if interim solutions get adopted on a large scale. The problem is that the interim solution becomes the foundation for other interim solutions that rely on its code, and by the time someone gets around to really coding up the *right* solution, it's too late because of all the legacy code. (Here in the U.S., it's a running joke how many "temporary" Quonset huts built by the Army in WWII are still being used today. Friends of my family used to live in one, in fact.) One of Drupal's few weaknesses, IMO, is that for some modules the upgrade path is not clean. Often upgade-XYZ.php scripts are not thoroughly tested, in my experience, and also there is the problem with modules popping up for one Drupal version and then not being maintained going forward. Or they get merged into core (a good thing) but the data migration path is a little bumpy for non- technical site owners. Having more interim code in core might make this even worse, because core API changes are what makes contrib modules incompatible from release to release. I don't mean to be overly critical on this last point. If I didn't consider Drupal to be utterly fantastic in every way that matters, I wouldn't be here. But I think we have good, solid, stable core right now, and acceptably-stable contributed modules. To step back from that stability even a little would, in my opinion, be a mistake. Now, I also recognize the legitimate desire to not hold back good features forever. There's an old adage in buying hardware that says, "You can get a PC with infinite capacity and infinite speed for free, if you wait for infinite years." The same holds in software -- waiting for the "perfect" design vs. moving ahead with "good enough" is a balancing act, a compromise. As a good example of a compromise that works well, I would point to the recent inclusion of free-tagging vocabularies into core for 4.7. Most of us would agree that, while Morbus Iff's code is a great start, it doesn't include every possible feature that people could want. Some argue for user-specific free tags, some argue for automatic detection of similar tags. BUT...The existing patch is a good interim solution because it blends smoothly into the existing core architecture. Morbus Iff's patch provides a new UI for creating and editing terms, but the underlying taxonomy schema doesn't really change except for adding a boolean flag to each vocabulary to indicate that it allows free tags. This interim solution doesn't constrain us for the future. Thus, I would argue that a balance is the best policy, and probably one that is close to what we do now -- an evolutionary, rather than revolutionary, change, such as making early-stage projects more visible but not changing the speed of putting things into Drupal core. Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher