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

Marcel Partap mpartap at gmx.net
Fri Mar 13 05:12:49 UTC 2009


> There are already few reviewers for core. Don't expect to have
> reviewers for contrib.
Well the idea was to convert all people currently posessing an SVN 
account the reviewing collective, not getting additional reviewers. Am 
i interested in the modules i have submitted codes for? Sure i am. Am 
i interested in the code quality / functionality of all the other 
modules aswell? YES i AM - because they all affect what and how i can 
use Drupal to accomplish stuff.

> It is clearer how core gains from public review.
> It's not that clear how a maintainer may gain from code review.
No more maintainers, just contributors.
> I'm not talking about quality of code... I'm talking about the
> interest of the maintainers.
Well take them out of the equation.
Anyone in fear of leaving his title as 'maintainer of module foo' 
should be soothed by the opportunity that per-module commit statics 
provide for fame.

> Core and contrib are quite different in terms of speed of
> development, purposes, design, coders sub-communities...
>
> People may use drupal infrastructure just if:
> - They're looking for public review
> - They're looking for co-maintainers
> - They're looking for exposure
> - They just feel "generous" and they think someone else may make good
>    use of their code without bothering them
Well my belief is that enforcing a community process on all developers 
for any D7 might be a good thing, strengthening the community and 
resulting in better code. And i highly doubt just out of pride people 
would take their module code elsewhere just because they won't be the 
sole 'owner' in the d.o repository.

> Release early, release often refers to your users... not to everyone.
> If I can't release early and often for *my users* because someone
> else is not going to review my patch, I'm going to move my stuff
> elsewhere.
Having your experimental code reside in a staging repository until the 
code is ready for being unleashed onto thousands of sites is too much 
of a pain to take?

 > If someone is pushing my module in a direction that
> doesn't fit *my users* I'm going to resist to the change.
Veto the change, comment on your reasoning. Is too bad of a way to 
handle it?

> Very frequently the maintainer of a module is the one that keeps
> contributing the module most.
So uhhm that'd make them 'top contributor' instead of 'guy who holds 
the golden key'.

> You're starting from the unproved assumption that for every
> maintainer code review and exposure are a larger benefit than keep
> on being the steering committee of its own project and that drupal
> benefit more from a supposed increase of code quality and reduction
> in duplication than having a prolific competitive community of
> contributors.
Difficult to answer.. in my opinion most of the stuff that even can be 
done with a website is already available in some form or another as D6 
module. Taking all this great innovative stuff in contrib, there's 
really not much stuff left to be desired. A lot of this code can be 
just migrated to D7, continuing as in past drupal version jumps. But 
having almost every thinkable use case already covered would allow us 
to take a different direction: cleaning up, merging and refactoring 
the existing modules, transplanting good code and skipping 
not-so-good. The competition that has been going on up to now already 
has created a huge pile of excellent stuff to pick from. Why not make 
the decision to not take the huge pile, but only the best part of it?
Also, frameworks for basic shared functionality should be designed in 
a way that makes them as expandable and REPLACEABLE as possible, i.e. 
clear interface definitions.
Having competition on that basic fundamental level of groundwork 
services (the prime examples again: notifications, web forms) in a 
project of this maturity level at least to me does not seem to be a 
good idea- because it REALLY REALLY isn't. Other people have stated 
why they support that statement.

> Otherwise you're heading to balkanization of contrib repositories.
Really have my doubts people would like to use modules that are not 
from the official d.o repository. Having all code committed only after 
quality reviews have been applied is more of an USP than anything other!

> While I agree that natural selection may be suboptimal and
> rationally planning and channelling efforts may achieve better
> results in a shorter time[1]... natural selection is self testing
> and it already happens with no extra effort.
Yeah so at this point we could look back at the pile of code it 
created and transplant ONLY THE GOOD PARTS of it into the D7 repository.

> Other theories have to be proved and require efforts to be put in
> practice.
Well apparently

> Now... if you've something better to substitute to natural selection
> and you can prove it is better, that's just the starting point as
> Laura Scott pointed out at the end of her post.
How can i prove that on my own? From my level of education on the 
object of process and quality management aswell as open source 
communities, i think it does.

> If no one feels your hypothesis is worth a test, provide your own
> test.
I'd gladly do everything i proposed myself (if only to show off) but 
time is the limiting factor again. Maybe i should have used the time 
debating here with people who misunderstand what i am trying to 
communicate to come up with a design draft for a D7 notification API, duh.

> Then maybe you'll reach the point where "d(em)ocracy" and evolution
> sucks and you may start complaining ;)
There's always this tiny fraction of people warning about shit tending 
towards the fan long before shit gets there. Not only the current 
climate change situation is a good example for that. Why is it that 
the majority can never be convinced to listen to such criticism BEFORE 
TSHTF?


> [1] let's turn this into a flamewar about XP vs. waterfall vs.
> academia vs. corporate vs. opensource vs. emacs as well ;)
ok let's try this: xp is to opensource as emacs is to .. ah well no 
let's not.
marcel, tired of a debate not representing his proposal.

-- 
  "Obstacles are those frightful things you see when you take
   your eyes off your goal."         -- Henry Ford (1863-1947)

   Change the world! Vote: http://hfopi.org/vote-future


More information about the development mailing list