[development] Fwd: Drupal.org uprade: contributed module dependencies

[Jeff Eaton]

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  
> have
> 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  
immediately.

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  
> modules
> 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  
> coders
> whos job it is to not only code for Core, but also run around the  
> edges
> and bring some of the more important contributed modules up to the  
> next
> release.

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  
> before
> 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.