How to submit multiple patches to a contrib module?

Question

I'm building a web application and use some contrib modules. I heavily rely on a particular module, for which I already submitted a patch a couple of months ago, which was eventually committed.

On these days I had some new requirements, so I added a new functionality to the module and discovered and solved two (unrelated) bugs.

Now a stupid doubt grips me and I'm stuck. My question is: what should I do now?

1. Create three issues (or write in the existing ones, if the bug was already known) and submit right away my code in three different patches (which are independently written on the current dev version). This means that when a patch will be committed, I'll have to create a new version of the remaining patches for the new dev version
2. Create a issue with patch for one of the bugs/features, wait that it gets committed, open another issue for another one of the bugs/features, submit a patch on the updated dev version, wait that it gets committed, then open the third issue, submit the patch for the last bug/feature on the again updated dev version. This could potentially take weeks or months.

Usually I would say 1, but due to the short timeframe between patches (a couple of minutes, just the time to create the issues) and the fact that only one person is the creator of all of them, gives me the impression of spamming. It's not a problem for me to create and "maintain" three issues and the related patches, I jut want to do it in the right way.

Answer 1

Submitting all the patches, in different issues, at the same time is actually a problem just in the case they conflict with each other; this means that, once applied a patch, it would not be anymore possible to apply the other ones without rerolling them.

Since you cannot say which of them is going to be applied first from the maintainer, I would submit all the three issues at the same time. In that way, even if two of them are not going to be applied first, there is still a discussion going on about the necessity of applying them, or about what needs to be changed in them. If then the applied one doesn't allow to apply the other ones, you will need to reroll them, or somebody else could reroll them.

As for the short timeframe between patches, that is never taken as spamming an issue queue. If you want to be taken in consideration from the maintainer, you should make a good use case for your patches, or make evident there is a issue to be fixed (in the case it is not so evident); if the patch is going to fix a problem that happens in very few cases, be prepared to make clear what the benefits from your patches are. Being a maintainer doesn't mean knowing all the problems the users of a module could have; in some cases, the maintainers need just some data to make evident what the problem is.

Answer 2

if these 3 fixes/patches unrelated, I would go with first option as it keeps things clear and if any of these patches introduces any other issues/conflict it will be easier to maintain it. I understand how this is time consuming, but it's better if you do it the right way.

Answer 3

Separate the issues/patches

For sure create 3 separated issues, with each of them containing 1 of your patches. This has advantages such as:

• Any community member can "cherry pick" any of your 3 issues to either use them (apply the patch(es) they need/like), review them, etc.
• It might potentially lead to the 3 issues being processed in parallel (by 3 different users/reviewers), so possibly also reducing the elapsed time to get them RTBC-ed also.
• It reduces the risk that 'all' your patches are rejected, in case something happens in the dev version of the module due to which "your" patch needs to be rerolled: if you have 3 separated patches, only 1 or 2 or them might require a re-rolling (read: that's not a showstopper for those patches that are not impacted).
• ... (there are more advantages to this approach).

Choose your battles

Even though you should separate them (see above), "you" have some level of control about the order of review and commits to the dev version. I would make a ranking like "which one is most important to me, and which one is more like a nice to have (eg because you have a work around)".

Based on your ranking, you could submit the most important one first, and wait "some time" (up to you to decide how long) before submitting the 2nd one. Later on the 3rd one. This approach avoids that the other people involved (reviewers, committers, etc) start working on "the" issue that "they" find most important (which is different from your ranking). Optionally, when submitting the 1st (or 2nd) issue/patch, you may want to add some type of comment like "after this gets addressed, I have another one coming up (which IMHO is lower priority)".

It works

I've used the above approach in the past also. After a while the module owner started to realise the value of my contributions ... it resulted in receiving commit access to the module, whereas I got 'carte blanche' for anything related to "what I found important to be fixed / enhanced".