CVS edit link for stephen.colson
My company has two modules that we would like to submit back to the Drupal community. One is a user interface/jquery module that makes it significantly more efficient to manage pages with large amounts of checkboxes. In it's current incarnation, this module is specifically geared towards the permissions page.The second, and much larger project, that we would like to contribute is an interface layer for using MogileFS (http://www.danga.com/mogilefs/) as a high-performance back-end file storage mechanism to help solve the problems with file synchronization introduced in multi-server architectures. Currently, the only mechanisms are to constantly rsync (or unison) or to use some shared filesystem like Coda, NFS, etc. The former option is only suitable in environments that have largely static file serving needs and the latter demands root access and the know-how to configure *nix systems in a high performance system and has the additional detriment that it is harder to do across multiple data centers. MogileFS fixes the problem by being a redundant mechanism that is massively scalable for decreasing complexity while also solving the problems that exist with an rsync- or unison-backed stack.
At this time, we are applying based off of the first module alone. The second module is still in development internally and will be coming later.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | permisionDragCheck.zip | 3.77 KB | steve.colson |
| #14 | permisionDragCheck.zip | 4.47 KB | steve.colson |
| #1 | permisionDragCheck.zip | 4.77 KB | steve.colson |
Comments
Comment #1
steve.colson commentedAdding zip of first module.
Comment #2
avpadernoFiles available from third-party sites should not be included in Drupal.org CVS.
Comment #3
steve.colson commentedThe only other published version of the checkboxAreaSelect.js file is currently licensed as GPLv3. My developer who wrote this and originally licensed it has told us we can fork it and re-license as GPLv2. At the moment, the only difference is availability under a new license, but any new features are only being considered for the included JS under the GPLv2 license.
To the best of my knowledge, none of the rest of the files are available from any other third-party site in any official capacity.
Comment #4
avpadernoCheckbox Area Select: http://plugins.jquery.com/node/7627.
Comment #5
steve.colson commentedkiamlaluno, what I wrote is in regards to the link you just pasted in. Please let me know how this doesn't address the concern.
Thanks
Comment #6
avpadernoFiles available from third-party should not be committed on Drupal.org, indipendently from the license of those files.
Comment #7
steve.colson commentedkiamlaluno,
I understand what you have written. As stated above, this is a forked and relicensed file. Any future changes to this file are only being made to the forked GPLv2 version.
Aside from potentially re-naming the file, I'm not sure what else I can do to make it clear that these are now considered two separate projects with two separate licenses that happened to start in the same original codebase... If you have any specific suggestions, I'd be happy to read them.
Comment #8
avpadernoChanging the license doesn't change the code, and what I reported is still valid.
Using a changed version of a plugin, and committing it in Drupal.org is not the correct way to proceed, IMO. If that would be allowed, I could change some lines of jQuery UI, and commit it in CVS.
In the Usage policy is then clearly stated that:
A jQuery plugin created by third-party authors falls into that category.
Comment #9
steve.colson commentedI can understand what you wrote, but I would point out that the jQuery plugin in question was created by my employee for my company, and therefor I have the authority to say it is being moved.
That said, I am not aware of any mechanism to de-publish the old version (GPLv3) in order to make this more clear. As stated before, both Harry (my employee who wrote the js file) and my company are looking to commit changes only to the GPLv2 version that is bundled with the included zip file.
Is there not an exception (or clarification) to the quoted rule (that I am already quite familiar with) for projects that are being moved to within a soon-to-be-published Drupal module? If you insist that there is no way to move an external project in to a Drupal module when one is the proper content owner, then I will strip the JS file out as requested. If this is this case then this part of the usage policy is, quite frankly, broken.
Comment #10
steve.colson commentedBumping this after the US Holiday. Any response to #9?
Comment #11
avpadernoWhat I reported is clear; the reference is to non-Drupal code, independently from who created the code.
If that code is already available from third-party sites, then that is a reason more to not include it in CVS.
Comment #12
gdoteof commentedStephen I think the point is that the only code that goes in the Drupal repository is drupal code, period. It's really not a matter of where it was created or who else has it.
It seems the correct way to move forward would be to either a) include Drupal specific .js file with your module, or include only the .info and .module files in the module and point to where the library can be gotten offsite.
Comment #13
avpadernogdoteof correctly understood the point, and the possible solutions.
I am marking this report as .
Comment #14
steve.colson commentedThe whole point of my comments is that this external project was becoming a Drupal project instead, but this is just plain silly to be arguing. Obviously the comment system isn't wide enough bandwidth (so to speak) to have a proper dialog of this nature. Of course, maybe I am just not understanding how the responses have addressed my points, but that is neither here nor there. I'll respect the determination from both of you and am resubmitting this with a placeholder js file and a readme file, both pointing to the old project which I guess won't be abandoned since it needs hosted somewhere...
New files attached.
Comment #15
gdoteof commentedStephen, was the js file written originally for drupal or was it re-purposed?
Comment #16
steve.colson commentedGeoff,
The js file was written originally for Drupal. We specifically wanted to make the admin/user/permission page much more manageable.
Comment #17
avpadernoThe original file has been reported to be licensed under GPL v3, which is not a license you would use for a file that you are going to commit on Drupal.org CVS; actually, you would not have chosen any licenses, as you are only allowed to use the same license used by Drupal.
What is reported about third-party libraries is also clear: don't commit on Drupal.org CVS files available from third-party sites; if I take a file licensed under GPL v3, and I re-license it under GPL v2, I don't change the code contained in the file, which is the same code contained in the file licensed under GPL v3.
Comment #18
steve.colson commentedkiamlaluno,
The way I took gdoteof's question was with regards to our original intention for what the JS file was to be used. It didn't start out as targeting a d.o project, but it did start out with the intention of being used for Drupal.
In any event, I'm not sure why this is still an issue. Please see post #14 for the new attachment which addressed your previous comments. Did I miss something in that attachment, or is it RTBC?
Comment #19
avpadernoThe file I was referring to is still present.
Comment #20
steve.colson commentedPlease look at the contents of the file. I have stripped out everything and placed a comment that directs the installer where the correct JS file can be found as well as putting the same information in the README.txt file.
Please let me know if there are any further changes that should be made.
Comment #21
avpadernoI saw the file content; still, the file must be removed.
Comment #22
steve.colson commentedNew version attached.
Now that this is out of the way, could you please explain why my request for a policy review on this issue was denied? In 3.3 on "3rd party libraries in Drupal CVS" (http://drupal.org/node/422996 ) it states that exceptions can be made if the 3rd party library is no longer maintained. As I had stated from the beginning, the file in question is no longer being maintained in it's current state and it was desired to bring newer version directly in to this project.
Also, please explain why it is not appropriate to use placeholder files for ones that need swapped out.
Your answers to these will help me avoid any future difficulties.
Comment #23
avpadernoWhat you report makes also reference to the fact that is possible or not find a copy of the library. If I would use a jQuery plugin, and it would not possible anymore to download it from any web site, then I can include it with the module; this is not true in this case.
Comment #24
steve.colson commentedNo longer maintained means no longer maintained. That is a separate issue from the old license. When I say that version on the jquery site is no longer maintained, do you not trust that I mean it? Is that the crux of the issue? The issue of things being no longer maintained is completely separate from wether or not you can find an old version of the library somewhere on the web -- there is abandoned code all over internet sites. Or am I just not following your logic?
For placeholders, is there a relevant place in the handbook pages that outlines this issue? What you write makes some sense, but I'd never seen that documented as a required practice, so it would be good to know for the future.
While I am seeking some additional clarification, would it be possible to treat this as RTBC since every issue has been fixed? Regardless of the answers you provide, I won't check any third party file in to cvs without specific authorization to do so.
Comment #25
avpadernoWhen in doubt, check what other modules do; that doesn't mean to look to just one module that does the same thing you think it is right, thought :-). There are many modules that require the users to download something, and they don't use such placeholders.
Comment #26
steve.colson commentedKiamlaluno,
Not to be pushy, but I have not seen any requests for any other changes and this has just been sitting as an open issue. Are there any other changes needing to happen, or can we proceed with creating the CVS account?
Comment #27
steve.colson commentedAnother bump for status
Comment #28
steve.colson commentedIt has now been a month since all requested changes have been made. I understand we are all volunteers here but what is holding this process up?
Comment #29
avpadernoThe module just contains the implementation of
hook_form_alter(), and it has not a settings page. As it is, it is too few to be used in a CVS application. If somebody would need such functionality, he could simply add that code in a custom module for his site.Comment #30
steve.colson commentedSo, I had a long rant asking for this to be re-reviewed by someone else, but in the end, this just isn't worth it to get a module that my local user's group wanted posted up on D.O. I'll just host any of our future modules elsewhere instead.
Comment #31
steve.colson commentedclosing
Comment #32
avpadernoComment #33
avpaderno