Hello! I was looking around in Gerrit and was noticing how many patches have been left behind by people who abandon working on the patches they submitted. I was wondering if there was a way to transfer ownership of a patch to allow someone to continue working on a patch that has been abandoned by the original submitter.
Patches are not abandoned, but gathered in Gerrit instead of Trac. Anyone can propose a new patch version.
1 Like
You can cherry-pick the patch from Gerrit, make changes and push an updated version. Make sure the change-id from the original patch is in the commit message so it is detected as an update of the existing one.
Help finishing these patches is very welcome!
2 Likes
Maybe some specific instructions on how to do that would be useful. I know it is possible but not obvious how to do it. Also maybe provide a bit extra detail about the Change-Id and the exact format Gerrit expects.
Lastly maybe there could be some priority list of abandoned patches we would like to get finished. Though I don’t know a nice way to do that…
Maybe I will just have to sit down and do the above 
A blog post might work.
I can agree! Possibly adding to the wiki page at https://dev.haiku-os.org/wiki/CodingGuidelines/SubmittingPatches would be a good way to inform developers of some extra features of Gerrit. (I would personally help out, though I will be on vacation for some time)
I don’t think you should be concerned with Change-Id format.
It is expected that you have a commit-msg hook installed, so it can be generated for every commit you do (instead of it being generated server side, and you having to manually apply it to your local repo).
A command to add the hook is in repo settings when you’re logged in (Browse->repositories->haiku).
Yes I am aware of the Gerrit commit-msg hook, and usually install that when I use Gerrit, but no one developing on Haiku seems to use it, I assume because it will pollute commits we push directly into master.
Also it is doubtful new patch submitters, or people trying to resurrect old patches will have this installed. I also don’t know if the Change-Id is guaranteed to be in the commit message if someone downloads an old patch branch from Gerrit.
Therefore if I went about documenting how to download and update old patches I would want to inform the reader (who 9 times out of 10 does not know how to use Gerrit) how to add the Change-Id to their amended commits, and maybe why it is needed (so Gerrit can match new pushes of previous commits.)
1 Like
The hook will become mandatory in next Gerrit versions. There is already a warning that pushing without change-ids is deprecated.
So, about the process for these patches, here is what I do:
- To download an old patch, use the “download” button. This conveniently gives you the command lines to cherry pick, checkout, etc the patch from your usual git checkout. I feel there isn’t much to document here, the download button seems to be the obvious place to go?
- The change-id is not guaranteed to be in old patches if the original submitter did not add it. However, it is displayed just below the commit message in the Gerrit web ui and can be copypasted as-is from there into the commit message. It is easy to look into other commit messages to see how this is done, and it follows the pattern of any tags you would add to commit messages: signed-off-by, fixes: #ticket, and so on. So I feel there is nothing too unexpected about this.
Anyway, the wiki is editable and the “getting the sourcecode” page can be changed through the merge request process. So if you think there are some things to clarify, go ahead. I think currently the pages are mostly targetted to people who are completely beginner at submitting patches in our workflow, but already know some git and maybe the pull request flow of github. This allows to keep the pages reasonably short. I think that’s more important: once we have got people to submit a first version of their patch, we can either tell them how to do the next step, or someone can take over the patch. Whereas if we drown them in too many information from the start, they may give up long before they submit the patch at all. This is why the hook installation, etc, hadn’t been covered.
3 Likes