Re: [development] Consolidating duplicate contrib modules for D7
[...] 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.
Differences occur because - development happened in a similar time frame. - developers do not play well with each other. - developer B has contempt for developer A's code - and is not courteous in discussions of said codes weakness so does their own project. - modules seem the same but use wildly differing methods to achieve their results.
The problem with the 'have the doc team do it' pretends we have assigned people that will magically carry this out. - They will install various modules on clean test sites. - They will have use cases which will allow the evaluation of the modules in questions - They assume the module contributor in question is responsive and that duplication is the result of 'just happened' instead of hostility between developers. - The modules are actually similar enough in function to be accurately compared. - Users will magically find the module comparison page and it will be up to date.
Not really going to happen.
The best long term suggestion is to have the maintainers clearly document any differences on their project page (preferably the ones who are second should do this by default). People (devs) who have a need for a module and had to evaluate could submit an issue with a request to have an updated 'difference' description added. Suggested sample text would probably help. A module maintainer is not necessarily willing to go download a similar module if theirs already fills their needs.
The ones that are not used die out as tracked on the usage page.
I would suggest a linked article on how to evaluate a project for use (and suggest how to get description updates) linked to the top of the Projects page description would be more useful.
sepeck
On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich@bellsouth.net> wrote:
Shai Gluskin wrote:
Asking the docs team to write module comparison pieces is a good thing too
NO!!! The comparison pieces should be written by the module developers or one of their advanced users.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
On Mon, Dec 7, 2009 at 10:12 PM, Marcel Partap <mpartap@gmx.net> wrote:
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.
When I first started working on Drupal back in the 4.6 days that's exactly how CVS worked, but we explicitly changed it so that each project has a list of approved maintainers. I went back to try to find the point on the list where this was discussed but didn't have much time. I just wanted to let you know that this was tried and found wanting. andrew
Huge -1 to free-for-all commits in contrib. If you want to contribute code to a module, do it by providing a patch in the issue queue. The reasons for this are legion: * The code needs really needs to go through more than one person before it is released to the public. The issue queue is the appropriate way to handle that. * The maintainer still really should be the only one creating release tags, and for that matter is the only one that can edit the project page and create the release nodes. * Sometimes a change can be great on the surface but have horrible consequences. The person who is most likely to know this is the maintainer, because they have the most experience with that code. Note that core is the extreme of this, with massive interdependence and 2 committers. * A corollary to the above: the ability to commit is clearly not a requirement to contribute, which is clearly evident in the number of core contributors. * 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. A broken patch file in an issue is neither stressful nor urgent. * This change doesn't solve any real problem (especially eliminating forks). If the maintainer is not doing their job, there is a process for replacing them. If that process needs work then fine, but it at least mostly works when it is used. - Ken Winters On Dec 7, 2009, at 10:12 PM, Marcel Partap wrote:
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!
I was going to lead this thread die. We had this back in ~2006. It was kind of crazy. I don't think it makes sense to go back to it. Wait - no, you're right.. The universe is static. Change is impossible, thus reconsidering established practices leads nowhere.
If someone is interested in following this practice for their own module they can do so ..how does this improve the issue of 'maintainers' not efficiently cooperating? Where is the incentive to combat feature duplication?
simply add anyone to the list of maintainers that asks for it. Wow, that really sounds so much more like a feasible, well thought through strategic plan... Heck what if someone is qualified to _hack_ the code but - not qualified to (co-)'maintain' a module?
But let's not make a sitewide change without some proof that it works well on a few specific projects first. Well obviously, KDE doesn't count as an example here - code complexity is drastically lower, little structural fluctuations and it has very few active participants. Not comparable to drupal contrib where a set of independent, highly complicated algorithms has to be professionally maintained by a vast pool of specialists. And if the KDE way works well for KDE, this implies nothing for drupal contrib. The fundamental requirements are just too different. Right?
My personal sense is that when I see more than 3-4 maintainers on a project I get concerned that it is probably not architecturally consistent and likely poorly maintained (the "everyone thought it should be done, anyone can do it, nobody did it" problem). This is not about raising the numbers of module maintainers, but about abolishing their sovereignty over code - is this FREE software, or just open? Why do we put code under the GPL in the first place? Doing things in a platform framework style sense can be facilitated or blocked by source/development management structures. With current policy, we obviously have not facilitated it enough. The Drupal project has grown its very own style regarding code change process, distinct from the development models of other projcts of comparable size and complexity like f.e. the Linux Kernel, WiNE, Xorg , KDE.. You are totally satisfied with it, fine - my opinion is there's room to improve. Anything non-perfect can be done better! :]
The Wikipedia entry on http://en.wikipedia.org/wiki/Shared_space doesn't seem exactly applicable (am I a pedestrian, bicyclist, or urban planner in the analogy?) whatever you so choose ;-)
but another apt way to describe an environment where anyone can do whatever they please is a "commons" as in http://en.wikipedia.org/wiki/Tragedy_of_the_commons <cite> Tragedy of the commons A B-class article from Wikipedia, the free encyclopedia The tragedy of the commons refers to a dilemma described in an influential article by that name written by Garrett Hardin and first published in the journal Science in 1968.[1] The article describes a situation in which multiple individuals, acting independently, and solely and rationally consulting their own self-interest, will ultimately deplete a shared limited resource even when it is clear that it is not in anyone's long-term interest for this to happen.[2] </cite> even with good intent i see no way how this could apply to the drupal open source project. Code is one of the very few things that grows in size if you share it ;)
PS I ignored the whole "move away from cvs" part of this discussion because that is well discussed and well documented at http://groups.drupal.org/node/8102 - needs more testers and more code first. Alright, everybody and his mother is busy doing other stuff. Why don't we put up a huge call for action on the drupal.org frontpage? Theoretically, the pure migration of the repositories should not take more than a few hours, right? If we as the drupal collective don't put it upfront the priority list, obviously it will be completed once hell is (at least half) frozen X-P
regards, marcel -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02
Alright, everybody and his mother is busy doing other stuff. Why don't we put up a huge call for action on the drupal.org frontpage? Theoretically, the pure migration of the repositories should not take more than a few hours, right? If we as the drupal collective don't put it upfront the priority list, obviously it will be completed once hell is (at least half) frozen X-P regards, marcel -- It's never about the cost of moving the data. It is always about the cost of changing the code that uses the data.
Wait - no, you're right.. The universe is static. Change is impossible, thus reconsidering established practices leads nowhere.
No, it means that a project's organization grew with its own growth.
If someone is interested in following this practice for their own module they can do so ..how does this improve the issue of 'maintainers' not efficiently cooperating? Where is the incentive to combat feature duplication?
It means that every maintainer is free to let any contributor help out and freely commit to a project, in case the contributor has CVS access. This is a very common practice on drupal.org already, so I really have to wonder how much you are involved in contrib development.
simply add anyone to the list of maintainers that asks for it. Wow, that really sounds so much more like a feasible, well thought through strategic plan... Heck what if someone is qualified to _hack_ the code but - not qualified to (co-)'maintain' a module?
How can you maintain hacks? You cannot. And you won't ever be able to maintain it if anyone can commit arbitrary hacks to your project. After all, you are maintaining a project so that other users can use it without experiencing bugs. If you are able to hack code but not able to maintain, then file a patch. If you are not able to maintain, then don't expect your code to work for others.
My personal sense is that when I see more than 3-4 maintainers on a project I get concerned that it is probably not architecturally consistent and likely poorly maintained (the "everyone thought it should be done, anyone can do it, nobody did it" problem). This is not about raising the numbers of module maintainers, but about abolishing their sovereignty over code - is this FREE software, or just open? Why do we put code under the GPL in the first place?
You are free to file a patch, if you can code. If you can maintain, then you are free to apply as co-maintainer. If you can maintain and you think that someone else cannot, then you are free to request to take over project ownership. If you can maintain and you think that someone else cannot, and taking over a project is not possible, then you are free to create a new project, given that you know Drupal's APIs (and are therefore granted CVS access). Thus, you have plenty of freedom. The Drupal project and community builds on collaboration to innovate and build a better product for users. If your code is not for users, then why do you want to hack something and contribute in the first place?
but another apt way to describe an environment where anyone can do whatever they please is a "commons" as in http://en.wikipedia.org/wiki/Tragedy_of_the_commons even with good intent i see no way how this could apply to the drupal open source project. Code is one of the very few things that grows in size if you share it ;)
Then you obviously didn't see Drupal modules that are not properly maintained and contain countless of hacks. Are those useful for anyone? No.
Alright, everybody and his mother is busy doing other stuff. Why don't we put up a huge call for action on the drupal.org frontpage? Theoretically, the pure migration of the repositories should not take more than a few hours, right? If we as the drupal collective don't put it upfront the priority list, obviously it will be completed once hell is (at least half) frozen X-P
This, next to your other replies, makes me believe that you neither want to contribute nor collaborate. Without contribution, it won't ever happen. You may want to re-consider your position. Or not.
participants (5)
-
andrew morton -
Daniel F. Kudwien -
Ken Winters -
Marcel Partap -
Walt Daniels