[development] An alternative to common thinking in 5->6 migration

[Marcel Partap]

> Marcel, I don't know if you've noticed but you haven't managed to
> visibly convince anyone your solution is a good one.
Well yes i do have noticed. Apart from 'don't like it' and 'messes
with our ways' i have not heard any sound counter arguments though,
but that might well be enough of an argument by itself in such a
community project.

> Especially not anyone who will bother to try and implement it.
Well if we all wanted to, we could make it. Easily: it's just a matter
of breaking habits, and not even that drastically. Btw it works for
other projects (linux, wine).

> On the contrary, you have a whole host of people saying it isn't a
> good idea and giving reasons why.
Like 'nah dont like'. (Almost) noone even picked my arguments in favor
of such a process, or tried to think up how it could be made to work, 
or even propose something entirely different.

> These people (not me mind you) are the dedicated volunteers that do
> actually work hard to implement solutions to Drupals problems, and
> are each in their own way personally responsible for the current
> success of Drupal today.
Well of course but i really missed some voices from those high-profile
developers. BTW nothing would change for them, especially no increase 
in work-load.

> They do understand the background and developer culture of the
> community, and the reasons behind Drupals success.
So that implies i don't do that, which is wrong. But to truly achieve
excellence, sometimes you have to trade in a bad habit (casual
developers committing code to the central repository) for a bitter
pill (having all code not from already proven drupal master minds
undergo a transparent quality screening) for long term profit (cure
the contrib). It's simply people not liking bitter pills until they
suffer severely from their sickness.. totally human.

> Don't take this personally
Course not, but i would have hoped for some support. Without any
community backing surely my idea does sound silly.

> but your idea and justifications for it have an air of either ivory
> tower academia or heavyweight process driven enterprise thinking
> about them.
Well it's not that my proposal is totally unrealistic. Only because no
one is supporting it does it become so. Would Dries or Angela have
proposed it, everybody and his dog would be up in flames of enthusiasm
and surely consider it the right way to go.

> Neither of which have a very good track record of actually getting
> things done in a volunteer driven open source community where
> inspiration and enthusiasm is the biggest driver behind doing
> anything.
Who is trying to stop that. By preventing bull sh1t code from being
committed to the official contrib? C'mon! We could easily set up a
testing repository, set up a drupal-patches mailing list and nice up
the issue tracker to facilitate more code centric work on stuff.

> The rate of progress in both Drupal and the supporting
> infrastructure over that time has been staggering.
Yes, true. So with all that gained, how are we possibly going to loose
it through tighter quality management?

> It's a tall order claiming that the environment or culture that
> achieved that success is broken - especially since people have come
> along and announced that plenty of times in the past.
I didn't say it's broken, it just allows unlucky stuff to happen.
Modifying it a bit could solve the problem for good. Not that this
step is _required_, but maybe we as a *software* project would 
_profit_ from it.

> Why should that claim be correct now, when it has been shown to be
> false in the past?
A major core redesign is the best time to make these modifications.
Why i proposed these changes i hope i have explained sufficiently.

> Your proposal to have every D7 contrib commit vetted by some sort
> of vote would just drive away the very enthusiasm and inspiration
> that drew in all the newbie contrib developers that grew up into
> veteran developers and core contributers (and that would be the
> single best way to kill Drupal).
Ahem, no. Why would anyone insist on committing every mind fart to the
official drupal repository? Heck as stated above, how hard is it to
have a staging branch?
The main motivation to even waste my time in this discussion was to
find a solution to the problems mentioned in the original posting:
> - modules spamming the watchdog table with E_ALL warnings
> - modules ignoring the style/documentation guide lines
> - applied insane programming(TM) techniques
> - undescriptive module names
> - duplication (partial feature overlap with existing modules).
If anyone has a more viable solution at hand, i'm more than willing to 
surrender my effort to their proposal. Right now all i've heard is 
votes for natural selection. Surely that is one approach to it, but at 
least not my favorite.
Also, almost every possible use case is covered by one or the other D6 
module, making that 'no more innovation' argument really not that 
convincing. What is the point of producing D7 at all? Restructuring! 
How is that case invalid for non-core modules, simply don't see it.
Furthermore, simply don't like the fact that individuals hold the keys 
to modules. The linux kernel f.e. handles this very differently: 
contributors get mentioned in the file header.
Really, the linux approach of development is what i think drupal 
should hand pick some points from.

 > I certainly wouldn't bother releasing any Drupal
> 7 modules if that were the case.
You must be kidding.
 > And for a lot of modules (eg my
> own), they simply don't have a user base capable of evaluating the
> quality of the commit
Code voting for developers only of course - sure all this needs 
implementing. Where's a will, there's a way.

> In nearly all cases, the people doing the voting will know
> far less about coding or the internals of the module than the
> author. It won't change much in terms of code quality - it will
> just add frustration to everyones experience.
Noone wants that, not even crazy me. But my belief still is: if we 
really want to find a way to improve the process, we can do it. If i 
stand alone, this is not a fight i'll waste my blood on.

BTW, i really wished i had the time to code all the stuff i'd like to, 
but obligations (you know.. school, work and stuff *g) shrink my 
visions to small compact pressed clumps that lay around. It would 
simply need some outside support to inflate them again, but convincing 
people to support something unknown nowadays doesn't seem to be too 
easy. Ah well.. back to work, the profane.
regards


-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future