On Mon, 27 Aug 2018, "Vivi, Rodrigo" <[email protected]> wrote: > Apparently I’m the only Goofy maintainer around, and I lost a day to > fix the tool flow for 100% of the cases I faced here, so, why just > mock it at first sight without considering it?!
Hey, no mocking or offense intended, apologies! Is it not fair to try to understand the reasons behind the changes before merging, regardless of the amount of work you've put in them? It's not just dim per se, it's the workflows we support and encourage. I want to know what the pain points are. The current pull request subcommands do not re-use tags because of how git works. IIUC if you push a tag, people pull it, you push the same tag again pointing at another commit, people pull it again, the tags do not change unless people specifically tell git to do so. What I'm wondering is whether we should drop the mixed convenience of tagging and pull request in one go, and require separate tag-branch and pull-request. I.e. remove tagging from the pull-request subcommands altogether. Then, if you screw up tag-branch, you do it again, leading to a new tag. If you screw up pull-request, you do it again, leading to regenerating the mail template from the existing tags. This way, we could get rid of one failure mode completely, and perhaps encourage tagging more often than sending pull requests. It's more robust overall and less surprising for the user to re-run the same command again on errors rather than provide ways to fix errors after the fact. Also, I wonder about providing the tag list to the subcommand. The current pull-request commands do that automatically based on the branch. Having to provide the tags is just adding another failure mode. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dim-tools mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dim-tools
