Please understand that my intention is not to start a flame war or a blame fest, but just to offer a constructive suggestion. As a non-technical user, I am constantly stumped (and I believe I am not alone) by two things I consider as the most serious usability issues on drupal.org:
1.) Tagging the tar balls of contrib modules by their original release date instead of the last update
2.) Requiring to manually apply patches
As far as 1 is concerned, one or two authors go out of the way to help newbies avoid confusion by mentioning the date of the latest release. Acidfree, for instance, has the following message on its project page:
Attention — last packaged 09 Nov 2005 05:10:00
The listed 'release date' below is a little off. The tarballs below were really repackaged on the above date/time despite the link text below.
But, really, drupal.org should be doing this automatically. Is it so difficult to do this?
As for 2 above, is it again difficult to provide the patched module for download? I know that issues are sometimes reopened even after a code review has been done, but the taxonomy patch (there are at least four forum postings right now about this issue) is a good example of an instance where the module has not been patched even months after it was accepted.
Ideally, 1 and 2 above should work in tandem so that when a module (core or contrib) is patched, it automatically makes it to the tar ball without requiring users to manually patch them. I suspect it happens for core modules (gets incorporated into the drupal download perhaps?) but not for contrib.
Please feel free to educate me if my understanding is incomplete.
Comments
Yeah, those are the ones
#1 annoys me no end. I have to either go through the CVS log or go ahead and download the tarball so I can see the file dates inside it.
#2 isn't as much of an inconvenience for me personally, but I know it is for a lot of people. Here is a good example:
http://drupal.org/node/22124
For my part, I have started to make a practice of uploading a patched version of a file along with the patch.
Search
What gets me is the search, unlesss (hopefully) there is some info somewhere I've missed, you can't search for phrases. For example on google putting "search term" in will search for the term instead of items which contain either word. This is really useful when searching for error messages etc... I've been getting around this by using google to search drupal.org with:
site:drupal.org "search term"
but this can bring up older documents above newer ones....
sincerely hoping someone knows a way of doing it with the native search :)
I'll take yet another shot at it.
1) someone needs to provide a patch for project module to do this. Someone not to busy or overwelmed already needs to donate their spare time and contribute this work to Drupal.org. Someone needs to do actual work and contribute. We don't have enough volunteer people helping as it is. Constantly posting in multiple forum posts the same thing over and over isn't work.
You are in luck, someone is updating it for 4.7. It's not ready yet but anyone could have. Anyone. Dries asked for volunteers to fix this on drupal-devel mail list, and the infrastrucutre support lists. It got added to the to do list. Anyone interested could have submitted a patch for this at any time. No one stepped up to do so until very recently.
2) you misunderstand the issue. Drupal core once feature frozen is feature frozen. Period. No new functionality will be added. Sometimes patches do not get accepted into core for a variety of reasons. They have a negative impact on performace, they serve the needs of a few, they are porrly coded, they lack support, there are competing approaches that are extrememly different, it wasn't ready when 4.6.0 was released. Whatever, feel free to join the development mail list to learn more and track these trends.
Here are some very detailed step-by-step instructions on how to patch a file in Windows.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Thanks, Sepeck.
Thanks, Sepeck.
Great to know that 1) is being fixed. Apparently chx raised an issue for this too way back.
Regarding 2), I suspected that this was the reason- the patch actually patched a core module. Sound reason, it seems, especially when the core is frozen for a version.
But, how about contrib modules that don't patch a core module? Do you think drupal could make it easier for newbies by providing the patched module instead of the patch itself?
I know that even for contrib modules, there is a time lag between patches being made and the maintainer accepting them after review. I suppose the patches make it into the tar ball only after the issue is closed/fixed, which is also sensible.
But, could drupal.org consider providing a mechanism for the maintainers to automatically provide (without waiting for the tar ball packaging to happen) the patched module? There could be a clear disclaimer that the patch/code should be used at the user's risk, issue may be reopened etc., etc. This would help people who find it technically challenging about patching or can't patch on their server. It would be upto them how they handle issue arising out of their patched module.
Patches are for developers
I keep saying this, and I'm going to say it again (although it may sound harsh). Any non-developer should use patches *at their own risk*. Patches are the way that developers who are not maintainers contribute fixes back to contrib and core modules.
Once the maintainer of a contrib module has reviewed a patch and applied it, it means it works with the module.
Yes, some patches work perfectly. Some don't or have issues why they are not applied.
If you want everything to keep working perfectly, don't apply patches. If you want advanced functionality, then either ask the maintainer (nicely, or pay them, or learn to do it yourself) to update the main module.
In other words, we would likely be having MORE unstable code (and more unhappy users) if we had this automated process.
I have to disagree that
I have to disagree that patches are for developers, not end users, especially when the patches actually make the contrib modules work as they should/add useful functionality. Taxonomy_access is an example of a contrib module that only works properly if the patch is applied (although it patches a core module, fortunately or unfortunately).
Sure, I could ask the maintainers nicely, but they may or may not respond. Of course, I would understand that since they are doing the rest of us a service by providing the module in the first place. And/or, some may respond while some don't.
This is where an automated process would help. It gives the module maintainer an incentive to be friendlier for newbies without getting dozens of requests to provide the patched module.
I am afraid I am unconvinced by the opinion that this would add more unstable code. Anyone who uses contrib modules understands that they are experimenting with code of varying quality. After all, that's the reason for the disclaimer on drupal.org. All I am looking for is an extra, auto-generated link to the module with the latest patches incorporated.
I don't want to come across as stubborn or unwilling to learn (css and php are on my list to understand drupal better) or worse, as someone who lives on the labour of others. But, at this point in time, as a non-technical user, this is my experience with drupal.
I also know that things may not be so easy to implement as I have suggested, but there must at least be room for discussion. If the developers/key decision makers think that this issue is basically a closed one without any further room/need for discussion or feedback from users, I will stop flogging a dead horse:-)
Closed
It's closed until someone comes up with the necessary scripts to
1) extend project module
2) automate this as a process on the command line
3) convinces the one or two people that actually have command line access to Drupal.org to install, setup, and maintain this
In my opinion, dead horse. In the case of patching core, especially, forget it -- Gerhard (for example) provided patched versions of core modules, so really, an easier root is to ask maintainers on a case by case basis to make this available (sandbox, part of contrib module download, etc.).
Hope that helps explain.
sepeck,
sepeck,
True... and the submitted patch would probably have joined the hundreds (?) of other contributed patches that have not been applied. Not only are people too busy to develop the code, it seems that they are also too busy to commit many of the user-contributed patches. I guess that's life.
And regarding taxonomy_access, the great news is that in HEAD, it is no longer necessary to patch taxonomy.module. :-)
-Steve
Flogging the dead horse one last time
Hmmm... So, the patch to taxonomy module was good enough to make it (will probably make it) to core for 4.7, if I correctly understand what you are saying.
Where does this leave 4.6 users who can get the same functionality only by patching core taxonomy? How would this affect them when they want to upgrade to 4.7?
No, that's not the reason.
No, that's not the reason. There is a new hook (hook_db_rewrite_sql) in 4.7 from what I understand. (The patch to taxonomy.module for 4.6.3 does not add this hook.) See comment #21 at http://drupal.org/node/34072 (which was a response to your comment #20).
I don't know enough about the way taxonomy_access works to answer the question about upgrading. That would be a good question for keve.
Permissions used to have a
Permissions used to have a high sql query cost per page generation. I think that the new forms api changed how some of this isdone and significantly reduced the cost.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
there are reasons many of
there are reasons many of the patches have not been applied. Some have not been reviewed by other people. Some have not been promoted. Some have not had the submitters advocating or participating or selling there idea to others. And some were a bad idea. I have seen patches that Dries, Steven, killes o rothers reviewed and commented on (patch needs some clean up) and the submittor never bothered to clean up and resubmit their patch....
Sign up for the devel list, track cvs, test and review patches, participate. We need active bodies to participate effectively.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide