enterprise needs

There will always be security releases to older versions,
which provide an
opportunity to roll in some other fixes (not new features).
For instance
there is a severe problem that prevents 4.6 working with
MySQL 5.12+ and
ISPs are converting to it. Since 4.7 is not even in beta yet
this is a show
stopper. It also has problems on the CVS of a few days ago -
I don't know
about current CVS.

IBM used to have (may still have) an issue escalation
process that declared
some problems as "Severity 1" which put teams on
solving it 24x7 until
fixed. Most current security bugs in Drupal are treated
close to this
process. I think there are bugs which deserve a similar high
priority, e.g.
the MySQL 5.12+ bug. 

> -----Original Message-----
> From: development-bouncesdrupal.org 
> [mailto:development-bouncesdrupal.org] On Behalf Of
Nedjo Rogers
> Sent: Monday, February 27, 2006 11:12 PM
> To: developmentdrupal.org
> Subject: Re: [development] enterprise needs
> 
> > 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.
> 
> Derek, I agree with your general point on 4.6.  In the
issue 
> you reference, http://drupal.org/node/4
9408, I didn't mean 
> that 4.6 was (formally) frozen--just that, to my
knowledge, 
> no one was doing much active maintenance.
> 
> But this small distinction gets fairly near the core of
the 
> issues we're discussing.  The situation is that a lot
of 
> (paid, economically significant) work depends on
volunteer 
> contributions--from Dries on down to module
maintainers.
> 
> The thing about volunteers is that you can't really
require 
> them to do work. 
> They'll contribute largely what they want to, what
interests 
> and motivates them.  Generally speaking, when there's
limited 
> time available, doing maintenance on old releases is
often 
> going to rate relatively low when measured up against,
e.g., 
> getting an innovative new version out.
> 
> So maybe the question really becomes: how do we enable
those 
> who depend on old releases to contribute to maintaining
them?
> 
> Maybe Dries' welcome approach of having a 'release 
> maintainer' is worth looking at here for more than
core.  
> Major users of modues could adopt old releases when the

> module author/maintainer no longer wishes to maintain
them. 
>