Re: [development] RFC: drupal as a moving target
On Mon, Apr 28, 2008 at 11:19 AM, John VanDyk <jvandyk@iastate.edu> wrote:
At 1:29 PM +0200 4/28/08, Ivan Sergio Borgonovo wrote:
Drupal is now a mature project and people start to rely on it for projects that have a longer life span than the release process of Drupal.
My understanding is that these kind of people are the target market for Acquia's commercially supported Carbon distribution.
John's comment goes to the heart of the question. I think the security is admirable in Drupal. I want to remove that entirely from the discussion, because moving target or not, we have the best security we could possibly have. But I think the central policy point worth discussing is: in order to obtain a Drupal capable of actually being used in the real world for production sites, must one be forced to opt for commerical products / versions because the real cost is enormous? I use Ubuntu, the free, open source, off-the-shelf release, and I am not forced to pay for a "Red Hat" version to rely upon it. The question being raised is this: Is Drupal being driven to be such a fast moving target that real time-to-market costs can only be afforded by large shops? If the answer were yes, then we are forced to examine whether economic/financial/corporate interests are at work pushing it in that direction. Instead of sweeping the issue under the carpet. Victor Kane http://awebfactory.com.ar
On Apr 28, 2008, at 4:32 PM, Victor Kane wrote:
I use Ubuntu, the free, open source, off-the-shelf release, and I am not forced to pay for a "Red Hat" version to rely upon it.
You *could* pay for Ubuntu, if you wanted, though.
The question being raised is this: Is Drupal being driven to be such a fast moving target that real time-to-market costs can only be afforded by large shops?
If the answer were yes, then we are forced to examine whether economic/financial/corporate interests are at work pushing it in that direction.
Canonical is credited with speeding up the development of Debian, quite the opposite of making it "business friendly" by slowing it down. If we're going to compare Drupal (and Acquia's Carbon) to Ubuntu, the more accurate comparison might be Drupal=Debian, Carbon=Ubuntu.
Instead of sweeping the issue under the carpet.
Victor Kane http://awebfactory.com.ar
Robert Douglass Senior Drupal Advisor Acquia robert@acquia.com +1 517 639 0204 (US) +49 228 4097 197 (Germany)
On Mon, Apr 28, 2008 at 11:56 AM, Robert Douglass <rob@robshouse.net> wrote:
On Apr 28, 2008, at 4:32 PM, Victor Kane wrote:
I use Ubuntu, the free, open source, off-the-shelf release, and I am not forced to pay for a "Red Hat" version to rely upon it.
You *could* pay for Ubuntu, if you wanted, though.
But the free version is robust and works as advertised. I meant what someone else said about long term support. See below to understand why. The question being raised is this: Is Drupal being driven to be such a fast moving target that real time-to-market costs can only be afforded by large shops? If the answer were yes, then we are forced to examine whether economic/financial/corporate interests are at work pushing it in that direction. Canonical is credited with speeding up the development of Debian, quite the
opposite of making it "business friendly" by slowing it down. If we're going to compare Drupal (and Acquia's Carbon) to Ubuntu, the more accurate comparison might be Drupal=Debian, Carbon=Ubuntu.
Here is the point: try to step away from the speeding up of development mindset for a moment. I want you to understand another problem: The immense cost of updating a non-trivial Drupal based site from 5.x to 6 to 7. I think it is great that development speeds ahead. What the original RFC attempts to express here is the upgrading cost, immense and almost monopolized by big shops. The community needs to gather round this real-world need: it is plenty specific and plenty concrete, I can tell you. I plan on studying it and documenting it and publishing it, in a variety of ways. Victor Kane http://awebfactory.com.ar
Instead of sweeping the issue under the carpet.
Victor Kane http://awebfactory.com.ar
Robert Douglass
Senior Drupal Advisor Acquia robert@acquia.com +1 517 639 0204 (US) +49 228 4097 197 (Germany)
On Apr 28, 2008, at 9:07 PM, Victor Kane wrote:
The question being raised is this: Is Drupal being driven to be such a fast moving target that real time-to-market costs can only be afforded by large shops?
If the answer were yes, then we are forced to examine whether economic/financial/corporate interests are at work pushing it in that direction.
I'm not convinced that it is being driven by anything but people's interests in making Drupal better. Most companies don't do upgrade projects, they do new development projects. Every time they close out a new development and launch a site, they yearn for a better Drupal that makes their site building job easier. I would argue that it is the relative infrequency and relative low demand of upgrade projects that allows the upgrade process to remain painful. As for the implication that anyone *wants* it to be hard to upgrade, I'm pretty sure you don't mean that, and would never imply it intentionally, but I've seen it expressed clearly and directly on other blogs and sites, so people are definitely thinking it. I've never known anyone who took glee or cashed in on the situation created by upgrades being hard to orchestrate.
Here is the point: try to step away from the speeding up of development mindset for a moment. I want you to understand another problem:
The immense cost of updating a non-trivial Drupal based site from 5.x to 6 to 7.
Yes, indeed.
I think it is great that development speeds ahead. What the original RFC attempts to express here is the upgrading cost, immense and almost monopolized by big shops.
Well, anything to do with really complex sites is monopolized by big shops. The complex sites I've worked on had hundreds of people involved in their making, which pretty well excludes the smaller shops. The real big shops (IBM, Oracle, PeopleSoft, SAP for example) aren't even really involved yet (though they might be in the near future), really, so big is of course relative. "Big" in the Drupal world still means >5 employees.
The community needs to gather round this real-world need: it is plenty specific and plenty concrete, I can tell you.
I totally agree. I look forward to your findings at the conclusion of your study.
Actually John and Victor's posts bring up a slightly different way of looking at this. I was about to say 'there's nothing stopping anyone skipping a core release for upgrades so they get their own two year cycle', but then I realised that I have a couple of 4.7 sites I'm planning to upgrade directly to 6.x, but need some 6.x versions of modules that aren't quite there yet - and 4.7 is officially past end of life. So obviously you can do it, but scheduling is tight, and if I was actually being paid for these two sites I might not have that option. It's been mentioned a couple of times on irc, so I can't take credit for the idea, but would it be worth discussing an extension of support for older core versions? To play devils advocate this would mean maintaining 5.x until 8.x is released (or 6.x until 9.x etc.), even if only for security. Obviously contrib support for older (and newer) versions of core remains entirely optional per maintainer/project. Going by a one year development cycle, and a 6 month contrib/site upgrade period, that would increase the usable lifetime of x version of drupal from ~18 months to ~ 30 months - and it'd do so without any slow down in actual development - although there's clearly non-trivial resources involved in 12 months additional maintenance of a core release.
So, now we are getting down to specifics which is good. The official security team policy is that we support the current release and the prior one. If we want to add a release to that list, then we need to think of a way to fund it. The volunteer fire dept approach of security team cannot possibly accept more work as it currently stands. We already review patches and issue advisories for hundreds of contrib modules on top of drupal core. IMO, It is time to fund the position of "Security Team lead". That person can then focus on optimizing the volunteers and can then decide if supporting another version is feasible. If anyone wants to fund this position, or donate their employees' time toward this, then please talk to the Drupal Association. We dont' really need more volunteers on the team IMO- coordination costs start to overwhelm the benefits.
It's been mentioned a couple of times on irc, so I can't take credit for the idea, but would it be worth discussing an extension of support for older core versions? To play devils advocate this would mean maintaining 5.x until 8.x is released (or 6.x until 9.x etc.), even if only for security. Obviously contrib support for older (and newer) versions of core remains entirely optional per maintainer/project.
Maybe we should take the Ubuntu LTS approach, beginning with D5. -----Original Message----- From: "Moshe Weitzman" <weitzman@tejasa.com> Date: Mon, 28 Apr 2008 11:35:10 To:development@drupal.org Subject: Re: [development] RFC: drupal as a moving target So, now we are getting down to specifics which is good. The official security team policy is that we support the current release and the prior one. If we want to add a release to that list, then we need to think of a way to fund it. The volunteer fire dept approach of security team cannot possibly accept more work as it currently stands. We already review patches and issue advisories for hundreds of contrib modules on top of drupal core. IMO, It is time to fund the position of "Security Team lead". That person can then focus on optimizing the volunteers and can then decide if supporting another version is feasible. If anyone wants to fund this position, or donate their employees' time toward this, then please talk to the Drupal Association. We dont' really need more volunteers on the team IMO- coordination costs start to overwhelm the benefits.
It's been mentioned a couple of times on irc, so I can't take credit for the idea, but would it be worth discussing an extension of support for older core versions? To play devils advocate this would mean maintaining 5.x until 8.x is released (or 6.x until 9.x etc.), even if only for security. Obviously contrib support for older (and newer) versions of core remains entirely optional per maintainer/project.
Moshe Weitzman wrote:
So, now we are getting down to specifics which is good. The official security team policy is that we support the current release and the prior one. If we want to add a release to that list, then we need to think of a way to fund it. The volunteer fire dept approach of security team cannot possibly accept more work as it currently stands. We already review patches and issue advisories for hundreds of contrib modules on top of drupal core.
IMO, It is time to fund the position of "Security Team lead". That person can then focus on optimizing the volunteers and can then decide if supporting another version is feasible. If anyone wants to fund this position, or donate their employees' time toward this, then please talk to the Drupal Association. We dont' really need more volunteers on the team IMO- coordination costs start to overwhelm the benefits.
I think if we could find the way to fund such a position it would be great, even if we are not supporting more than the current number of releases. (Maybe open a new thread for this issue? as I think this proposal deserves more visibility)
On 28 Apr 2008, at 15:57, catch wrote:
[...] there's clearly non-trivial resources involved in 12 months additional maintenance of a core release.
Can anyone estimate what security only (no other bug fixes) support would cost in man hours? And prior to answering that question, we would also need to decide how this would affect security policy for contributed modules on those core versions.
On Mon, Apr 28, 2008 at 9:05 AM, Alan Pritt <alan@humte.com> wrote:
On 28 Apr 2008, at 15:57, catch wrote:
[...] there's clearly non-trivial resources involved in 12 months additional
maintenance of a core release.
Can anyone estimate what security only (no other bug fixes) support would cost in man hours?
It depends on the situation. Personally, I easily spend 10-20 hours on a 5.x security release. It varies a lot depending on the straightforwardness of the fixes and who is helping. At least 3 people, two branch maintainers and the security team lead, spend up to 4 hours online to make the release, others are online to help. Various people review every incoming message and examine potential vulnerabilities. Various people write and review patches; a good patch review takes at least 30 minutes. Security releases are not straightforward, easy, or cheap. -- Neil Drumm http://delocalizedham.com
participants (8)
-
Alan Pritt -
catch -
David Strauss -
Jose A. Reyero -
Moshe Weitzman -
Neil Drumm -
Robert Douglass -
Victor Kane