[development] enterprise needs

[Derek Wright]

On Sun, 26 Feb 2006 09:28:32 +0100  Dries Buytaert wrote:

> The real question is: why is upgrading _that_ important?

I basically agree with everything you just said.  I'd like to offer
one possible answer to this real question you raised:

  "because every module maintainer has a different opinion about how
  to manage fixes and improvements in the different versions of their
  modules, and drupal can't do much of anything without at least
  *some* modules enabled."

It seems that if you want anything improved about your 4.6 site, you
either have to manually maintain a forked copy of the 4.6 module code
base (which is what i'm doing, while trying to submit as many patches
back to the issue queues as possible), or you have to upgrade to 4.7.

A few anecdotes to illustrate the point from my recent history of
interacting with different module maintainers:

1) A trivial patch I submitted to the project.module to fix a
permission problem in 4.6 wasn't going to be committed (without some
prodding) because "4.6 is frozen", even though the code was actually
broken (one of the access control permissions didn't work at all if
you tried to enable it) and a 1-line change got it working.

2) A very handy feature in simple_access.module was discussed at great
length as a 4.6 improvement, but finally the maintainer just committed
it to the 4.7 version of simple_access and closed the issue.  To
further complicate this, the fix was done in the same commit as
porting the entire module to the 4.7 forms API, so it's now going to
be a lot of effort to extract this feature (which many people using
4.6 wish they had) from this monolithic commit and get it working in
4.6 (it doesn't appear to require 4.7 forms for any real reason).
Even if I did the work, it's unclear if the maintainer will actually
apply it to 4.6.

3) The maintainer of signup.module wants to completely re-write and
re-organize the entire 4.6 signup codebase, to make it more modular
and off-load more of the forms-related stuff it's doing into modules
it should depend on (partially in response to the avalanche of patches
i've submitted that provide new functionality I needed).  So, folks
trying to use the "stable" 4.6 signup might find that one day, when
they download the "4.6 signup" (since there's no versioning of
modules, something that makes doing your own revision control with
vendor branches more of a pain), all of a sudden the entire look and
functionality of the module has completely changed from the last 4.6
site they setup, it now depends on 3 other modules, etc.

So, 3 very handy modules have 3 completely different philosophies on
what to do with their "stable" version.  Project didn't even want to
fix a known bug with a trivial solution, since (at first) that was
considered too much of a change to a now-frozen stable release.
simple_access seems willing to do bug fixes to 4.6, but anything new
goes into 4.7.  Signup seems willing to completely change everything,
right in the middle of a "stable" version.


I'm still not sure what I think about the fact that there's no
consistency across modules in this respect.  Of course, it's great
that ultimately, everything is open source, and I can (and do) just
get my own 4.6 site working exactly how I want, with some combination
of stock modules, custom modifications, and occasionally, updates to
the modules from the real maintainers when they fix or add something I
care about.  

However, that's not an ideal model, since it makes the cost of using
drupal pretty high.  I happen to have been writing code and using CVS
for well over a decade before I ever heard of drupal, so even though I
had never written a line of php a few months ago, I could add a bunch
of functionality I needed and fix a lot of bugs I found.  But most
people trying to use drupal to setup a website aren't going to have
those skills and that experience to draw from (nor many thousands of
dollars to hire someone who does).  If one of the motivating
philosophies behind drupal is "down with The Man, let's help the
underdog" (which I totally support), that doesn't quite jive with
"only if the underdog is already a computer programmer, or has a $20K
budget for their website".

It also complicates the question "why bother upgrading?".  Depending
on what modules you need, you're often faced with the difficult (and
somewhat evil) choice of a) redo a lot of work someone already did to
the 4.7 version or b) upgrade your entire site to 4.7.


This is *not* an argument for crippling drupal by tying its hands to
backwards compatibility.  We've gone down that road for the university
research project I work on for my day job, and it's a *major* waste of
developer time, source of bloat, and maintenance costs.  I'm just
raising the issue that while the core has a clear philosophy and
(mostly) clear process, the modules are all over the map, and
precisely because of drupal's (correct) emphasis on modularity, core
drupal *on its own* isn't very useful for doing much.

I'm still too new around here to have any profound insights on what to
do about all this, so unfortunately I don't (yet) have a concrete
suggestion to share.  Given the distributed ownership and maintenance
of the contrib modules, I don't think it'd be possible (or wise) to
enforce any kind of uniformity.  I just wanted to offer my perspective
as a new drupal user and developer, trying to keep a live site happy
and stable in 4.6, but still getting new functionality or bug fixes I
need to solve real problems I'm facing.  I hope this is helpful input
into the discussion...

Thanks,
-Derek