[development] Why Drupal 4.7 is late? (long)
gerhard at killesreiter.de
Mon Jan 16 14:10:33 UTC 2006
Bèr Kessels wrote:
>Thank you Karoly, for this very well written mail! It clarifies a lot.
>But, (as always) I'd like to play the devils advocate here.
I'd rather see you reviewing patches.
>As I recently wrote on my blog  there are a few things to consider:
>* Its done when its done is not a good attitude hen you want to keep
>professionals (aka those-with-agendas-plannings-and-deadlines) on board. They
>need insurance that their project can go live on Date X.
There is no insurance. There won't ever be one. Look at how often large
software companies postpone releases. And those have real clients. The
Drupal project as such does not have clients. Your clients are your
problem, nobody else's.
Also, if you want to be Drupal a viable development plattform in the
future it will be wise to invest some of your time into working on HEAD
even if it is not tied to any current project.
>* If you want people to help fixing bugs in HEAD, you must allow them to use
>head for development. IE: make it as stable as possible
We already do that.
> and give insurance
>about when things will be done.
>* If you don't provide that certainty, professional developers will have to
>decide to develop on and for the last stable release. Hence pulling away
>resources that *could* have helped with the HEAD. That could have fixed
>numerous bugs. I still see lots of 4.6 modules being released. Meaning that
>people still do no trust HEAD.
I see it the other way round: If you work a lot on head, you can judge
whether you can use head for your clients. OTOH, I find it quite normal
to use the latest stable release for a project.
>So, I am not debating against the points you make. For the reasons you give
>for why we are where we are are very well put, and very true. I just hope,
>sincerely, that we learn from this; and never ever make the almost classic
>OSS mistake to slip in huge changes in the end. Again. And that we could
>reconsider some of our release cycle methods. For, I fear this is not a
>standalone incident, but, with the growth-rate of Drupal will rather become
>standard. Meaning there will probably be no 4.8 before 2007/8.
>>Ps. If anyone wants to start bitching around "you should have released
>>without form API", then first please show your comment with a September
>>date asking for that on Drupal.org -- I met none in the roadmap posts or
>>the form API thread.
>This, however, is the only part I really disagree with. We all know that the
>FormAPI was met with great Resistance (hefty discussions at the
The discussions were mainly related to a rather controversial idea some
people had: Provide a backwards compatibility layer. I still can't
believe how much time I spent argueing against something that in the end
turned out to be not possible.
To incorporate the forms API was neccessary from a security point of
view. Anybody who did not contribute to rolling out a Drupal security
release at 4am should simply stfu when it comes to security issues.
> Should we all archive our concerns? I am sure, that on
>IRC, in mails and maybe evenon Drupal.org I have been against this big change
>at the end of the cycle. But that does not mean that I had to (try to) stop
>the patch from going in, does it?
I didn't notice much of your opposition. Good for you. :p
>Should we always vote against things that we a) do not yet fully understand or
>b) do not agree upon?
>It is a bad thing, IMO to have to -1 all decisions, that one does not really
>understand but that 'might possibly have a great impact, of which one thinks,
>it might turn out negative'. In that case one should not vote. Which, is not
>the same as a +1 !
More information about the development