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

[Larry Garfield]

On Monday 09 March 2009 5:22:02 pm Marcel Partap wrote:

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

Except that those high-profile developers would need to troll through contrib 
to vote on stuff.

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

Perhaps the lack of community backing is a sign that the idea really is silly?  
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.

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

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.


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

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.  Does KDE not 
get to commit something unless kernel devs sign off on it?  Of course not, that 
would be insane.  But it would get rid of that pesky "Do I use Gnome or KDE?" 
question.  Duplication is just wasted effort, right?

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

The vast majority of contrib modules have exactly one person who knows the 
code at all, 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. :-)

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

I think it should be apparent by now that you do stand alone on this issue.

> 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

Convincing people to support something unknown shouldn't be easy.  It should 
have to prove itself.  It can happen, but it takes time and generally only 
happens if the idea really does have merit.  The development process for D7 
core has changed considerably, for the better, because we only made process 
changes that made sense to those involved and that reduced workload rather 
than increasing it.

Once again, the fact that no one else supports this proposal should tell you 
something about it.

-- 
Larry Garfield
larry at garfieldtech.com