FAQ
Hi,

I know there are many patches are written, reviewed and committed
still. But, without intending to critique of anyone in particular, I
see a very dangerous cycle:

As Drupal 5 and 6 are very good, rock solid releases, people are
satisfied and very busy there, much less is the need, the drive and
the availability for core development. This means less patches are
written. Also core got bigger. Very, very few people touch
actions/triggers, fields, filter system, openid or for that matter,
menu just to name a few. Once a patch is written , it needs a review.
However, the testing bot, curiously, made patch reviews even harder --
no longer can a novice just install a patch, click around and report
back "works" ( the testing bot, of course added a lot of quality to
Drupal, I am not saying, down with the bot). This has very severe
consequences: we always had too few reviewers and now the entry
barrier is even harder as you need to do meaningful code reviews all
the time. Low reviewer activity means patches do not get 'bumped' and
they linger. Lingering is exacerbated by the loss of Steven and that
the single guy who can call the big decisions now has a kid (soon two)
and two companies to run. Of course, this leads to frustration on
behalf of the patch writers and even less patches get written or
reviewed and people draw back into their own little contrib empire
where they call the shots...

Regards

Karoly Negyesi

Search Discussions

  • Dmitri G at Apr 19, 2009 at 11:46 pm
    Hi chx,

    I completely agree. However, how do you suggest we make this better?

    Dmitri
    On Sun, Apr 19, 2009 at 1:38 PM, Karoly Negyesi wrote:
    Hi,

    I know there are many patches are written, reviewed and committed
    still. But, without intending to ?critique of anyone in particular, I
    see a very dangerous cycle:

    As Drupal 5 and 6 are very good, rock solid releases, people are
    satisfied and very busy there, much less is the need, the drive and
    the availability for core development. This means less patches are
    written. Also core got bigger. Very, very few people touch
    actions/triggers, fields, filter system, openid or for that matter,
    menu just to name a few. Once a patch is written , it needs a review.
    However, the testing bot, curiously, made patch reviews even harder --
    no longer can a novice just install a patch, click around and report
    back "works" ( the testing bot, of course added a lot of quality to
    Drupal, I am not saying, down with the bot). This has very severe
    consequences: we always had too few reviewers and now the entry
    barrier is even harder as you need to do meaningful code reviews all
    the time. Low reviewer activity means patches do not get 'bumped' and
    they linger. Lingering is exacerbated by the loss of Steven and that
    the single guy who can call the big decisions now has a kid (soon two)
    and two companies to run. Of course, this leads to frustration on
    behalf of the patch writers and even less patches get written or
    reviewed and people draw back into their own little contrib empire
    where they call the shots...

    Regards

    Karoly Negyesi
  • Daniel F. Kudwien at Apr 20, 2009 at 1:15 pm

    wrote:
    As Drupal 5 and 6 are very good, rock solid releases, people are
    satisfied and very busy there, much less is the need, the drive and
    the availability for core development. This means less patches are
    written. Also core got bigger. Very, very few people touch
    actions/triggers, fields, filter system, openid or for that matter,
    menu just to name a few. Once a patch is written , it needs
    a review.
    I completely agree. However, how do you suggest we make this better?

    Dmitri
    I completely agree as well. Core is way ahead of contrib and far ahead of
    actual implementations. Only a minority of contrib modules has really
    adopted all new features of D6 thus far. There is an obvious gap between
    possible implementations and actual implementations of core features in
    modules.

    This also explains the fact that only a few contrib developers have the
    energy to work on improvements to Drupal core that would actually improve
    our APIs for contrib.

    The answer to solve this is simple, but somehow disliked by some:

    Let it mature.


    i.e. defer the code freeze for D7. I know that I'm not the only one who
    would prefer that (but capitulated in disagreement).

    sun
  • Gerhard Killesreiter at Apr 20, 2009 at 1:39 pm

    Daniel F. Kudwien schrieb:

    I completely agree as well. Core is way ahead of contrib and far
    ahead of actual implementations. Only a minority of contrib modules
    has really adopted all new features of D6 thus far. There is an
    obvious gap between possible implementations and actual
    implementations of core features in modules.

    This also explains the fact that only a few contrib developers have the
    energy to work on improvements to Drupal core that would actually improve
    our APIs for contrib.

    The answer to solve this is simple, but somehow disliked by some:

    Let it mature.


    i.e. defer the code freeze for D7. I know that I'm not the only one who
    would prefer that (but capitulated in disagreement).

    I don't think you are making much sense here. You claim that module
    developers haven't found time to add the new D6 features in their code
    and at the same time want to have a D7 which is more mature (and
    presumably thus contains even more features).

    In the end your proposal would only serve to disconnect core and
    contrib even more.

    Cheers,
    Ger?release early, release often?hard
  • Daniel F. Kudwien at Apr 20, 2009 at 1:58 pm

    I don't think you are making much sense here. You claim that
    module developers haven't found time to add the new D6
    features in their code and at the same time want to have a D7
    which is more mature (and presumably thus contains even more
    features).

    In the end your proposal would only serve to disconnect core
    and contrib even more.

    Cheers,
    Ger?release early, release often?hard
    In case this really was ambigious:

    Let it [D6] mature.

    => i.e. defer the code freeze for D7.


    Obviously, I mean the exact opposite of what you understood. Contrib needs time to catch up with core.

    sun
  • Bryan Ollendyke at Apr 20, 2009 at 2:06 pm
    lol yeah, I believe the intent of the original author was to hold off on D7
    until D6 matured more from a crontrib standpoint. I'll +1 that idea. D5
    was and still is a very mature platform that you can develop and build off
    of, seemingly without "need" to upgrade if you have a site up and running
    stablly; this isn't always the case with 6 with some of the more major
    projects just getting to full releases in the last 6 months.

    I think once D6 stablizes and you start to feel that clamoring for D7 is the
    time to move to it. I know there's a push to keep the community /
    versioning alive and active since it's a very deliver or die out in the open
    source world and we want to stay on top of over big projects in our space
    but having a full functional D6 that people are adopting the APIs / features
    of and THEN working towards 7 is probably a better idea.

    I've started to notice a bunch of dev / alpha D7 module ports too; maybe
    having versions of D7 released and keeping it in the alpha phase longer
    (once it reaches that point) will encourage developers to play around with
    it and start porting things over in the interum. No timeline, no "this is
    the date we move", a more organic window to maturation much like the nature
    of open source in the first place...

    Or get it out tomorrow; I'll end up using it either way ;)

    On Mon, Apr 20, 2009 at 9:58 AM, Daniel F. Kudwien
    wrote:
    I don't think you are making much sense here. You claim that
    module developers haven't found time to add the new D6
    features in their code and at the same time want to have a D7
    which is more mature (and presumably thus contains even more
    features).

    In the end your proposal would only serve to disconnect core
    and contrib even more.

    Cheers,
    Ger?release early, release often?hard
    In case this really was ambigious:

    Let it [D6] mature.

    => i.e. defer the code freeze for D7.


    Obviously, I mean the exact opposite of what you understood. Contrib needs
    time to catch up with core.

    sun
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090420/15697f36/attachment-0001.htm>
  • Karoly Negyesi at Apr 20, 2009 at 2:18 pm

    On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke wrote:
    lol yeah, I believe the intent of the original author was to hold off on D7
    until D6 matured more from a crontrib standpoint.? I'll +1 that idea.
    I had concerns and I shared that with the community. I had no
    solutions. I stil do not have. I am not sure postponing Drupal 7 even
    further is the solution. Because then, as Gerhard says, what will you
    do when Drupal 7 gets out, send core development on vacation for two
    years?
  • Daniel F. Kudwien at Apr 20, 2009 at 2:40 pm

    From: Karoly Negyesi

    I had concerns and I shared that with the community. I had no
    solutions. I stil do not have. I am not sure postponing
    Drupal 7 even further is the solution. Because then, as
    Gerhard says, what will you do when Drupal 7 gets out, send
    core development on vacation for two years?
    Well, I asked myself the very same questions like you:
    This means less patches are written. [why?]
    Very, very few people touch actions/triggers, fields, filter system,
    openid or for that matter, menu just to name a few. [why?]
    The most obvious that crosses my mind is: Most developers did not really
    work with the current feature-set and APIs, they did not experience (and
    suffer from) current limitations, and have no clear idea or vision of how
    Drupal *should* really work. Once this prerequisite is there, we will see
    much more interest and traction in core development.

    Releasing yet another new API, developers have to catch up with, means that
    it will take them even longer to get into core development business.

    sun
  • Nancy Wichmann at Apr 20, 2009 at 3:09 pm

    Karoly Negyesi wrote:
    what will you do when Drupal 7 gets out, send core development on vacation
    for two years?
    Hmm, I wonder what would happen if we all realized that every member of DO
    is a "core developer?" There may be a few people who are more or less
    directly responsible for consolidating proposed changes, but it is the
    community at large that is responsible for making those proposals - and
    patches. Even though we sometimes refer to those privileged (burdened) few
    as "Drupal-gods," they are not perfect; they cannot predict every way
    someone will use the code, nor can they test everything all together the way
    we put them together. Those people have real lives too (I think), and have
    to do the same thing we do: fit in time for Drupal amidst all our other
    demands.
    I don't always agree with everything they do or say - I dare say chx is one
    of them who knows that already. But Drupal is a great system, and it will
    stay that way only if we all think of ourselves as core developers.
    -------------- next part --------------

    No virus found in this outgoing message.
    Checked by AVG - http://www.avg.com
    Version: 8.0.176 / Virus Database: 270.12.0/2068 - Release Date: 4/19/2009 8:04 PM
  • Nedjo Rogers at Apr 20, 2009 at 3:35 pm

    Karoly Negyesi wrote:
    On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke wrote:

    I had concerns and I shared that with the community. I had no
    solutions. I stil do not have. I am not sure postponing Drupal 7 even
    further is the solution.
    I agree that bottlenecks in the reviewing and applying of patches is a
    huge problem majorly holding up Drupal development. I suspect we need
    some significant structural changes to address it.

    Partly I think we need to look at changes in the drivers of Drupal
    development.

    There was a time when it was mainly hobbyists, who weren't particularly
    tied to external timelines. No longer. The biggest amount of focused
    development time now comes from medium to large companies needing
    specific functionality within set timelines. The typical development
    cycle for a large project (e.g., a major site or multisite installation)
    is a matter of months. Development can't wait the many months or even
    years before a new version is ready and can't deal with the uncertainty
    of fluxuating timelines. So the significant work they sponsor is almost
    never for core, which is years ahead of what can be used. It's instead
    for the current usable release version.

    Meanwhile, with fewer resources, core goes its different direction,
    choosing its own solutions to many of the same problems. And so the
    contrib-core gap increases.

    Even when a corporate-sponsored project is specifically designed to
    contribute to core, the results can be mixed at best. Take the
    internationalization work CivicActions did, sponsored by Sony Music, see
    http://drupal.org/node/383954. We worked just as hard or harder on
    numerous core fixes and enhancements as we did on work in contrib. But
    at the end of the six or seven months, when pretty much every
    significant patch had been accepted and applied in dozens of contrib
    modules (Views, CCK, Flag, Voting API, Internationalization, Date,
    etc.), practically none of our core patches had got in.

    I conclude:

    1. More than tweaks and further exhortations to just do more reviewing,
    we probably need to consider some major changes.
    2. Any changes should increase the ease and incentive of contributing
    major improvements to core as part of the regular development work.

    Here are some concrete ideas:

    1. Expand our team of core committers.

    Since 4.7 we have had a single maintainer per major version in addition
    to the permanent core committers (now reduced to one). We could consider
    changing this. Possible changes:

    a. Each core committer either becomes a permanent core committer or is
    maintained for two or three versions instead of one. E.g., while Angie
    is the primary maintainer of 7.x, some or all of Gerhard, Neil and Gabor
    retain the ability to accept and apply patches for HEAD.

    b. Two or three core committers are appointed per major release instead
    of just one.

    c. The maintainers listed at
    http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co
    are given permanent commit access to be used only in the areas they are
    responsible for.

    2. Shorten our release cycle. Instead of trying to fit many major API
    changes and improvements into each major release, we instead limit
    ourselves to a focused few changes and a much shorter timeline. This
    quickens the pace of change, reducing the contrib-core gap.

    3. Rather than always limiting new functionality to the new version, we
    accept specific, break-nothing backports in core of new functionality
    and APIs. E.g., we have two branches of each major version, one a
    feature-frozen branch (what we have now) and the other one (yes,
    somewhat less stable) that accepts selected new APIs and features that
    have been added already to HEAD. This allows contrib modules to use the
    new APIs in the current version.

    I know that all of these potential changes - and others that I hope
    others will come up with - would have potential pitfalls and disasters.
    But I think these are the sorts of discussions we should be having.
    We've recognized a long-standing issue. We need some creative thinking,
    drawing on our strengths, to consider afresh how to keep core
    development accessible, rewarding, and effective.

    Nedjo
  • Robert Douglass at Apr 20, 2009 at 4:03 pm
    Nedjo has given us the first response to chx's origninal problem
    statement that addresses the real intent of the concern, and proposes
    solutions.

    Of the three solutions Nedjo proposed, I favor c) giving targeted
    commit rights to people who have historically been the maintainers for
    certain subsystems. We would need to develop guidelines around where
    their turf ends and they are no longer free to commit without
    escalating to either the branch maintainer or a permanent core
    maintainer (Dries), but this is a feasible solution that could speed
    the development of certain subsystems (actions, triggers, openID, i18n).

    The other solution which chx and I have discussed, and which is a long
    time goal of mine, would be to reduce the size of core. We carry
    around a lot of modules that don't absolutely need to be part of core:

    - aggregator
    - blog
    - blogapi
    - forum
    - help
    - poll
    - profile
    - search
    - statistics
    - taxonomy
    - tracker

    I believe that all of these modules could have brilliant lives outside
    of core. A slimmer core means more focused development for the core
    team. It would also make us focus our attention on the APIs that
    support these very important modules. For example, the search API is
    in great need of being decoupled from the node module. If our goal
    were to remove search from core we'd need to really make sure the API
    were in place for letting core be searched.

    My argument squarely reflects opinion that "core" Drupal should be an
    application framework that doesn't offer any specialized
    functionality. Forums, polls, profiles, blogs and even taxonomy are
    specialized web application functions that don't need the 10,000
    layers of red tape that core has. I firmly believe that taxonomy, for
    example, is hampered by its presence in core. There has been amazing
    work done on turning taxonomy into something far beyond what we have
    today, but the very presence of taxonomy IN CORE means that nobody
    uses it. Same with search. When I first wrote the ApacheSolr module it
    utilized as much of the search "API" as possible. Now we're moving to
    make it completely independent of core search because there is no way
    core can keep up with our development pace.

    So, in my opinion, if you want to take Drupal to the moon, you do two
    things: 1) give more people the keys to the car, and 2) shed a bunch
    of the pieces that we currently call "core".

    Robert Douglass

    The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter
    Follow me on Twitter: http://twitter.com/robertDouglass
    On Apr 20, 2009, at 5:35 PM, Nedjo Rogers wrote:

    Karoly Negyesi wrote:
    On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke <bto108 at psu.edu>
    wrote:

    I had concerns and I shared that with the community. I had no
    solutions. I stil do not have. I am not sure postponing Drupal 7 even
    further is the solution.
    I agree that bottlenecks in the reviewing and applying of patches is a
    huge problem majorly holding up Drupal development. I suspect we need
    some significant structural changes to address it.

    Partly I think we need to look at changes in the drivers of Drupal
    development.

    There was a time when it was mainly hobbyists, who weren't
    particularly
    tied to external timelines. No longer. The biggest amount of focused
    development time now comes from medium to large companies needing
    specific functionality within set timelines. The typical development
    cycle for a large project (e.g., a major site or multisite
    installation)
    is a matter of months. Development can't wait the many months or even
    years before a new version is ready and can't deal with the
    uncertainty
    of fluxuating timelines. So the significant work they sponsor is
    almost
    never for core, which is years ahead of what can be used. It's instead
    for the current usable release version.

    Meanwhile, with fewer resources, core goes its different direction,
    choosing its own solutions to many of the same problems. And so the
    contrib-core gap increases.

    Even when a corporate-sponsored project is specifically designed to
    contribute to core, the results can be mixed at best. Take the
    internationalization work CivicActions did, sponsored by Sony Music,
    see
    http://drupal.org/node/383954. We worked just as hard or harder on
    numerous core fixes and enhancements as we did on work in contrib. But
    at the end of the six or seven months, when pretty much every
    significant patch had been accepted and applied in dozens of contrib
    modules (Views, CCK, Flag, Voting API, Internationalization, Date,
    etc.), practically none of our core patches had got in.

    I conclude:

    1. More than tweaks and further exhortations to just do more
    reviewing,
    we probably need to consider some major changes.
    2. Any changes should increase the ease and incentive of contributing
    major improvements to core as part of the regular development work.

    Here are some concrete ideas:

    1. Expand our team of core committers.

    Since 4.7 we have had a single maintainer per major version in
    addition
    to the permanent core committers (now reduced to one). We could
    consider
    changing this. Possible changes:

    a. Each core committer either becomes a permanent core committer or is
    maintained for two or three versions instead of one. E.g., while Angie
    is the primary maintainer of 7.x, some or all of Gerhard, Neil and
    Gabor
    retain the ability to accept and apply patches for HEAD.

    b. Two or three core committers are appointed per major release
    instead
    of just one.

    c. The maintainers listed at
    http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co
    are given permanent commit access to be used only in the areas they
    are
    responsible for.

    2. Shorten our release cycle. Instead of trying to fit many major API
    changes and improvements into each major release, we instead limit
    ourselves to a focused few changes and a much shorter timeline. This
    quickens the pace of change, reducing the contrib-core gap.

    3. Rather than always limiting new functionality to the new version,
    we
    accept specific, break-nothing backports in core of new functionality
    and APIs. E.g., we have two branches of each major version, one a
    feature-frozen branch (what we have now) and the other one (yes,
    somewhat less stable) that accepts selected new APIs and features that
    have been added already to HEAD. This allows contrib modules to use
    the
    new APIs in the current version.

    I know that all of these potential changes - and others that I hope
    others will come up with - would have potential pitfalls and
    disasters.
    But I think these are the sorts of discussions we should be having.
    We've recognized a long-standing issue. We need some creative
    thinking,
    drawing on our strengths, to consider afresh how to keep core
    development accessible, rewarding, and effective.

    Nedjo
  • Gábor Hojtsy at Apr 20, 2009 at 4:13 pm

    On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass wrote:
    So, in my opinion, if you want to take Drupal to the moon, you do two
    things: 1) give more people the keys to the car, and 2) shed a bunch of the
    pieces that we currently call "core".
    Would that solve our other problem: that many contrib modules got
    updates later, so it turns out after a stable release that certain
    APIs are not complete or suitable for important contrib stuff? If we
    move more of the modules which use these APIs outside of core, we go
    to pure API design without validation of those APIs with real life
    modules, no? While I agree some modules would be best to go, maybe
    moving all is not the solution. Poll was joked to be one of the best
    API validation modules (for drag and drop, AHAH, etc). While that was
    a joke to some degree, it also has roots in reality.

    G?bor
  • Robert Douglass at Apr 20, 2009 at 4:40 pm

    On Apr 20, 2009, at 6:13 PM, G?bor Hojtsy wrote:
    On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass wrote:
    So, in my opinion, if you want to take Drupal to the moon, you do two
    things: 1) give more people the keys to the car, and 2) shed a
    bunch of the
    pieces that we currently call "core".
    Would that solve our other problem: that many contrib modules got
    updates later, so it turns out after a stable release that certain
    APIs are not complete or suitable for important contrib stuff? If we
    move more of the modules which use these APIs outside of core, we go
    to pure API design without validation of those APIs with real life
    modules, no? While I agree some modules would be best to go, maybe
    moving all is not the solution. Poll was joked to be one of the best
    API validation modules (for drag and drop, AHAH, etc). While that was
    a joke to some degree, it also has roots in reality.

    G?bor
    I agree that your concerns are valid, but I think that solving those
    concerns would be easier than solving the larger core concerns raised
    by chx if we continue to follow the exact strategy that we have now.

    API validation is vitally important, and should be driven by contrib.
    Contrib should be instructing core "hey, I need this in the API so
    that I can do what I want". Contrib module maintainers currently
    submit patches to core to tend to the important APIs that affect their
    modules. Witness Earl Mile's recent patch that has major ramifications
    on future Views development. http://drupal.org/node/322344

    Contrib modules are real modules. They do a fine job of finding the
    limitations and strengths of core's APIs. The feedback loop from
    contrib to core is there, and it is strong. In one direction. Most of
    that feedback currently sits idle in the core issue queue, however,
    and contrib module authors often choose to just work around core
    instead of enhancing it.

    Poll, despite being "core's regression test", is the best example. The
    only time anyone pays any attention to poll module development is when
    other people scream "get poll out of core!" loudly enough :P These
    days, if we need regression tests, we should put them in the
    Simpletest framework.

    Another solution would be to split core into two parts. "Framework",
    and "CMS". The framework would be the things like user, node, block,
    system, actions, fields, etc., and the CMS would be things like poll,
    blog, forum and who knows what. The smart thing would be to make
    "Framework" in this case as small as possible, and push as much as we
    can into "Framework". Then "Framework" could adopt a nice, long
    release cycle and focus on big API changes, whereas "CMS" could focus
    on shorter release cycles upon any given "Framework" release.

    "CMS" would get a new set of "core" committers.
  • Andrew morton at Apr 20, 2009 at 5:15 pm

    On Mon, Apr 20, 2009 at 10:40 AM, Robert Douglass wrote:
    API validation is vitally important, and should be driven by contrib.
    Contrib should be instructing core "hey, I need this in the API so that I
    can do what I want". Contrib module maintainers currently submit patches to
    core to tend to the important APIs that affect their modules. Witness Earl
    Mile's recent patch that has major ramifications on future Views
    development. http://drupal.org/node/322344

    Contrib modules are real modules. They do a fine job of finding the
    limitations and strengths of core's APIs. The feedback loop from contrib to
    core is there, and it is strong. In one direction. Most of that feedback
    currently sits idle in the core issue queue, however, and contrib module
    authors often choose to just work around core instead of enhancing it.
    I think contrib authors submitting back core patches is really the
    exception. I know it too me two full versions of working around a
    crappy file APIs before I finally decided to wade in an experience the
    utter frustration that is core development. And even then it was two
    versions before things really started to improve. Someone at DCDC
    described core development as not a meritocracy but a
    who's-got-more-free-time-ocracy and as Nedjo identified most corporate
    sponsored development doesn't come with that free time leading to the
    idle feedback you identified.
    Another solution would be to split core into two parts. "Framework", and
    "CMS". The framework would be the things like user, node, block, system,
    actions, fields, etc., and the CMS would be things like poll, blog, forum
    and who knows what. The smart thing would be to make "Framework" in this
    case as small as possible, and push as much as we can into "Framework". Then
    "Framework" could adopt a nice, long release cycle and focus on big API
    changes, whereas "CMS" could focus on shorter release cycles upon any given
    "Framework" release.
    I like this idea but it sort of goes into the whole "golden" module
    list that seems to come up ever now and again.

    andrew
  • Nathaniel Catchpole at Apr 20, 2009 at 6:37 pm

    Another solution would be to split core into two parts. "Framework", and
    "CMS". The framework would be the things like user, node, block, system,
    actions, fields, etc., and the CMS would be things like poll, blog, forum
    and who knows what. The smart thing would be to make "Framework" in this
    case as small as possible, and push as much as we can into "Framework". Then
    "Framework" could adopt a nice, long release cycle and focus on big API
    changes, whereas "CMS" could focus on shorter release cycles upon any given
    "Framework" release.
    I like this idea but it sort of goes into the whole "golden" module
    list that seems to come up ever now and again.

    andrew
    I think the problem is less the number of modules we have in core
    (mainly CMS-ish ones), and much more that the ones we have in core are
    only there for arbitrary / historical reasons. A patch to add forum,
    blog, help, poll, tracker, taxonomy to core now would be almost
    immediately won't fixed or stay at CNW for a very long time requiring
    years of work to get right - either because there are better contrib
    alternatives, or because the code is crappy, or both. However taking
    them out requires an upgrade path and a responsible contrib
    maintainer, not to mention consensus, and getting all three of those
    at the same time is hard too.

    On the other hand, getting eternally useful modules like token, CCK,
    Views etc. into core is a very long and drawn out process too - for
    good reason - if only in part because we know that once they're in
    core it's very hard to take them out, and any wrong design
    implications have a much longer lifespan and are harder to fix (hence
    the main query in tracker module which was bringing Drupal.org down
    regularly on Drupal 5 still hasn't been fixed in core for three
    releases).

    Packaging and better install profiles might help, getting those major
    APIs into core will hopefully help us push the old-style modules out
    of core eventually as well - i.e. replace tracker.module with a couple
    of default views.

    I don't think this is the root of the various recurring frustrations
    with core development though at all - either those of us very active
    in the core issue queue or those who avoid it like the plague. In my
    opinion it's a combination of factors, most very hard to fix - hence
    threads like this and discussions in #drupal on a regular basis.

    Nat
  • Peter Wolanin at Apr 20, 2009 at 5:06 pm
    I would strongly agree with chx and others that in some way we need
    additional committers. I think that it does make sense for Dries to be
    providing overall guidance, but I think it would be helpful if in
    some/many cases Dries would lay out criteria for a proposed change to
    be accepted and then delegate review and commit implementation details
    to others.

    A few of the modules Robert mention (maybe blog, tracker, and help)
    should either go or get a serious revamping. I general, however, many
    of the module in core serve as reference implementations of certain
    APIs and allow you to build a reasonable little site with just core -
    there can and should be other or more feature-rich implementations in
    contrib.

    -Peter
    On Mon, Apr 20, 2009 at 12:13 PM, G?bor Hojtsy wrote:
    On Mon, Apr 20, 2009 at 6:03 PM, Robert Douglass wrote:
    So, in my opinion, if you want to take Drupal to the moon, you do two
    things: 1) give more people the keys to the car, and 2) shed a bunch of the
    pieces that we currently call "core".
    Would that solve our other problem: that many contrib modules got
    updates later, so it turns out after a stable release that certain
    APIs are not complete or suitable for important contrib stuff? If we
    move more of the modules which use these APIs outside of core, we go
    to pure API design without validation of those APIs with real life
    modules, no? While I agree some modules would be best to go, maybe
    moving all is not the solution. Poll was joked to be one of the best
    API validation modules (for drag and drop, AHAH, etc). While that was
    a joke to some degree, it also has roots in reality.

    G?bor
  • Karoly Negyesi at Apr 20, 2009 at 5:29 pm

    On Mon, Apr 20, 2009 at 10:06 AM, Peter Wolanin wrote:
    I would strongly agree with chx and others that in some way we need
    additional committers.
    You can't agree with me because I have not said so. Check the thread
    again :) I have not suggested anything and will not (for some time at
    least). I deliberately avoid taking sides and rather play devil's
    advocate. Do not presume I agree or disagree with any idea presented
    in here.

    The rest of this mail will be reflections on many of the things were
    raised in here.

    It really must be noted that the Drupal 6 cycle was unusual because
    major contribs decided they do not want to maintain old crap and did a
    complete refactoring and started that only once D6 was out the door.
    This, hopefully, won't repeat so in the future contribs will be ready
    somewhat sooner. This does not help the contrib-core gap, of course.

    One of the reasons I left contrib is that my perfectionist half could
    not stand the crappy code my programmer half produced. I can't write
    pretty code without peer review. If you think you can, my best advice
    is to think again. Really, peer review is almost mandatory. Simply
    allowing people to commit patches will not help our code quality.
    Really, check most contrib vs core. I started with a post which showed
    how a shortage of patch writers, reviewers and committers create a
    self strenghening cycle. Making a half-assed fix at committers is not
    enough to fix the whole cycle.

    Slimming down core is an idea but as was noted we do we need them to
    validate. Also, if you slim down core and thus speed up development,
    how again will that help the contrib-core gap?

    Now, Drupal shops. Sure, you can't sell to a client directly core
    development but what about this, say, you would ask for 100/hr on a
    project which takes 400 hrs (less hree man-months, not that much). If
    you ask 110/hr instead then that client sponsored 40 hrs of core work,
    too. On the other hand if you can get away with 110/hr then why not
    just bill that and go to the beach?
  • Andrew morton at Apr 20, 2009 at 4:52 pm

    On Mon, Apr 20, 2009 at 10:03 AM, Robert Douglass wrote:
    The other solution which chx and I have discussed, and which is a long time
    goal of mine, would be to reduce the size of core. We carry around a lot of
    modules that don't absolutely need to be part of core:
    While there might be specific modules that would be better off in
    contrib, on the whole, I think we need to have code in core that
    actually uses our APIs. Converting core modules to use a new API is
    one of the first and most informative tests the API will get. And
    importantly it happens while the original developers are still engaged
    and working with the code rather than months later when no one
    remembers exactly why a decision was made. I've heard poll.module
    referred to as the canary of the FormsAPI because it helps spot subtle
    flaws in the API that might have gone unnoticed for months after core
    ships.

    Back in the D5 beta days I tried to keep the audio module updated for
    HEAD to help test it but HEAD was insanely unstable. These days, due
    to the unittests, HEAD is the most stable I've seen since I stared
    with 4.6 but most of my modules are have enough dependencies on other
    contrib modules that it would be impossible to keep them updated.

    The one success I've had in this regard was back porting the fixes
    that quicksketch did moving the ImageAPI module into core
    (http://drupal.org/node/373613) back to the contrib module. There's
    been one core bug fixed and another identified. I'm hoping something
    similar comes from the push to get ImageCache into core
    (http://drupal.org/node/371374).

    So while I'm all for reviewing the list of modules in core and
    dropping some I think we'd be well served to have several higher level
    modules that exist solely to help smoke test our core APIs.

    andrew
  • Frédéric G. MARAND at Apr 21, 2009 at 5:18 pm
    Notwithstanding the fact that modules shed from core tend to die, I think
    some of the modules you mention could indeed be made contrib, because their
    are "application"-type (like aggregator, forum, or poll), whereas one
    (taxonomy) is what really defines Drupal to many people outside the coder
    group, and others (search, statistics, ....profile(!) ) are part of anyone's
    basic expectations in a CMS.


    ----- Original Message -----
    From: "Robert Douglass" <rob at robshouse.net>
    To: <development at drupal.org>
    Sent: Monday, April 20, 2009 6:03 PM
    Subject: Re: [development] Very concerned over Drupal's core development



    [...]
    The other solution which chx and I have discussed, and which is a long
    time goal of mine, would be to reduce the size of core. We carry
    around a lot of modules that don't absolutely need to be part of core:

    - aggregator
    - blog
    - blogapi
    - forum
    - help
    - poll
    - profile
    - search
    - statistics
    - taxonomy
    - tracker

    I believe that all of these modules could have brilliant lives outside
    of core. A slimmer core means more focused development for the core
    team. It would also make us focus our attention on the APIs that
    support these very important modules. For example, the search API is
    in great need of being decoupled from the node module. If our goal
    were to remove search from core we'd need to really make sure the API
    were in place for letting core be searched.
    [...]
  • Angela Byron at Apr 20, 2009 at 5:25 pm

    On 20-Apr-09, at 11:35 AM, Nedjo Rogers wrote:

    <snip>
    c. The maintainers listed at
    http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co
    are given permanent commit access to be used only in the areas they
    are
    responsible for.
    Let's examine the consequences of this, since it's always a popular
    option when it comes up. I'm going to choose the menu system as a
    random example, but you can easily substitute 'menu system' as
    $subsystem and 'chx and pwolanin' as $subsystem_maintainers in the
    following narrative.

    The menu system is a bit tweaky and its innards not easily understood
    by the "common developer" in the Drupal community. As a result,
    patches that improve the menu system tend to languish in the queue in
    "code needs review" for weeks or months. When a review does happen,
    it's normally on more minor things like coding style or similar; not
    about the fundamental architecture of the menu system. This is
    extremely frustrating to chx and pwolanin, the menu system
    maintainers, since they want to keep going with their crazy
    development ideas and are blocked.

    So, to resolve the issue of menu system patches languishing in the
    queue, chx and pwolanin are granted commit access to the menu system.
    Suddenly, all of our problems with languishing patches magically
    disappear! After a quick discussion in #drupal-dev, patch after patch
    that improves the menu system is committed. The menu system has never
    evolved so quickly in such a short period of time! And better still,
    the committers for the field API, the database system, actions/
    triggers, etc. are all empowered to do so as well, so Drupal evolves
    at lightning speed! WIN!

    Of course, without any kind of peer oversight, while these patches
    that get committed make perfect sense to chx and pwolanin, they
    completely mystify the "common developer." When Drupal 7 is released,
    it becomes painfully obvious that we've developed extremely well-
    engineered subsystems without ever exposing a "real" human developer
    to having to work with them. And since these patches only needed to
    make sense to two subsystem maintainers with intimate knowledge of the
    underlying subsystem already, documentation is extremely sparse. It's
    now way harder than ever before to jump in and get involved in core
    development.

    Worse, because all of these subsystems were rapidly evolving within
    their own sphere, 20, 30, perhaps 50 patches committed per day, it's
    become impossible for anyone to oversee all of them; at best you have
    people inspecting one-off patches here and there. That means things
    like coding standards compliance, performance benchmarking, algorithm
    optimization, and the collective DX (not to mention UX) experience of
    Drupal 7 plummets. Drupal 7 is usable by chx, pwolanin, DamZ, catch,
    and about 20 other people, and everyone else switches to Django. ;)

    We have this kind of decentralized development model, where one or two
    people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with sub-
    standard, shoddily documented code that needs to be closely inspected
    by individual site maintainers before being deployed on any serious
    production sites.

    The entire strength of Drupal core *is* that it is peer reviewed
    (sometimes mercilessly so :)), it has oversight from others who are
    *not* deeply immersed in APIs who can give sanity checks, and has
    people who are bringing a very *diverse* range of experience levels,
    specializations, and use cases. You remove that, you remove what I
    would argue is the very heart and soul of Drupal.

    "But webchick!" I hear you say. "Obviously, we wouldn't let these
    subsystem maintainers work /completely/ bereft of peer review. We'd
    surely have someone else check over their work." And I say, "Great!
    Then *why aren't these mythical someones doing this right now*?" and
    *then* you get at what I believe is the /actual/ root of the problem. ;)

    *We need to grow the base of people who have understanding in these
    subsystems.*

    People who consider themselves subsystem maintainers should be
    actively working to build teams around their subsystem of choice. They
    should be documenting how their underlying APIs work so that someone
    without familiarity could jump in and get oriented quickly. They
    should be recruiting from contrib authors who are doing interesting/
    innovative work in their areas. They should be maintaining a "patch
    spotlight" page under http://drupal.org/community-initiatives/drupal-core
    so that people who want to jump in and don't know where to start
    have a direction. They should be guiding and mentoring "younger"
    contributors on how to do patch reviews, and actively advocating for
    others to do so as well.

    If subsystem maintainers do this, the collective IQ of the Drupal
    development community goes up, we grow the larger pool of
    contributors, and no patch gets left as code needs review. Then you
    can come back to me when the RTBC queue is 6 pages long (as opposed to
    cleared down to zero about once every couple of months as it has been)
    and say "webchick, we need subsystem maintainers to have commit
    rights, because these patches have all been thoroughly peer reviewed
    and are languishing at RTBC." and I will probably back you up 110%.

    -Angie
  • Matt Farina at Apr 20, 2009 at 6:02 pm
    A few idea (I'm flinging IT at the wall to see what sticks):

    1) Building on what Angie wrote about teams. We could put some time
    into tools to help people build teams. g.d.o helps with the tools. We
    could see what's missing and bring the tools there to help form the
    teams. Maybe come up with common solutions to making successful teams
    and sharing them. Maybe a guide to team building. It may seem basic
    but a guide can help people who don't know how.

    2) The complex systems (like filters, menus, etc.) can be scary to
    people. Even really smart and capable developers. We could create
    training and teaching to explain how these work and why these work the
    way they do. The caching systems interaction with filters has caused
    more than a few questions, arguments, and violent beatings on drupal
    code. Tools to lower the barrier to entry to understand the more
    complex systems can invite people to learn them and learn how to code
    better raising the bar overall.

    3) dww started to work on a distribution system for drupal some time
    ago. A package with an install profile, drupal core, modules, themes,
    etc. Imagine drupal.org creating distributions. There could be one for
    blogging, a video site, a knowledge management system, etc. We could
    be less worried about what core puts out for people to use and let it
    be a tool that things are built upon.

    The concern I've had is more along the lines of what chx noted. Go
    back and read it. It's not the committing of patches. It's the people
    with expertise in different areas working on and reviewing patches.
    For all the hundreds of people working on core there are areas we need
    more people qualified to work on the tough stuff, more people
    reviewing patches, and more people crafting them to be core worthy.
    More committers doesn't help with this part of the process (though
    that may eventually become a bottleneck).

    Additionally, there is the time aspect. Core development isn't a high
    priority for many people. How can we change that? If it's a priority
    people will find to be involved.

    Matt
    On Apr 20, 2009, at 1:25 PM, Angela Byron wrote:

    On 20-Apr-09, at 11:35 AM, Nedjo Rogers wrote:

    <snip>
    c. The maintainers listed at
    http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co
    are given permanent commit access to be used only in the areas they
    are
    responsible for.
    Let's examine the consequences of this, since it's always a popular
    option when it comes up. I'm going to choose the menu system as a
    random example, but you can easily substitute 'menu system' as
    $subsystem and 'chx and pwolanin' as $subsystem_maintainers in the
    following narrative.

    The menu system is a bit tweaky and its innards not easily
    understood by the "common developer" in the Drupal community. As a
    result, patches that improve the menu system tend to languish in the
    queue in "code needs review" for weeks or months. When a review does
    happen, it's normally on more minor things like coding style or
    similar; not about the fundamental architecture of the menu system.
    This is extremely frustrating to chx and pwolanin, the menu system
    maintainers, since they want to keep going with their crazy
    development ideas and are blocked.

    So, to resolve the issue of menu system patches languishing in the
    queue, chx and pwolanin are granted commit access to the menu
    system. Suddenly, all of our problems with languishing patches
    magically disappear! After a quick discussion in #drupal-dev, patch
    after patch that improves the menu system is committed. The menu
    system has never evolved so quickly in such a short period of time!
    And better still, the committers for the field API, the database
    system, actions/triggers, etc. are all empowered to do so as well,
    so Drupal evolves at lightning speed! WIN!

    Of course, without any kind of peer oversight, while these patches
    that get committed make perfect sense to chx and pwolanin, they
    completely mystify the "common developer." When Drupal 7 is
    released, it becomes painfully obvious that we've developed
    extremely well-engineered subsystems without ever exposing a "real"
    human developer to having to work with them. And since these patches
    only needed to make sense to two subsystem maintainers with intimate
    knowledge of the underlying subsystem already, documentation is
    extremely sparse. It's now way harder than ever before to jump in
    and get involved in core development.

    Worse, because all of these subsystems were rapidly evolving within
    their own sphere, 20, 30, perhaps 50 patches committed per day, it's
    become impossible for anyone to oversee all of them; at best you
    have people inspecting one-off patches here and there. That means
    things like coding standards compliance, performance benchmarking,
    algorithm optimization, and the collective DX (not to mention UX)
    experience of Drupal 7 plummets. Drupal 7 is usable by chx,
    pwolanin, DamZ, catch, and about 20 other people, and everyone else
    switches to Django. ;)

    We have this kind of decentralized development model, where one or
    two people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with sub-
    standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on
    any serious production sites.

    The entire strength of Drupal core *is* that it is peer reviewed
    (sometimes mercilessly so :)), it has oversight from others who are
    *not* deeply immersed in APIs who can give sanity checks, and has
    people who are bringing a very *diverse* range of experience levels,
    specializations, and use cases. You remove that, you remove what I
    would argue is the very heart and soul of Drupal.

    "But webchick!" I hear you say. "Obviously, we wouldn't let these
    subsystem maintainers work /completely/ bereft of peer review. We'd
    surely have someone else check over their work." And I say, "Great!
    Then *why aren't these mythical someones doing this right now*?" and
    *then* you get at what I believe is the /actual/ root of the
    problem. ;)

    *We need to grow the base of people who have understanding in these
    subsystems.*

    People who consider themselves subsystem maintainers should be
    actively working to build teams around their subsystem of choice.
    They should be documenting how their underlying APIs work so that
    someone without familiarity could jump in and get oriented quickly.
    They should be recruiting from contrib authors who are doing
    interesting/innovative work in their areas. They should be
    maintaining a "patch spotlight" page under http://drupal.org/community-initiatives/drupal-core
    so that people who want to jump in and don't know where to start
    have a direction. They should be guiding and mentoring "younger"
    contributors on how to do patch reviews, and actively advocating for
    others to do so as well.

    If subsystem maintainers do this, the collective IQ of the Drupal
    development community goes up, we grow the larger pool of
    contributors, and no patch gets left as code needs review. Then you
    can come back to me when the RTBC queue is 6 pages long (as opposed
    to cleared down to zero about once every couple of months as it has
    been) and say "webchick, we need subsystem maintainers to have
    commit rights, because these patches have all been thoroughly peer
    reviewed and are languishing at RTBC." and I will probably back you
    up 110%.

    -Angie
  • Dries Buytaert at Apr 20, 2009 at 6:35 pm

    On Mon, Apr 20, 2009 at 8:02 PM, Matt Farina wrote:
    The concern I've had is more along the lines of what chx noted. Go back and
    read it. It's not the committing of patches. It's the people with expertise
    in different areas working on and reviewing patches. For all the hundreds of
    people working on core there are areas we need more people qualified to work
    on the tough stuff, more people reviewing patches, and more people crafting
    them to be core worthy. More committers doesn't help with this part of the
    process (though that may eventually become a bottleneck).
    This is spot on.

    It's important that we look at Drupal core development at the
    macro-level -- "Drupal core is a very healthy project that is making
    steady progress, but it risks going too fast and becoming too complex
    for (contrib) developers". Often, contributors, including myself,
    are thinking at the micro-level -- "my patch is really important, but
    it doesn't bubble to the top, and it doesn't get committed so let's
    get grumpy because things are too slow".

    Giving more people commit access doesn't solve the macro-problem. It
    seemingly solves the micro-level problem, but at the expense of making
    the macro-level problem worse. That is key to understand -- and
    explained by webchick.

    Matt is spot on because he succeeds at looking at the macro-level.

    It is what I call a 'community responsibility' to help solve this
    problem. From doing a better job educating people to fighting
    complexity. The fact that we have poll module is not a source of
    complexity because it can be safely ignored 98% of the time. The fact
    that we have difficult to understand subsystems and increasingly more
    Drupal-isms is a problem.

    --
    Dries Buytaert :: http://buytaert.net/
  • Daniel F. Kudwien at Apr 20, 2009 at 7:21 pm
    From my point of view, this discussion has some real value, but targets
    other areas that could use improvement.

    Braindump:

    It's not about the speed of patches being committed.

    It's about core patches lacking review, and core evolving in ways and areas
    that leave contrib behind.

    It's about contrib development not being able to catch up with core.

    Core development is driven by some core developers. Only a few of them
    being contrib maintainers.

    But the real applications live in contrib.

    Contrib developers need to catch up with new core APIs and features before
    they can think about and work on improving core.

    But next to catching up with that, they also have to maintain, solve issues,
    and develop new stuff for their projects/applications. By doing so, they
    identify areas in core that need improvement.

    At the time they realize what needs improvement, new core APIs are released,
    so they start from scratch.

    Contrib should influence and drive core development.

    Currently, I experience the opposite. I have to decide whether I want to
    improve my XYZ module or whether I want to work on core without taking into
    account what XYZ module would really need in X months when new core is
    released.

    If I do both, neither core nor my module is mature.


    Gotta go.

    sun
  • Earl Miles at Apr 20, 2009 at 6:04 pm

    Angela Byron wrote:
    We have this kind of decentralized development model, where one or two
    people are solely responsible for code with basically zero peer review.
    It's called contrib. And it's notoriously filled with sub-standard,
    shoddily documented code that needs to be closely inspected by
    individual site maintainers before being deployed on any serious
    production sites.
    I stop following your argument here. The only way this argument holds up
    is that if *all* of contrib is substandard crap. It is not. There is a
    level of contrib that is above that, and there is a reason those
    particular pieces of contrib are above that. Chew on that.
  • Angela Byron at Apr 20, 2009 at 6:15 pm

    On 20-Apr-09, at 2:04 PM, Earl Miles wrote:

    Angela Byron wrote:
    We have this kind of decentralized development model, where one or
    two people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with sub-
    standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on
    any serious production sites.
    I stop following your argument here. The only way this argument
    holds up is that if *all* of contrib is substandard crap. It is not.
    There is a level of contrib that is above that, and there is a
    reason those particular pieces of contrib are above that. Chew on
    that.
    And this level contrib is the kind that has enough users so that peer
    reviews occur naturally, or at the very least peer QA after the fact.
    As we've noted, peer review and peer QA is *not* happening with these
    core subsystems, which makes it a lot closer to the "darker, scarier"
    contrib. So I'm not sure what there is to chew on. :)

    -Angie
  • Earl Miles at Apr 20, 2009 at 6:20 pm

    Angela Byron wrote:
    On 20-Apr-09, at 2:04 PM, Earl Miles wrote:

    Angela Byron wrote:
    We have this kind of decentralized development model, where one or
    two people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with
    sub-standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on any
    serious production sites.
    I stop following your argument here. The only way this argument holds
    up is that if *all* of contrib is substandard crap. It is not. There
    is a level of contrib that is above that, and there is a reason those
    particular pieces of contrib are above that. Chew on that.
    And this level contrib is the kind that has enough users so that peer
    reviews occur naturally, or at the very least peer QA after the fact. As
    we've noted, peer review and peer QA is *not* happening with these core
    subsystems, which makes it a lot closer to the "darker, scarier"
    contrib. So I'm not sure what there is to chew on. :)
    Perhaps you attribute more peer review and QA to some of these modules
    than is truly there. I don't think there is very much. There is peer
    review pretty much after the fact; that's the review that said "it's ok
    to use this module."

    But the responsibility of the committer is what made that happen in the
    first place. I personally believe that anyone who is given the right to
    commit directly to Drupal core is going to think several times longer
    before committing something than he or she would to contrib. Obviously
    this varies based on personality, but the suggestion that adding more
    committers to core will turn core into contrib does not work for me.
  • Angela Byron at Apr 20, 2009 at 6:48 pm

    On 20-Apr-09, at 2:20 PM, Earl Miles wrote:

    Angela Byron wrote:
    On 20-Apr-09, at 2:04 PM, Earl Miles wrote:
    Angela Byron wrote:
    We have this kind of decentralized development model, where one
    or two people are solely responsible for code with basically zero
    peer review. It's called contrib. And it's notoriously filled
    with sub-standard, shoddily documented code that needs to be
    closely inspected by individual site maintainers before being
    deployed on any serious production sites.
    I stop following your argument here. The only way this argument
    holds up is that if *all* of contrib is substandard crap. It is
    not. There is a level of contrib that is above that, and there is
    a reason those particular pieces of contrib are above that. Chew
    on that.
    And this level contrib is the kind that has enough users so that
    peer reviews occur naturally, or at the very least peer QA after
    the fact. As we've noted, peer review and peer QA is *not*
    happening with these core subsystems, which makes it a lot closer
    to the "darker, scarier" contrib. So I'm not sure what there is to
    chew on. :)
    Perhaps you attribute more peer review and QA to some of these
    modules than is truly there. I don't think there is very much. There
    is peer review pretty much after the fact; that's the review that
    said "it's ok to use this module."

    But the responsibility of the committer is what made that happen in
    the first place. I personally believe that anyone who is given the
    right to commit directly to Drupal core is going to think several
    times longer before committing something than he or she would to
    contrib. Obviously this varies based on personality, but the
    suggestion that adding more committers to core will turn core into
    contrib does not work for me.
    I guess I view it as the following simple pseudo-query, assuming an
    active maintainer:

    $relative_project_quality = db_result(db_query('SELECT (number of
    active participants in issues, filtering out '+1 subscribe') FROM
    {the_issue_queue} WHERE project = %d', $project->nid)).

    On a project such as Views, with a very high number,
    $relative_project_quality will be very high. On a project such as any
    of mine ;) with a very low number, code quality will be much lower.
    This is not because I'm a horrible coder or that I'm not conscientious
    about my work or that I don't care about quality. It's because there's
    no body of diverse people chiming in to say "actually that will break
    my use case and here's why," or "I actually find that a bit hard to
    grasp; what if we did it this way instead?" There's no one looking
    over my shoulder for obvious brain-os that I miss in the height of my
    caffeine-powered coding rush. And furthermore, even if I *wanted* to
    bounce ideas off of more experienced developers or peers (which I
    do!), I quite simply can't; they don't have expertise in this space.
    So I do what most contributed module authors do, which is muddle
    through and try my best.

    Now, if you do the above query with project = 3060, you will get an
    extremely healthy project. And by having only a small number of
    committers, through whom *all* changes are run, this number holds
    true. However, If we move to a subsystem maintainer committing model,
    we need to change that query for the Drupal project so that it's WHERE
    project_component = %d. And if you do /that/, you do not get a rosy
    Views-esque picture of things like the menu system. You get a very
    worst-case scenario picture of webchick-maintained contributed modules.

    So my argument is quite simply that without building this number much
    higher for each of the underlying subsystems, I don't see what choice
    core has *but* to turn into the dark, scary kind of contrib by adding
    more committers to the mix.

    -Angie
  • Earl Miles at Apr 20, 2009 at 7:02 pm

    Angela Byron wrote:
    On 20-Apr-09, at 2:20 PM, Earl Miles wrote:

    Angela Byron wrote:
    On 20-Apr-09, at 2:04 PM, Earl Miles wrote:
    Angela Byron wrote:
    We have this kind of decentralized development model, where one or
    two people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with
    sub-standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on
    any serious production sites.
    I stop following your argument here. The only way this argument
    holds up is that if *all* of contrib is substandard crap. It is not.
    There is a level of contrib that is above that, and there is a
    reason those particular pieces of contrib are above that. Chew on that.
    And this level contrib is the kind that has enough users so that peer
    reviews occur naturally, or at the very least peer QA after the fact.
    As we've noted, peer review and peer QA is *not* happening with these
    core subsystems, which makes it a lot closer to the "darker, scarier"
    contrib. So I'm not sure what there is to chew on. :)
    Perhaps you attribute more peer review and QA to some of these modules
    than is truly there. I don't think there is very much. There is peer
    review pretty much after the fact; that's the review that said "it's
    ok to use this module."

    But the responsibility of the committer is what made that happen in
    the first place. I personally believe that anyone who is given the
    right to commit directly to Drupal core is going to think several
    times longer before committing something than he or she would to
    contrib. Obviously this varies based on personality, but the
    suggestion that adding more committers to core will turn core into
    contrib does not work for me.
    I guess I view it as the following simple pseudo-query, assuming an
    active maintainer:

    $relative_project_quality = db_result(db_query('SELECT (number of active
    participants in issues, filtering out '+1 subscribe') FROM
    {the_issue_queue} WHERE project = %d', $project->nid)).
    What if a project is small and so mature that there simply aren't
    issues? Does that make it poor quality? This metric does.

    Also, flexinode. That also would hit your metric, but the code quality
    of flexinode was not high. It had a huge number of issue participants
    because it was a cool idea, not good code.

    In fact, what your metric gets you are "Things people really want but
    may not work right," not "quality contrib modules."
  • Peter Wolanin at Apr 20, 2009 at 11:33 pm

    On Mon, Apr 20, 2009 at 2:48 PM, Angela Byron wrote:

    So my argument is quite simply that without building this number much higher
    for each of the underlying subsystems, I don't see what choice core has
    *but* to turn into the dark, scary kind of contrib by adding more committers
    to the mix.

    -Angie

    I have to take issue with this in as much as any added committers
    would almost certainly not (as you do not) commit their own patches.
    If we were to move towards the notion of subsystem committers I would
    imagine that they would have to be in close communication with you and
    Dires about the overall direction and API design, get one or more
    serious reviews in addition to their own review, and probably would
    have much less time for writing patches as opposed to reviewing and
    committing them. In other words, they would behave w.r.t. a subset of
    the code in much as we observe you (and Gabor, and Neil) behaving.

    -Peter
  • Gerhard Killesreiter at Apr 20, 2009 at 6:35 pm

    Earl Miles schrieb:
    Angela Byron wrote:
    We have this kind of decentralized development model, where one or two
    people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with
    sub-standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on any
    serious production sites.
    I stop following your argument here. The only way this argument holds up
    is that if *all* of contrib is substandard crap. It is not. There is a
    level of contrib that is above that, and there is a reason those
    particular pieces of contrib are above that. Chew on that.
    Because they follow core's development model?

    Cheers,
    Gerhard
  • Earl Miles at Apr 20, 2009 at 6:44 pm

    Gerhard Killesreiter wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Earl Miles schrieb:
    Angela Byron wrote:
    We have this kind of decentralized development model, where one or two
    people are solely responsible for code with basically zero peer
    review. It's called contrib. And it's notoriously filled with
    sub-standard, shoddily documented code that needs to be closely
    inspected by individual site maintainers before being deployed on any
    serious production sites.
    I stop following your argument here. The only way this argument holds up
    is that if *all* of contrib is substandard crap. It is not. There is a
    level of contrib that is above that, and there is a reason those
    particular pieces of contrib are above that. Chew on that.
    Because they follow core's development model?
    They don't, actually, or at least, mine don't. I don't post patches and
    have half a dozen people review them before I commit code. If someone
    posts a patch, chances are there's only 1 or 2 reviews on it, and I have
    to do the real review prior to deciding whether or not to commit it.
    Sometimes some patch will be both simple enough and important enough for
    more than a couple people to review it, but that is the exception, not
    the rule. Right now, it's because I try to hold myself to a high
    standard. And I admit that I can be sloppy and commit too fast due to
    the workload, but ultimately even with that I do a better job than a lot
    of contrib, simply because I try to see the bigger picture prior to
    committing.

    The reason I think more committers in targeted areas will work is
    because I think it will create more activity in those areas. The people
    who have the right to commit will have a more vested interest, and
    therefore you will get more of their time, effort and energy, plus any
    that they can draw to them. webchick commented earlier that one of the
    issues was providing an incentive to do reviews. And that's certainly a
    key issue, right there. There isn't much incentive to do reviews.
    There's the good of the project, but there is no pride of ownership in a
    review. The pride of ownership drives a lot of the initial development,
    and it drives the committers, but the reviewers?

    I cannot remember a time in the 4 years I've been with this project that
    we haven't had a longstanding complaint about lack of good patch
    reviews. That is one of the first complaints I heard then, and it is one
    of the complaints I hear now. It has not changed, and asking people to
    do more reviews has already proven to be ineffective in combatting the
    issue.

    Give your reviewers some ownership and you'll find a lot more people
    interested in reviewing.
  • Karoly Negyesi at Apr 20, 2009 at 7:08 pm

    The people who have the right to commit will have a more vested interest
    There isn't much incentive to do reviews.
    There's the good of the project, but there is no pride of ownership in a review.
    The pride of ownership drives a lot of the initial development, and it drives the
    committers, but the reviewers?
    I am giving up my neutral position (already...) and I must say: I agree.

    I *am* sloppy but if I am given the keys to Drupal core? I will
    second-guess every decision of mine for sure.
  • Sam Boyer at Apr 20, 2009 at 7:38 pm

    On Monday 20 April 2009 14:08:42 Karoly Negyesi wrote:
    The people who have the right to commit will have a more vested interest

    There isn't much incentive to do reviews.
    There's the good of the project, but there is no pride of ownership in a
    review. The pride of ownership drives a lot of the initial development,
    and it drives the committers, but the reviewers?
    I am giving up my neutral position (already...) and I must say: I agree.

    I *am* sloppy but if I am given the keys to Drupal core? I will
    second-guess every decision of mine for sure.
    Hear hear for that. Nothing like the knowledge that if you commit a screw-up,
    it'll be noted by core devs within hours (if not minutes), which any self-
    respecting dev would find at least a smidge humiliating.

    When reading this little part of the thread, I got this mental image of Angie
    and Dries each driving enormous vans along a precarious cliffside road, trying
    to listen to a cacophony of conflicting navigational advice (ranging in
    quality from "local expert guide" to "pin the tail on the donkey") mixed in
    with a healthy dose of griping and "ARE WE THERE YET?!?"

    Not intended to paint us as whiny or unhelpful. My only point: personally, I
    got a lot better at navigating after I started driving.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: This is a digitally signed message part.
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090420/d4441b85/attachment.pgp>
  • Nathaniel Catchpole at Apr 20, 2009 at 8:30 pm
    On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer
    Hear hear for that. Nothing like the knowledge that if you commit a screw-up,
    it'll be noted by core devs within hours (if not minutes), which any self-
    respecting dev would find at least a smidge humiliating.
    This is interesting, because I find it really comforting that we
    manage to pick up screw-ups both before and after commit, especially
    mine, maybe I'm not self-respecting enough. I don't really like the
    experience of coming across an issue which just got committed and have
    to mark it code needs work (sometimes with rollback patch ready if
    it's really, really bad) - but when people do it to me I don't get
    offended or overly humiliated - I'm just glad it never made it into a
    final release.

    Actually I think a big part of the problem is this perception that
    core is hard and contrib is easy, personally I find the contrib
    workflow really hard.

    A lot of people's first attempt to contribute to Drupal is often when
    they apply for a CVS account to contribute back a module. A lot of
    companies view that as their primary way to contribute back resources
    as well. What we end up with is 4,000 projects of very varying
    quality, and the projects which /everyone/ uses - Views, CCK etc. are
    crying out for people to help in their issue queues - not just writing
    and reviewing patches at a high level, but answering support requests,
    closing out duplicates, stuff like that.

    One issue with this is the way our user profiles work in terms of
    highlighting contributions. I'd been contributing to core for more
    than a year before I got a CVS account, and that was when one of my
    core patches removed a slice of user.module on the condition it was
    maintained in contrib. So for a long time I never had any projects
    listed on my profile page, nor any entries in 'track code'. I've still
    only got commit access on a handful of projects, and don't actively
    maintain any of them - a situation I'm quite happy with. However if I
    posted a couple of crappy modules and committed loads of tiny patches
    to them, then to the casual observer that'd make the user profile look
    a lot beefier.

    The only way that code contributions to core get measured is when Greg
    Knaddison parses commit logs and puts everything into a spreadsheet
    once or twice a year - our commit model also completely breaks sites
    like ohloh. Personally I'd really like better statistics on how many
    people are reviewing/submitting patches, getting them committed etc.
    since it'd at least help to spot clear trends when having discussions
    like these. And I think it'd be a bit of incentive to review and post
    patches more if there was some way of having that data recorded more
    firmly than just in commit messages themselves.

    There was talk of having 'issue queue maintainers' without actual
    commit access for contrib projects as well - for people who answer
    lots of support requests and write documentation etc. Similar issue
    and it goes two ways. Identifying the people who you need to speak to
    about a particular area is hard unless you know who they are.
    Identifying what any particular individual is doing is hard unless you
    trawl through their tracker. There ought to be better ways to deal
    with this than filing patches to add people to maintainers.txt and
    having to write big long lists of names in commit messages (then what
    if you forgot someone or spell their name wrong).

    Nat
  • Dries Buytaert at Apr 20, 2009 at 9:03 pm
    I think catch hits a lot of good points about how our reward and trust
    system could be improved. I'm all for better profile pages, giving
    credit where credit is due, and providing better visibility into who
    is working on what. It might be useful to provide a "Reviewer rating"
    or "Reviewer score" -- something which could be an incentive for more
    people to review patches. Maybe this can be accomplished through some
    project module extensions? I'm not sure what the best approach would
    be, but it is worthy of a discussion.


    On Mon, Apr 20, 2009 at 10:30 PM, Nathaniel Catchpole
    wrote:
    On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer
    Hear hear for that. Nothing like the knowledge that if you commit a screw-up,
    it'll be noted by core devs within hours (if not minutes), which any self-
    respecting dev would find at least a smidge humiliating.
    This is interesting, because I find it really comforting that we
    manage to pick up screw-ups both before and after commit, especially
    mine, maybe I'm not self-respecting enough. I don't really like the
    experience of coming across an issue which just got committed and have
    to mark it code needs work (sometimes with rollback patch ready if
    it's really, really bad) - but when people do it to me I don't get
    offended or overly humiliated - I'm just glad it never made it into a
    final release.

    Actually I think a big part of the problem is this perception that
    core is hard and contrib is easy, personally I find the contrib
    workflow really hard.

    A lot of people's first attempt to contribute to Drupal is often when
    they apply for a CVS account to contribute back a module. A lot of
    companies view that as their primary way to contribute back resources
    as well. What we end up with is 4,000 projects of very varying
    quality, and the projects which /everyone/ uses - Views, CCK etc. are
    crying out for people to help in their issue queues - not just writing
    and reviewing patches at a high level, but answering support requests,
    closing out duplicates, stuff like that.

    One issue with this is the way our user profiles work in terms of
    highlighting contributions. I'd been contributing to core for more
    than a year before I got a CVS account, and that was when one of my
    core patches removed a slice of user.module on the condition it was
    maintained in contrib. So for a long time I never had any projects
    listed on my profile page, nor any entries in 'track code'. I've still
    only got commit access on a handful of projects, and don't actively
    maintain any of them - a situation I'm quite happy with. However if I
    posted a couple of crappy modules and committed loads of tiny patches
    to them, then to the casual observer that'd make the user profile look
    a lot beefier.

    The only way that code contributions to core get measured is when Greg
    Knaddison parses commit logs and puts everything into a spreadsheet
    once or twice a year - our commit model also completely breaks sites
    like ohloh. Personally I'd really like better statistics on how many
    people are reviewing/submitting patches, getting them committed etc.
    since it'd at least help to spot clear trends when having discussions
    like these. And I think it'd be a bit of incentive to review and post
    patches more if there was some way of having that data recorded more
    firmly than just in commit messages themselves.

    There was talk of having 'issue queue maintainers' without actual
    commit access for contrib projects as well - for people who answer
    lots of support requests and write documentation etc. Similar issue
    and it goes two ways. Identifying the people who you need to speak to
    about a particular area is hard unless you know who they are.
    Identifying what any particular individual is doing is hard unless you
    trawl through their tracker. There ought to be better ways to deal
    with this than filing patches to add people to maintainers.txt and
    having to write big long lists of names in commit messages (then what
    if you forgot someone or spell their name wrong).

    Nat


    --
    Dries Buytaert :: http://buytaert.net/
  • Dries Buytaert at Apr 20, 2009 at 9:19 pm
    Something else which is worth to discuss.

    In private conversations, various people have expressed concerns that
    our release cycles are too long, and that, as a result, they are not
    interested in working on core. If they have a problem, and they fix
    it in core, they have to wait 1-2 years before they can actual use
    their own improvement in a production environment. In a lot of cases,
    people don't bother with it because they can't wait that long.

    We see evidence of that around code freeze time, when people actually
    do start to bother and patches tend to move through the review cycle
    quite a bit faster -- creating it own set of frustrations.

    In other words, moving to shorter release cycles could help. Not only
    does it increase the incentive for people to work on core, it could
    also provide additional focus. Because we have been working on Drupal
    6 so long, people might have lost some of their incentive and
    motivation. There is a certain engery-cycle/rhythm that we might have
    broken with the longer Drupal 6 development cycle.

    In fact, a lot of big projects, like the Linux kernel, Gnome, KDE,
    Ubuntu, Fedora and Wordpress all switched to 6 month release cycles.
    Mark Shuttleworth posted some good insights about that in a recent
    blog post: http://www.markshuttleworth.com/archives/288. I'm not
    suggesting that we should switch to 6 month release cycles, I'm merely
    bringing it up to get feedback on the idea.


    On Mon, Apr 20, 2009 at 11:03 PM, Dries Buytaert
    wrote:
    I think catch hits a lot of good points about how our reward and trust
    system could be improved. ?I'm all for better profile pages, giving
    credit where credit is due, and providing better visibility into who
    is working on what. ?It might be useful to provide a "Reviewer rating"
    or "Reviewer score" -- something which could be an incentive for more
    people to review patches. ?Maybe this can be accomplished through some
    project module extensions? ?I'm not sure what the best approach would
    be, but it is worthy of a discussion.
    --
    Dries Buytaert :: http://buytaert.net/
  • Marijn Kruisselbrink at Apr 20, 2009 at 9:27 pm

    On Monday 20 April 2009 23:19:03 Dries Buytaert wrote:
    In fact, a lot of big projects, like the Linux kernel, Gnome, KDE,
    Ubuntu, Fedora and Wordpress all switched to 6 month release cycles.
    Mark Shuttleworth posted some good insights about that in a recent
    blog post: http://www.markshuttleworth.com/archives/288. I'm not
    suggesting that we should switch to 6 month release cycles, I'm merely
    bringing it up to get feedback on the idea.
    I don't think any of those projects have 6 month release cycles that break
    backwards compatibility, which I think major drupal releases do...

    Marijn
  • Jamie Holly at Apr 20, 2009 at 10:24 pm

    Marijn Kruisselbrink wrote:
    On Monday 20 April 2009 23:19:03 Dries Buytaert wrote:
    In fact, a lot of big projects, like the Linux kernel, Gnome, KDE,
    Ubuntu, Fedora and Wordpress all switched to 6 month release cycles.
    Mark Shuttleworth posted some good insights about that in a recent
    blog post: http://www.markshuttleworth.com/archives/288. I'm not
    suggesting that we should switch to 6 month release cycles, I'm merely
    bringing it up to get feedback on the idea.
    I don't think any of those projects have 6 month release cycles that break
    backwards compatibility, which I think major drupal releases do...

    Marijn
    Looking at that list, one thing sticks out - there is only one
    blogging/CMS platform listed. Even though I know that list isn't a
    comprehensive collection of project release cycles, can anyone find any
    other blogging or CMS system pushing releases out every six months?

    I'm not saying its a bad thing, but I believe serious consideration
    needs to be given to backwards compatibility and support length of
    releases. Perhaps one good route for Drupal would be to mimic the Ubuntu
    system of offering a "long term support"release after X releases. That
    would benefit sites with a large custom code base, or even the smaller
    guy, who is less tech-savvy and dreads the upgrade for fear of breaking
    their site.
  • Jakob Petsovits at Apr 21, 2009 at 5:50 am

    On Monday 20 April 2009, Marijn Kruisselbrink wrote:
    On Monday 20 April 2009 23:19:03 Dries Buytaert wrote:
    In fact, a lot of big projects, like the Linux kernel, Gnome, KDE,
    Ubuntu, Fedora and Wordpress all switched to 6 month release cycles.
    Mark Shuttleworth posted some good insights about that in a recent
    blog post: http://www.markshuttleworth.com/archives/288. I'm not
    suggesting that we should switch to 6 month release cycles, I'm merely
    bringing it up to get feedback on the idea.
    I don't think any of those projects have 6 month release cycles that break
    backwards compatibility, which I think major drupal releases do...
    I think that's just another argument in favor of Robert's suggested move of
    core modules to contrib. The Form/Fields/File/whatever APIs deserve longer
    release cycles so that contrib has at least some chance to stick with feature
    work for a single core version only.

    However, for the modules built on top of the APIs (Forum, Aggregator, etc.)
    nobody really cares about API compatibility, those are the ones that would
    actually benefit from significantly shorter release cycles.

    While I'm not yet convinced that stripping down Drupal to a bare framework is
    the right approach, I do think that the two aspects of core should get
    different treatment.

    -- Jakob
  • Steven Peck at Apr 21, 2009 at 6:20 am
    To my knowledge, every module removed from Drupal core has died. I
    use several of the modules on Roberts list (blog, aggregator, blogapi)
    and if they were removed, then I would be out of luck as one of the
    few remaining 'hobbyist' users.

    And Stefan, I too miss the old front page where it wasn't all site
    implementations and Drupalcons but things people found interesting,
    but that's just what happened.

    -sepeck
    On Mon, Apr 20, 2009 at 10:50 PM, Jakob Petsovits wrote:
    On Monday 20 April 2009, Marijn Kruisselbrink wrote:
    On Monday 20 April 2009 23:19:03 Dries Buytaert wrote:
    In fact, a lot of big projects, like the Linux kernel, Gnome, KDE,
    Ubuntu, Fedora and Wordpress all switched to 6 month release cycles.
    Mark Shuttleworth posted some good insights about that in a recent
    blog post: http://www.markshuttleworth.com/archives/288. ?I'm not
    suggesting that we should switch to 6 month release cycles, I'm merely
    bringing it up to get feedback on the idea.
    I don't think any of those projects have 6 month release cycles that break
    backwards compatibility, which I think major drupal releases do...
    I think that's just another argument in favor of Robert's suggested move of
    core modules to contrib. The Form/Fields/File/whatever APIs deserve longer
    release cycles so that contrib has at least some chance to stick with feature
    work for a single core version only.

    However, for the modules built on top of the APIs (Forum, Aggregator, etc.)
    nobody really cares about API compatibility, those are the ones that would
    actually benefit from significantly shorter release cycles.

    While I'm not yet convinced that stripping down Drupal to a bare framework is
    the right approach, I do think that the two aspects of core should get
    different treatment.

    -- Jakob
  • Earl Miles at Apr 21, 2009 at 6:45 am

    Steven Peck wrote:
    To my knowledge, every module removed from Drupal core has died. I
    use several of the modules on Roberts list (blog, aggregator, blogapi)
    and if they were removed, then I would be out of luck as one of the
    few remaining 'hobbyist' users.

    And Stefan, I too miss the old front page where it wasn't all site
    implementations and Drupalcons but things people found interesting,
    but that's just what happened.
    I don't believe this would be true if we were still packaging them
    together, but treating them differently.

    Think of the Drupal Framework as the Linux Kernel, and then the Drupal
    distribution as Linux. The framework includes only the APIs -- node,
    user, base object stuff. The foundation. Drupal then provides
    applications built upon that foundation. It starts with just one:
    Something resembling Drupal as we know it today. We split core, and we
    devote effort to the most important projects. This might allow us to
    better focus efforts, anyway. One of the issues I see is that core
    itself is too big. Neither of the two committers really understand
    everything they've been committing, lately. (If you doubt me...field API =)
  • George at Apr 21, 2009 at 9:57 am

    Earl Miles wrote:
    Think of the Drupal Framework as the Linux Kernel, and then the Drupal
    distribution as Linux. The framework includes only the APIs -- node,
    user, base object stuff. The foundation. Drupal then provides
    applications built upon that foundation. It starts with just one:
    Something resembling Drupal as we know it today. We split core, and we
    devote effort to the most important projects. This might allow us to
    better focus efforts, anyway. One of the issues I see is that core
    itself is too big. Neither of the two committers really understand
    everything they've been committing, lately. (If you doubt me...field
    API =)
    I think Drupal growing in size is natural. Drupal doesn't have to fit
    onto a floppy disk. Code bloat, and overall code size are two different
    things.

    I'm really surprised and scared at how quickly Drupal is progressing. At
    this rate, contrib will never be able to keep up all the features in
    core, with only handfuls of people really understanding it, and so it
    will be a complete waste of time coding the features in the first place.
    Each radical change between major core versions means more time
    investment for contrib developers to upgrade their modules.

    So, instead of trying to clump lots of really great cool features into
    the next major release and blowing everyone away, how about picking a
    few major features, and make them the best they can be, and then adding
    other new features at a later date? This would give contrib developers
    time to develop for them, and the docs team time to document.
  • Marco Sousa at Apr 21, 2009 at 11:38 am
    Or we can have one Drupal Legacy Module that we can suport the modules of
    previous drupal release.

    Pros:
    * Lots of previous module will work.
    * The "contrib developer" have more time to decide to upgrade the module.
    (instead 1 years will have 2 years or more)
    * More users will update their Drupal version.
    * I think with that, instead contrib modules became more not up to date,
    will became more up to date. because with this we can use the modules with
    the new version of drupal, so the process of migrating modules will became
    more faster..
    Why? because some developers wait until all others modules (that they use)
    became migrated, before start..

    Cons:
    * Modules that use this module will run more slow
    * Some Modules will not run and others have some break's.


    --
    -------------------------------------
    Marco Sousa
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090421/0df8e939/attachment.htm>
  • Marco Sousa at Apr 21, 2009 at 11:46 am
    I forget, we can start suporting Drupal 7 Contrib Modules to work with
    Drupal 8.

    Because of the realy change in BD and POO...

    On Tue, Apr 21, 2009 at 1:38 PM, Marco Sousa wrote:

    Or we can have one Drupal Legacy Module that we can suport the modules of
    previous drupal release.

    Pros:
    * Lots of previous module will work.
    * The "contrib developer" have more time to decide to upgrade the module.
    (instead 1 years will have 2 years or more)
    * More users will update their Drupal version.
    * I think with that, instead contrib modules became more not up to date,
    will became more up to date. because with this we can use the modules with
    the new version of drupal, so the process of migrating modules will became
    more faster..
    Why? because some developers wait until all others modules (that they use)
    became migrated, before start..

    Cons:
    * Modules that use this module will run more slow
    * Some Modules will not run and others have some break's.


    --
    -------------------------------------
    Marco Sousa


    --
    -------------------------------------
    Marco Sousa
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090421/e5a15d7c/attachment-0001.htm>
  • Marco Sousa at Apr 21, 2009 at 11:54 am
    See the joomla way:

    Legacy Mode:
    *http://tinyurl.com/cxr45d*

    --
    -------------------------------------
    Marco Sousa
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090421/537d811e/attachment.htm>
  • Gerhard Killesreiter at Apr 21, 2009 at 12:02 pm

    Marco Sousa schrieb:
    See the joomla way:

    Legacy Mode:
    *http://tinyurl.com/cxr45d*
    Feel free to provide such a module in contrib and package it as part of
    an install profile. Or just use Joomla.

    Cheers,
    Gerhard
  • Marco Sousa at Apr 21, 2009 at 1:26 pm

    On Tue, Apr 21, 2009 at 2:02 PM, Gerhard Killesreiter wrote:
    Feel free to provide such a module in contrib and package it as part of
    an install profile. Or just use Joomla.
    Gehard, this comment is useful? Please stop that.

    I just want to give more alternatives (used by one CMS), to we have all
    variables to choose the better one..

    I'm not inflame nothing...



    --
    -------------------------------------
    Marco Sousa
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.drupal.org/pipermail/development/attachments/20090421/2ceac13d/attachment.htm>
  • Gerhard Killesreiter at Apr 21, 2009 at 1:30 pm

    Marco Sousa schrieb:
    On Tue, Apr 21, 2009 at 2:02 PM, Gerhard Killesreiter <
    gerhard at killesreiter.de> wrote:
    Feel free to provide such a module in contrib and package it as part of
    an install profile. Or just use Joomla.
    Gehard, this comment is useful? Please stop that.

    I just want to give more alternatives (used by one CMS), to we have all
    variables to choose the better one..

    I'm not inflame nothing...
    You are repeating a discussion we are having every couple of months or
    years. Last time was February, IIRC.

    This is not helpful and has to be stopped. The others gave you more
    detailed answers why your proposal is not only annoying but also not
    working.

    Cheers,
    Gerhard
  • Nathaniel Catchpole at Apr 21, 2009 at 12:07 pm

    Or we can have one Drupal Legacy Module that we can suport the modules of
    previous drupal release.

    No we can't. The API changes in Drupal 7 include things like changing
    the way modules are defined in .info files to make them compatible
    with the registry, and changing the syntax of every single database
    query. It's impossible to make a module which would allow you to run a
    Drupal 6 module on Drupal 7 with no changes, and that's a very, very
    good thing.

    It's already been said once in this thread, but the reason it took so
    long for contrib to catch up to Drupal 6 was a massive refactoring of
    CCK, Views, wysiwyg API and other modules all the same time - and the
    fact that contrib has a very complex web of dependencies (baz module
    extends foo module which extends bar module, so can't do an update
    until both bar and foo are upgraded). A Views 2 which was backwards
    compatible with Views 1 wouldn't be half as much fun - and if you just
    want to use the same D5 modules you were using already without any of
    the advantages, why upgrade at all?

    We don't make API changes for fun, we make them because we have to -
    either to correct previous mistakes or open up new possibilities. If
    an API doesn't need to change then it usually doesn't - for example
    hook_menu() is pretty much exactly the same between 6 and 7.

    All the effort talking about backwards compatibility should instead be
    focused on http://drupal.org/project/deadwood and
    http://drupal.org/project/coder - and also on the Field API and Views
    related patches to core which will be necessary for field, views, and
    views-dependent modules to upgrade to D7.

    Coder already has an initial port to Drupal 7 and does a great deal of
    the work required to update a module. The better it gets, the less
    work module maintainers (or upgrade patch contributors) need to do to
    get a basic port of their module going. Combined with unstable
    releases, it's quite possible to start upgrading modules to Drupal 7
    now - in fact there's 7 pages of modules which have some kind of port
    in the works, months before code freeze - something we've never, ever
    had before.

    http://drupal.org/project/modules?filters=drupal_core:103&solrsort=sort_title%20asc

    Nat
  • Jakob Petsovits at Apr 21, 2009 at 12:07 pm

    On Tuesday 21 April 2009, Marco Sousa wrote:
    Or we can have one Drupal Legacy Module that we can suport the modules of
    previous drupal release.
    This is proposed by someone for every Drupal version, it has been tried
    several times, and it has never worked for reasons that have been discussed at
    length in previous threads on this list. Please search the archives to read up
    those arguments.

    If we really go with module-supported "automatical" compatibility, the
    forward-facing way (deadwood) is much more promising than the legacy one.
  • Eric Schaefer at Apr 21, 2009 at 12:25 pm

    2009/4/21 Jakob Petsovits <jpetso at gmx.at>:
    Or we can have one Drupal Legacy Module that we can suport the modules of
    previous drupal release.
    This is proposed by someone for every Drupal version, it has been tried
    several times, and it has never worked for reasons that have been discussed at
    length in previous threads on this list. Please search the archives to read up
    those arguments.
    Last night, just before I went to sleep, I was thinking if it would be
    good to have CHANGES.txt accompanied by DIDNOTCHANGE.txt to aid
    porting of contrib modules. In some cases people might even be able to
    have xyz.module and xyz.d6.inc as well as xyz.d7.inc. xyz.module would
    contain everthing mentioned in DIDNOTCHANGE.txt. But maybe this is
    silly...

    Eric

Related Discussions

People

Translate

site design / logo © 2022 Grokbase