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

Wed Mar 11 10:45:30 UTC 2009

Hallo,

i agree very much to all your posting in the last days (did not check
older ones ;-) )

i suggested in the attached mail to change the decision making process
in the drupal community.

Some people agreed and i want to start a group (if it not exists) that
creates a proposal for the decision making process.

Are you willing to join such a group on groups.drupal.org?

Best 
Thomas Zahreddin

Am Mittwoch, den 11.03.2009, 11:12 +0100 schrieb 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.
> 
-------------- next part --------------
An embedded message was scrubbed...
From: Thomas Zahreddin <tz at it-arts.org>
Subject: Re: [development] Duplicated modules
Date: Wed, 11 Mar 2009 01:23:15 +0100
Size: 8704
URL: <http://lists.drupal.org/pipermail/development/attachments/20090311/409fe53f/attachment-0001.eml>