[development] New version control policies/system? (was: Consolidating duplicate contrib modules for D7)

[Cameron Eagans]

Ooo, huge +1 to both points (contrib free-for-all, and moving to something
that's not CVS or Subversion). It would be a lot of work to get to that
point, and would likely not be something that could happen for the Drupal 7
release, but it sounds like a fair goal for Drupal 8!
-----
Cameron Eagans
Owner, Black Storms Studios, LLC
http://www.blackstormsstudios.com


On Mon, Dec 7, 2009 at 8:12 PM, Marcel Partap <mpartap at gmx.net> wrote:

> [...]
> Totally agree with your analysis but not with the conclusion that creating
> documentation of duplicate module's differences is a feasible way out.
> Especially, all problems tied to the fact that there's an individual person
> who has sole sovereignty over a certain part of the code - ain't tackled a
> bit. If the maintainer is 'malfunct' (in some way or the other), 'his'
> module is doomed, even though it's licensed as FOSS. Only way of
> circumventing the problem is forking - something the Drupal project really,
> really does not need more of (quite the contrary!).
>
> Instead, IMHO, the responsibility for contrib code development should move
> from indiviual people to the collective, i.e. every svn ... uuhm cvs account
> holder should have commit access to all code. Sounds unmanageable at first
> but seems to work out very well, f.e. with the KDE project. It's kind of
> like the shared space 'urban design concept' (
> http://en.wikipedia.org/wiki/Shared_space) - a lack of strict regulation
> means individuals have to care a lot more about their interaction with other
> participants. This way communication _and cooperation_ actually become
> obligatory to making decisions - consequently a more swarmwork-oriented
> style of interaction evolves. (..and in contrast to real world shared space
> traffic, in the rare cases where this process fails and b$ code changes
> indeed are committed, it's very easy to roll back and rework.)
>
> So imho Drupal contrib repository should be freed from
> only-maintainer-writable-restriction to accessible-for-all-devs. The new way
> of avoiding bogus code commits is not to prohibit developers (who might be
> perfectly qualified for the task at hand) from changing certain code, but by
> giving more clearance to everybody. With more power comes more
> responsibility of course: covert, disagreed code changes are only prevented
> by social mechanisms, not repository access rights.
> To reiterate: this process works perfectly well for KDE: although i have
> only done some tiny commits here and there, my SVN account is not limited!
> Nothing there to prevent me from committing havoc to core kdelibs code
> straight away, right now... Still - it never happens!
>
> Proceeding from there, the pitiful situation of duplicate modules with
> overlapping functionality could be entirely prevented for D7 by
> - identifying with which functionality this has happened in the past
> - collecting ideas for frameworks (such as messaging, search functionality,
>  shopping cart, payment, web questionaires, workflows, file handling - oh
> wait that one's cared for already) or spotting existing ones most fit to do
> the job in D7
> - implement frameworks with focus on modularity, customizability
> - port functionality from existing modules to these new interfaces
> - raise the bar on adding new 'isolated' modules
>
> The switch to D7 is also a good time to introduce these workflow changes,
> because with the major API restructuring it has seen, most modules will have
> to change substantially anyways (and be it just to comply with new coding
> standards) to be in line with HEAD - a good time for converging, tidying up
> and trashing cruft code constructs from contrib.
>
> Earlier this year i already tried to win some support for this idea
> (admittedly a bit differently in form) but for all reasons, failed
> miserably. Bytes are cheap though so SCNR to bring it up again.
>
> BTW, using the drupalfr.org GIT mirror for D7 and the infamious tig CLI
> interface makes the repo really much more friendly to manage - is D7 still
> not the time to move to a 21st century source control system?
>
> regards,
> marcel.
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091208/58b461b6/attachment.html