[development] Consolidating duplicate contrib modules for D7

[Matt Chapman]

On Wed, Dec 9, 2009 at 4:35 PM, Kyle Mathews <mathews.kyle at gmail.com> wrote:
> Somewhat of a joke / serious comment -- but if the KDE development process
> is so good -- why does Gnome exist?

Because of licensing religion, but that's a whole 'nother ball of wax...

> I think switching to a DCVS-type development would be a great benefit but
> it's not going to happen overnight and it's not going to magically make
> every problem go away.

No one claimed to be able to solve EVERY problem. According to the
thread title, the problem being solved is the duplication of modules.
And neither a DCVS nor a commit-access free-for-all will ultimately
solve that. People are going to disagree about what the objectives for
a module should be, and there going to disagree about what constitutes
"technical superiority."

The solution to such roadblocks is social, not technical. Good
old-fashioned human interaction, communication, deference, and mutual
respect. "Blessed are the peacemakers...."

Showing up and demanding that everything change in a workflow that
you've never participated in... that's not going to win friends and
influence people, and it's not going to produce better code or fewer
duplicate modules either.

Of course, I'm biased, because I think duplicate modules are largely a
good thing. Let natural selection take it's course, I say.

One thing is for sure: KDE and Gnome wouldn't be nearly as good as
they are today if they weren't constantly stealing and improving on
ideas from one another.

All the Best,

Matt







>
> On Wed, Dec 9, 2009 at 4:58 PM, Marcel Partap <mpartap at gmx.net> wrote:
>>
>> > > How exactly do you define 'release to the public'? Commiting
>> > > code to a development branch used only by developers? Or
>> > > releasing ready-made quality-inspected module packages?
>> > Almost all projects have development snapshot releases that are
>> > repackaged
>> > every 12 hours.  How much more is "public"?
>> Well in that sense, as good as every line of open source software is
>> 'public'. To me 'release to the public' implies a push operation by the
>> developer - post a release statement with download link in some form.
>>
>> > > > * The maintainer still really should be the only one
>> > > creating release
>> > > > tags,
>> > > Why?
>> > Because the maintainer is "guilty" for the bugs that users experience,
>> > regardless of whether its caused by own code, code by co-maintainers, or
>> > flawed code introduced in patches by contributors.
>> Guilt? What's that thinking supposed to be good for.. Personally i much
>> prefer the concept of responsibility.
>> Just for example: in the more open KDE development paradigm, for mnst
>> participants, committing to the code means also committing to the quality
>> and success of the code. It actually works(tm).
>>
>> > Really, it seems you have not maintained any project at all.
>> That's correct. I wanted to, but didn't yet get around to.
>>
>> > > > and for that matter is the only one that can edit the project
>> > > > page and create the release nodes.
>> > > mmh.. What is the key characteristic of the internet project
>> > > with the hugest growth rate in the last decade? (*)
>> >
>> > You forgot that there is an armada of content moderators in your
>> > scenario.
>> > This armada does not exist, especially not regarding the skill-level.
>> So how do we loose qualified drupal developers once we take out the
>> only-maintainer-writable? And if we don't, what is the issue here.
>>
>> > That's why we have modules, and that's why we promote a proper
>> > separation
>> > between APIs.  That's why we have module dependencies.  There is no one
>> > who
>> > understands all.  But we also don't need someone like that, because it's
>> > sufficient to understand and focus on a particular sub-system or module.
>> How is anyone forced to come up with greater code insight by merely
>> removing write restrictions on the repository?
>>
>> > > > Note that core is the extreme of this, with massive
>> > > > interdependence and 2 committers.
>> > > Yes, but there are more than two people in the project
>> > > capable of grokking every commit that goes into drupal core.
>> > > These two 'just' mostly do the (highly critical!) job of
>> > > judging code readiness (relying heavily of course on opinions
>> > > voiced on the report thread), plucking the cherries from that
>> > > big colourful issue queue tree ;==)
>> >
>> > Do those other people need to commit?  No.
>> Noone _needs_ to - but certain restrictions on who can are also
>> unnecessary..  It's FREE software, is it not?
>>
>> >
>> >
>> > http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-
>> > workflow
>> IIUC this post is about CORE development, for which i see NO CHANGE
>> NECESSARY. Core development works just fine the way it is.
>> BTW, regarding this core-contrib distinction: i would also count views
>> module to the core area, as it is a vital module but only really understood
>> by very few (so it should be protected from inexperienced eager beavers ;) -
>> and scheduled for inclusion in D8 anyway.
>>
>> > > > * If anything I'd say this would discourage people from
>> > > > contributing a
>> > > > module, since other people breaking their code is now a
>> > > > hassle they have to deal with.
>> > > Breaking *whose* code? Is this still free software - or just
>> > > freeware hosted on a common platform?
>> > Breaking the code that users want to use.
>> In a development branch? How awful. None of the other FOSS projects do
>> that.. unstable branches are just named this way to scare people away, not
>> because the code is actually unstable..
>> ???
>> Release versions should definitely be stable and consistent - but for
>> experimental branches, code breakage is to be expected. Just like with
>> everything that has 6.x-dev in it.
>> You didn't actually respond to my main argument btw: the code is ours _as
>> a community_, not the private property of the maintainers - else it would
>> just be freeware, not free software.
>>
>>
>> > > > If the maintainer is not doing their job, there is a process
>> > > > for replacing them.
>> > > Bureaucreacy (how tf is this spelled **g) to solve problems
>> > > that wouldn't exist without it, we need more of it.
>> > Why would you want to contribute to a project, if you can't establish a
>> > trust-relationship to the project maintainer?
>> Because i actually and exclusively care about the technical superiority of
>> the code?
>> > Because, if you can establish one, there's little that hinders you from
>> > becoming a co-maintainer, or have your patches committed quickly.
>> Yes of course. What if it _does not_ work this way. Bugger.
>>
>> > Again, we want to encourage contribution and collaboration.  Not
>> > discourage it.
>> How am i proposing to discourage that, quite the contrary..
>> wow this is getting tedious. I really hoped for some more support, but it
>> seems there is only fear from current maintainers that something will be
>> taken away from them. We will probably have the same duplicate modules
>> problem with D7 as with D6, instead of stemming the united effort of
>> consolidating and merging the functionality of thousands of modules into a
>> couple of frameworks and some hundred submodules.
>>
>> regards,
>> marcel.
>> --
>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
>