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

[Marcel Partap]

> Except that those high-profile developers would need to troll
> through contrib to vote on stuff.
Would not. On the contrary, all people writing Drupal code could
handle all Drupal non-core code as a collective.

> Perhaps the lack of community backing is a sign that the idea
> really is silly?
Well my professor for the lecture 'quality management' came up with
several examples where there was absolutely no support for ordered
quality assurance procedures until something bad happened, at which
point someone from the institute went in for counseling and after
leaving everybody at the company highly supported the introduction of
a structured approach to quality management on the process. It may
seem to increase the amount of work needed at first, but really in the
end it does the opposite.
So no - i still don't think the idea is silly, as i understand it.
However many times my points have been misinterpreted so maybe i just
didn't make myself clear in the first place. Shame on me.

> If you want a "crowdsourced" approach to module maintenance, well,
> the crowd is right now voting against your idea in droves.  That
> should tell you something.
Yeah, but nothing about the viability of the idea of a different
approach to non-core code. And opinions change with the tides..

> You can already get email notifications of every single post to
> the issue queue if you want them.  Yet another mailing list for
> that would be a big step backward.
Well maybe all the supporting infrastructure already in place just
isn't the best it could be. Furthermore personally i still see huge
benefit in a single drupal-patches mailing list that would allow me to
take part in deciding where the code goes in a different way than
filing reports - why let wrong code get in the first place.

>> Really, the linux approach of development is what i think drupal
>>  should hand pick some points from.
> Once again, as others have pointed out, you're mapping to the
> Linux module, um, wrong.  Drupal core is to Linux kernel as Views
> is to KDE.
How can you tell me the analogy i chose is wrong? The point is not the
different layers of software but the development process. You could
also compare the SLOC of codes, or the amount of code contributors, or
the average color of the project's bike shed.

> Does KDE not get to commit something unless kernel devs sign off
> on it?  Of course not, that would be insane.
That point is so totally void.

> But it would get rid of that pesky "Do I use Gnome or KDE?"
> question. Duplication is just wasted effort, right?
Like i'm getting myself involved in another flame war, nice try.

> The vast majority of contrib modules have exactly one person who
> knows the code at all
Which is a *problem* that a different development model would address.

> , much less well enough to be able to vet and vote intelligently on
> a patch.  So it would fall to those "high level" devs to pick up
> the slack so that things could even get committed.  We're kinda
> busy already. :-)
As long as you don't _really try to imagine_ how it could work you're
not going to understand it anyways.

> I think it should be apparent by now that you do stand alone on
> this issue.
Well it is apparent to me that noone brought up any compelling
arguments against it (besides 'dont like'). Some people however voiced
their annoyance about the current situation - especially with module
duplication - which has not been addressed adequately by anyone. Also
up to now, the only approach to tackle the other existing real problem 
of overloaded, unresponsive and uncooperative module maintainers which 
hold the sole keys is mine. No alternative concept (except the new 
project queue idea, which has been already mentioned to not catch many 
of the cases) has been proposed. Yet if nothing is done, shit will 
just again hit the fan.

> Once again, the fact that no one else supports this proposal
> should tell you something about it.
Yes, that it isn't supported, which basically cancels it. That does
not imply however it would not work, nor that it would not improve
overall code quality, avoid module duplication and on the long run
prove to be a scalable development process.

The people i'd really like to have heard an opinion of are people like 
Dries, Angela and the maintainers of overly complex modules (CCK and 
Views mainly) however. But now the jury has made up their mind it is 
too late for the idea anyways.
  regards, marcel.

-- 
  "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