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

[Victor Kane]

Marcel, Drupal uses your idea on Drupal core.

But we aren't linux and wine, we have a core and then a constellation of
contrib.

Best stuff then bubbles up through contrib (example is part of views and cck
going into core for Drupal 7)... contrib is a test tube, a source forge
(which works really well by committing mind farts and then folks vote by
using or not using, community actually decides best quality).
That way we get the most creativity, and the community decides in their
use/reuse/discard attitude towards the modules.

A thousand eyes of feature hungry users informs better than one pair of
expert eyes.

And frees up the expert to do his thing too, instead of bureaucratizing
contrib.

That's the Drupal way, and it rocks (for this particular application)!

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

On Mon, Mar 9, 2009 at 3:22 PM, Marcel Partap <mpartap at gmx.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090313/5bb6517f/attachment-0001.htm>