Wrong reference to hook_nodeapi in devel_generate

Thank you for the clean-up. Please note that D8 needs to go first.

+++ b/devel_generate/devel_generate.inc
@@ -114,8 +114,10 @@ function devel_create_users($num, $kill, $age = 0, $roles = array()) {
+ * their data during hook_node_insert or in own submit handler for the form.

Use parentheses with hook_node_insert() — this will generate a link in the documentation.

Also add a 'their' in the proper place, please.

+++ b/devel_generate/devel_generate.inc
@@ -678,14 +680,16 @@ function devel_generate_content_add_node(&$results) {
+  //generated node.

Add a space.

I've added the "their":

+ * their data during hook_node_insert or in THEIR own submit handler for the
+ * form.

Committed to D8 and D7. Thanks!

This is proper attribution...

Issue #1799024 by pcambra: Fix outdated references to hook_nodeapi() in comments (no functional changes).

... even though I had to fix your patch.

git am is a pain because it auto-commits the patch. For that the patch needs to be 100% perfect, including the commit message. I had to fix both the patch and the commit message, so if anything is wrong here, it's that I didn't add my name (for reviewing and fixing).

Even if the patch is perfect, git am is a pain because it cannot be rolled back as easily as git apply. And if I've tentatively applied a patch with apply and I decide to keep it, I will not roll it back and reapply with am. Also I don't think about the commit message until I'm ready to commit, another strike against git am.

As it says on the page you referenced (my emphasis):

the author's drupal.org user name can be used for attribution [with --author].

I will do the --author thing for a perfect patch that represents a significant amount of work by a single person and no other significant contributors, but for small patches (and patches with more than one contributor) the standard attribution must do.

You'd be the first to accuse me of not doing proper attribution. Please take that back.

[EDIT: Our messages crossed. This is in reply to #6, without having read #7]

#4:

Thanks, but next time please use proper attribution

This implies that I have not used proper attribution. This comes across as a personal accusation.

I have shown that I have used proper attribution, and that's why I reject the implied personal accusation and I'm asking you politely to take it back.

You may have a preference for the git am workflow and the --author parameter and I have a preference against them, for the reasons that I explained above.

I would totally applied git attribution (what I've seen in many places called as "proper attribution") in any of my modules for a patch like that and that's why I'm expecting the same thing anywhere else.

You can do whatever you feel is right with your modules, but that does not mean that your maintenance style is the one and only correct one, and that everyone else has to follow.

I'm trying to help here in devel as you can see in more and more issues

I realize that and I appreciate and support your efforts. Thank you.

just asking for what I think (and I'm not a fool alone in this) it should be the way to proceed for all projects.

That is your opinion. I'm not aware of any consensus to do this. The commit message provides "proper attribution" and I'm opposed to adding mandatory overhead to the maintenance workflow, as explained above.

@salvis - I encourage you to install dreditor and try out its 'create commit message' feature. it really does make the --author enhancement much easier. and i do think thats ultimately a good thing for devel. we need to encourage contribution. if dreditor just won't fit with your workflow, you could try out the new drush issue queue commands. I have been meaning to start using those.

I have found a way to make git am not painful. Basically, you use git commit --amend -a to add your bits to the most recent commit. To roll back, you use git reset HEAD^1. You can alias these to git amend and git rollback if you wish.

Patches formatted with git format-patch can still be applied with git apply in case a change is needed. The commit message can also be copied and pasted from the patch. Furthermore, with git rebase -i commits can be modified, squashed or merged prior to be pushed by the maintainer.

This is not the first time I see negative comments which may make willing contributors to step back on this module. I have even heard about it at Drupalcon Munich. Contributions are good for all of us, even if they are tiny.

This interleaved discussion is becoming cumbersome...

@pcambra, #7:

I was referring to "proper attribution" as the name to the initiative to get more maintainers to use the git --author thingy, as I pasted the link above, I didn't invent the naming for that.

Changing the meaning of common words is a popular tool in a propaganda campaign, but it alienates those who are not on the train. Agitation can, does, and will backfire.

--author is flawed because it allows only one name; attributing a commit to whoever may have added the last iota is definitely wrong. I have used it (for example here) and will use it for major contributions, but having hundreds of modules listed on your profile page looks spammy IMO.

Also, the --author names appear on the Committers page of the modules, which is not correct — authors are not committers — and spammy, too.

I truly think that's a step forward in getting more and more people contributing back as it is displayed in the user profile, and that means something, the "by name" message is hardly traceable.

I disagree. The cost is too high. Having to deal with a flood of trivial patches cannot be in the interest of the real committers nor of the community, and trophy hunting is the wrong incentive, especially if the trophies are so cheap that you have to amass hundreds of them to make them mean something. This is a major drain on the module maintainers.

The kids willing to spend 10 minutes to make a trivial change somewhere in exchange for a link outnumber the maintainers who have to spend 5 minutes on correspondence, reviewing, testing, committing by a factor of maybe 100 to 1. This strategy cannot work. Even if we go to the core model where committers don't look at patches until they're RTBC'd, committing a patch still takes 2 minutes.

@moshe, #10:

I have Dreditor installed. The 'create commit message' feature is not bad, but most often I don't want an --author parameter.

you could try out the new drush issue queue commands.

I use msysgit under Windows and I'm comfortable using its bash shell in a console window, but I don't think drush runs in that environment.

To roll back, you use git reset HEAD^1.

No, that should not be part of a normal workflow, whether per se or (even worse) aliased. We have safety nets for good reasons.

it really does make the --author enhancement much easier. and i do think thats ultimately a good thing for devel. we need to encourage contribution.

I already feel an increase of trivial patches, and if this continues, I'll either quit, WF them, or just ignore them. My time is too valuable to deal with peanuts for the benefit of trophy hunters.

@juampy, #11:

Patches formatted with git format-patch can still be applied with git apply in case a change is needed.

That's exactly what I did and what I'll continue to be doing. And what pcambra complained about. I'm comfortable with git commit --amend, too, but git rebase -i is more than I want to get into.

This is not the first time I see negative comments which may make willing contributors to step back on this module. I have even heard about it at Drupalcon Munich.

Sure, everyone wants their pet feature committed and then maintained forever by others. It sucks when this doesn't happen. ;-) The people who wanted to talk to us in Munich didn't show up. Surely our fault, too...

BTW, what about the willing reviewers? I'd rather have more reviewers than more contributors at this point.

Contributions are good for all of us, even if they are tiny.

They're especially good if you don't have to move a finger, meaning that others take care of them. Being on the receiving end, I can't agree with that global statement. If you refuse to weigh costs against benefits, then you're out of touch with reality.