[development] enterprise needs

[Walt Daniels]

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-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Nedjo Rogers
> Sent: Monday, February 27, 2006 11:12 PM
> To: development at drupal.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/49408, 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. 
>