| Project: | Drupal.org CVS applications |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
| Issue tags: | module review |
Issue Summary
The module I am submitting is meant to be an enhancement of the Content Copy module that ships with CCK.I reckon there are several "problems" with the Content Copy import.
First, the interface is not very good, because you can misunderstand what it really does.
Second, if the Content Copy module imports just fields, than it should also export just fields, and ask the users for the content type details when they require a new content type to be created to import the fields into it. But it does not. It works exporting and importing a full content type definition, which is an inconsistence.
So, Content Copy actually exports and imports either just the fields or the whole content type. It implicitly depends on your choice. Well, that’s not really the right way to make things work.
Third, and *most important*, we actually have a missing functionality, because we can:
* Create a new content type out of the code;
* Import new fields into an existing content type;
but we can’t
* Update a content type
where "update" means you can take an existing content type and import a new definition into it. This implies adding, updating and removing fields, as well as updating the basic informations about the content type itself, or the fields associations with potential field groups, and so forth.
This is clearly something that Content Copy does not do. That’s why I created Alternate Content Copy.
My module seamlessly integrates with CCK, by just altering the behaviour of the Content Copy module. It does it basically via form_alter, changing the aspect of the drop-down in the "import" form, and replacing the submit handler with an enhanced version of it implemented in my module itself.
On top of all that, the functionalities provided by the Alternate Content Copy module allow to implement CCK content types programmatically, including a very easy and less error prone way to implement content type updates via hook_update_N().
This procedure is fully described here:
http://neminis.org/blog/drupal/programmatic-cck-content-types-updated/
The Alternate Content Copy module is, instead, downloadable from the bottom of this article:
http://neminis.org/blog/drupal/cck-alternative-content-copy/
Thank you all for you attention.
Best regards,
Vincenzo.
Comments
#1
Attaching the module.
#2
#3
As the proposed module is an enhancement of project , why didn't you submit patches, or open feature requests for that project?
As stated in Apply for contributions CVS access:
#4
I was expecting this reply.
Although it doesn't seem so, I did read that passage.
Also, I did submit patches, open feature requests, and so forth. Everything has been declined with detailed yet vague excuses.
The maintainer (I am assuming he is) provided reasons not to accept the submitted patches, but, still, at the end of the day, I did not get any real, valid, motivation. I am just adding a new functionality, after all. The rest would have stayed the same.
Since I believe many people could benefit of this enhancement (I wasn't the first one proposing such a patch), I decided to submit it as separate module, even though I knew that the passage you quoted would have been an obstacle.
I am already maintaining this module and it is publicly available from my website, however I'd rather prefer it to be hosted here on drupal.org, for obvious reasons.
I do understand the point quoted in that passage, but sometimes the attitude of some maintainers really prevent any sort of contribution which slightly disagree with the their mindset. Don't get me wrong, I can kind of understand their position, just I don't see the point to decline patches like mine rather than including them in dev/alpha versions and let the community decide (via testing, criticism, etc.).
One more reason that brought me to submit this module and make it available to as many people as possible.
Thank you and regards,
Vincenzo.
#5
For other people reference, Vincenzo is referring to #634832: Patch to allow content_copy to update existing fields.
IMO, what said from markus_petrux in #634832-16: Patch to allow content_copy to update existing fields is not a vague excuse, but says exactly the reason he is not accepting the patch.
#6
Well, the only thing I can see from markus_pretrux is a general concern. I can't see any formal proof and/or valid technical explanation why my patch could cause any problem. No counter-examples, no real scenarios that proves that to me and shows me the nature of these problems. He's just concerned.
That's not a valid reasons, for me, to decline patches. He also said I should use CCK CRUD API like other modules do. But that's exactly what I do. I just do it in a place he doesn't like.
Regarding publishing this as module, similar modules have been accepted, e.g. CCK_sync. I must say CCK_sync author has been clever enough to do the same thing but "outside the region of concern", i.e providing the lot in a separate interface and as a separate function, rather than providing an enhancement.
With my module, instead, I am just putting this feature in the place it is supposed to be.
Now, of course, I expect being told to speak with CCK_sync author in order find an integration between the two solutions, as my module looks like it is a duplicate.
#7
The maintainer of CCK_sync has gotten his CVS application approved before the actual system was used. At that time, there was not a code review; even if there would have used a code review, it is possible that he applied for a CVS account with another module, and then created CCK_field.
#8
Wait a minute, you are telling me that once I get the CVS account, I can create any "project" I want?
I hope I am missing something, because otherwise this whole process does not make any sense.
#9
@Vincenzo: Look at reports you see here, and check how many fixed applications you find for each user.
It could be that in the future users will not allowed to create a project themselves, but they will need to ask somebody else to create the project node.
This is not the place to debate how a CVS application should be done; that is left to other places.
The conclusion is not exact.
#10
The conclusion is one e one only: the process you guys use is absolutely without logic and far to be "open".
You do not create the preconditions for pluralism and opportunity. Modules' maintainers are allowed to decline patches just because they are worried there might be problems, without a formal process to identify issues. CVS applications are subject to the judgment of few people, which in turn rely on the aforementioned scared maintainers.
Well, this is called oligarchy where I am from.
I am utterly disappointed from the attitude of the whole community, despite I profoundly appreciate the everyone's work.
Of course, I'd like to know which the place is to talk about this things, so that I can move this discussion there.
Thank you,
Vincenzo.
#11
As reported in Apply for contributions CVS access, creating a new project for the simple reason another one has issues is not a reason to apply for a CVS account.
#12
Well, the whole system being broken leaves me no other options. The reasons why markus_petrus has refused many times to integrate these functionalities are nothing but personal concerns. Which is unacceptable (and please don't tell me again his reasons were valid, you must have formal proofs that a patch will break - we are talking about software, not paintings). That leaves me no other options but to try and make a separate module for that. Which you have every right to refuse, but I have every right to propose for the reasons stated above.
PS: I am, again, discussing the flaws of the CVS application process here because I still didn't find out where this should be done. Anyone able to tell me that, please do so, that I don't feel comfortable continuing this discussion here. Thank you very much.