[development] Fwd: Drupal.org uprade: contributed module dependencies
jeff at viapositiva.net
Tue Nov 27 15:35:03 UTC 2007
On Nov 27, 2007, at 7:46 AM, Gordon Heydon wrote:
> Actually I think this is a sign of another underlying problem that the
> exponential growth of the community has caused.
> In previous release cycles at this time most of the major projects
> been ported, so they are at least working if not ready for the next
> stable release of Drupal.
I don't think that's really true. We've had a longish dev cycle, and
the early betas were much more "beta" than Drupal 5's. By the time D5
was this stable, there were a handful of modules ported but none of
the biggies had been migrated. If you remember, the first module
ported to Drupal 5 was the Talk Like A Pirate filter, and for more
than a month, it was actually the ONLY Drupal 5 module. ;-) For months
following D5's release, people said that it was 'pretty but useless'
because it would never have the large library of contrib modules that
4.7 did. We all know how that prediction turned out.
> One of the biggest changes at least what I think is that now is that
> most of the developers are now doing this full time and setting the
> balance between paid work and fun development of contributed modules
> sometimes becomes very hard.
Earl Miles, working for Sony, has been able to put MORE time into
Views and Panels development, both for D5 and D6, now that he's being
paid to work on those important infrastructure tools. Larry Garfield's
company Palantir has slotted him for work on the views 2 for D6
upgrade specifically because they as a company depend on it for their
work. I've upgraded VotingAPI to D6 already -- and it was one of the
'blocking' modules that kept some people from upgrading to D5
In many ways, full-time-employment for Drupal development means that
developers can more reliably allocate time to the projects that really
ARE important. It depends on individual circumstances, obviously, but
I know that I would not have had time to tackle anything complex in a
short time frame when I was doing Drupal in the evenings for fun.
The biggest challenge is not that there is less time, but that the
average site in D5 is now built on a much, much larger number of third-
party contrib modules. Its not uncommon to have thirty, forty, even
fifty contrib modules all contributing to the smooth operation of a
normal site. That's not inherently bad, as it springs out of more
granular APIs, greater flexibility, and better separation of
functionality into complimentary tools.
And that means that we depend on not just a handful of important
'headline' modules, but clouds of smaller helper modules, each of
which need to be upgraded before the average site can move forward.
And most of THEM are, in turn, waiting for those central modules --
Views and CCK -- to be ready first.
> I think we need to find ways to get the coders working on the major
> contributed modules like views and cck (if we do not have these
> at the release of Drupal 6 it will be very bad) working on getting the
> Drupal 6 releases done.
> Maybe the Drupal Association needs to not only deal with the
> infrastructure but maybe also look at bringing on some full time
> whos job it is to not only code for Core, but also run around the
> and bring some of the more important contributed modules up to the
There are developers working on these projects. There could certainly
be more, but the biggest challenges with Views and CCK are simple:
they are not just being updated to work with Drupal 6. They are being
upgraded to Views 2.0 and CCK 2.0, respectively. With enhanced APIs,
long sought-after new features, and so on. This is without a doubt a
good thing for the Drupal community, because the new releases promise
to solve lots of long-standing frustrations.
However, those changes also take time. Whether it would be better to
do a 'straight port' of Views 1.6 for Drupal 6, and CCK 1.4 for Drupal
6, is an interesting question. However, it's important to note that
when they do ship, they will also take advantage of many of the new
and enhanced capabilities of D6. Straight ports wouldn't do that.
> I think that Drupal 6 is a different release than any of the previous
> releases of Drupal. We have modules outside of core which we need
> we can more forward.
We've always had those, though. Does anyone remember the emails that
went around during the 4.7 and 5.0 release cycles? The lists of
'modules we can't release without'? This isn't a new development.
I don't mean to shoot down your concerns. I think that the UI for
Views 2, and some of the hook-driven API enhancements for CCK2, are
very important but will not be ready for some time (weeks? a month?
early January? I don't know.) I just don't think that this is a new
development -- it's just the schedule collision of a major core
release, and major version upgrades for both of those key modules.
More information about the development