Re: [development] Consolidating duplicate contrib modules for D7
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: Yes, that's the accepted standard approach, and it works well ~90% of the time. But that still means there's a _huge_ number of cases where it _does not work very well_.
* The code needs really needs to go through more than one person before it is released to the public. 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?
The issue queue is the appropriate way to handle that. Well yes, it is one feasible way to handle it.
* The maintainer still really should be the only one creating release tags, Why? 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? (*)
* Sometimes a change can be great on the surface but have horrible consequences. ..ack, had that before ;)
The person who is most likely to know this is the maintainer, because they have the most experience with that code. Actually - that's bad for core CMS functionality like messaging, file management, payment, workflow, isn't it? Is it not preferable to have a bigger group of people be involved and familiar to such implementations?
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 ;==)
* 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?
* This change doesn't solve any real problem (especially eliminating forks). Not by itself, of course. We shouldn't do software like some politicians do geopolitics (i.e. 'nicht zuende gedacht' ;)
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.
If that process needs work then fine, but it at least mostly works when it is used. Might be or not, it is a barrier, putting people off from contributing. And one's persistence to have his work published somewhere on drupal.org might not be correlated to that work's quality (means good sh1t might - instead of automagically being supported - lay stale = double plus bad)..
regards, marcel. * hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
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"?
* 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. Really, it seems you have not maintained any project at all.
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. This is not about maintaining documentation.
The person who is most likely to know this is the maintainer, because they have the most experience with that code. Actually - that's bad for core CMS functionality like messaging, file management, payment, workflow, isn't it? Is it not preferable to have a bigger group of people be involved and familiar to such implementations?
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.
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. http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development- workflow
* 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.
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, if you can establish one, there's little that hinders you from becoming a co-maintainer, or have your patches committed quickly. Again, we want to encourage contribution and collaboration. Not discourage it. sun
On Dec 8, 2009, at 9:41 PM, Daniel F. Kudwien 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"?
Exposed to the general public rather than just developers, that is. Everyone can download any branch of the code regardless, but the recommended releases need to be more reliable. When someone creates a release node, everyone with update status enabled and an older version of the module will know about it, and the implication is that they should update. Ill- advised release creation has caused a lot of grief to a lot of people in the past, so this process should not be taken lightly. Breaking the devel branch is one thing, but breaking the "stable" branch and broadcasting is far more disruptive and hardly inspires confidence in the module / CMS. - Ken Winters
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
Somewhat of a joke / serious comment -- but if the KDE development process is so good -- why does Gnome exist? I think some of your ideas Marcel have merit but you're ignoring that a) as with everything, there's no silver bullet and b) you're overestimating the benefit of your ideas and underestimating the cost in developer time to implement the changes and in education to retrain everyone on how drupal development happens. 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. --Kyle Mathews kyle.mathews2000.com/blog http://twitter.com/kylemathews On Wed, Dec 9, 2009 at 4:58 PM, Marcel Partap <mpartap@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
On Wed, Dec 9, 2009 at 4:35 PM, Kyle Mathews <mathews.kyle@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@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
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." That might well be. But the most important thing to avoid functionality overlap is to engineer frameworks that are capable of handling as many different, probably conflicting, use cases that could be come up with. Then code not agreed upon can be refactored into submodules for the framework, instead of reimplementing functionality multiple times in conflicting ways.
The solution to such roadblocks is social, not technical. Good old-fashioned human interaction, communication, deference, and mutual respect. "Blessed are the peacemakers...." The solution is both, of course. Technical utilities that support the social workflow ;) The thing is, abolishing individual persons' OWNERSHIP on code in D7 contrib does away with possible prevention of code improvements due to social factors. By itself, it does not solve any problem of course, even giving room to a new one: people at will committing changes NOT coordinated with one another. To prevent that, important thing is to start implementing the potential frameworks ASAP and make sure they can properly be expanded by extensions/submodules. This process will naturally result in a voluntary group of developers doing the job of maintenance.
Showing up and demanding that everything change in a workflow that you've never participated in... What does that mean? I have provided patches to at least a dozen modules, and core.
that's not going to win friends and influence people, and it's not going to produce better code or fewer duplicate modules either. To put it bluntly, i am not trying to make friends, i am trying to stir up some discussion about the development process i am taking part in.
Of course, I'm biased, because I think duplicate modules are largely a good thing. Let natural selection take it's course, I say. For Drupal 6, no disagreement. Everybody and his dog tried his variation of how to implement basic functionality, and it has led to an impressive amount of creative programming work of (partly) high quality. But duplication is bad in several ways which already have been mentioned multiple times before. Frameworks with beyond-dispute general structure are a good replacement for obvious reasons, so a development process which facilitates that is an improvement.
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. Comparing <10KLOC modules with overlapping functionality with two rivaling desktop environments is stretching scales a bit. And with nested frameworks (payment framework -> paypal framework -> submodules) there's still room for competing implementations - the difference it makes is at which API level differences are visible. paypal_framework_1 and paypal_framework_2 might differ in internals and have incompatible submodules, but should both provide same functionality/interface to the payment framework. At the moment, there's no common payment framework, none for shopping carts, none for a variety of other applications, resulting in competing implementations in D6 contrib.
regards, marcel. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
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.
That's the point. You are talking about consolidation and merging without considering that any approach on consolidation requires to join forces with others. That means to communicate, to talk, and to share vision. And after doing so, it means to code, to review, to find compromises, and finally to commit. This is how innovation works. If you'd want to express this in numbers, then 99% is collaboration and contribution, and only 1% (or even only a fragment of that) is committing. If we want to decrease duplication, then we need to improve the communication. sun
The bottom line is that with the exception of abandoned modules, consolidation needs to be initiated by the module creators and maintainers. The same is true, for the most part, of module comparison. Experience has shown that these work well and virtually every other approach fails. Cary On Wed, Dec 9, 2009 at 4:42 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
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.
That's the point. You are talking about consolidation and merging without considering that any approach on consolidation requires to join forces with others. That means to communicate, to talk, and to share vision. And after doing so, it means to code, to review, to find compromises, and finally to commit. This is how innovation works.
If you'd want to express this in numbers, then 99% is collaboration and contribution, and only 1% (or even only a fragment of that) is committing.
If we want to decrease duplication, then we need to improve the communication.
sun
-- Cary Gordon The Cherry Hill Company http://chillco.com
The bottom line is that with the exception of abandoned modules, consolidation needs to be initiated by the module creators and maintainers. The same is true, for the most part, of module comparison. Yes, and that is the flaw of the current, maintainer-centric workflow. It depends on maintainers being able to be good maintainers. This will never be true for all people coding drupal.
Experience has shown that these work well Everything imperfect can be improved upon. Explicitly including things that work well.
and virtually every other approach fails. How has that been proven? It's hard to prove that something cannot be done, even if insurmountable obstacles seem to exist. Take space flight for example ;)
regards, marcel. -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02
That's the point. You are talking about consolidation and merging without considering that any approach on consolidation requires to join forces with others. That means to communicate, to talk, and to share vision. And after doing so, it means to code, to review, to find compromises, and finally to commit. This is how innovation works. If you'd want to express this in numbers, then 99% is collaboration and contribution, and only 1% (or even only a fragment of that) is committing. If we want to decrease duplication, then we need to improve the communication. Yes, agree to all. And imho, NOW (i.e. BEFORE a D7 final) is a good time to adapt such a more cooperative contrib development mode. Once all the competing modules have D7 versions, the problem is just prolonged for about two years until D8. And at the same time, some tools part of the workflow could be improved, too. Migration to GIT (only the D7 repository!), testing bots, etc. Of course it's a lot of work. Getting it done requires the commitment to do it. Again: why don't we put a 'Help D7 migrate to a DCVS call for action' and 'D7 contrib frameworks hackfest invitation' up on the front page for starters. regards, marcel. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Yes, agree to all. And imho, NOW (i.e. BEFORE a D7 final) is a good time to adapt such a more cooperative contrib development mode. Once all the competing modules have D7 versions, the problem is just prolonged for about two years until D8. And at the same time, some tools part of the workflow could be improved, too. Migration to GIT (only the D7 repository!), testing bots, etc. Of course it's a lot of work. Getting it done requires the commitment to do it.
Change happens by contribution. It seems you are highly interested. So why don't you pick your most annoying candidates, do and publish a module comparison, contact the maintainers and get them talking to each other to get the ball rolling? sun
On Tue, Dec 8, 2009 at 9:14 PM, Marcel Partap <mpartap@gmx.net> wrote:
* hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier.
I agree with Sun that docs are not really analogous to project code, but even disregarding that, it's worth pointing out that many pages on Wikipedia are locked to editing from the general public in the interest of maintaining a positive experience for the majority of readers. Regards, Ezra Ezra Barnett Gildesgame | http://growingventuresolutions.com | http://ezra-g.com
I agree with Sun that docs are not really analogous to project code, but even disregarding that, it's worth pointing out that many pages on Wikipedia are locked to editing from the general public in the interest of maintaining a positive experience for the majority of readers. Unfortunately i couldn't find definite statistics on the amount of locked pages but i doubt it is more than five percent. And most of these pages are locked because of security implications (some templates, scripts). Adding to that, as already mentioned in my response to sun, even i support not lifting restrictions on some modules of similar importance, like the views module.
regards, marcel. -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02
participants (7)
-
Cary Gordon -
Daniel F. Kudwien -
Ezra B. Gildesgame -
Ken Winters -
Kyle Mathews -
Marcel Partap -
Matt Chapman