[PATCH 2/3] dim: Introduce dim_request_pull_tags

Jani Nikula jani.nikula at intel.com
Tue Aug 28 07:43:46 UTC 2018


On Mon, 27 Aug 2018, "Vivi, Rodrigo" <rodrigo.vivi at intel.com> 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


More information about the dim-tools mailing list