[PATCH 2/3] dim: Introduce dim_request_pull_tags

[Rodrigo Vivi]

On Tue, Aug 28, 2018 at 10:43:46AM +0300, Jani Nikula wrote:
> 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!

no problem. I see you reasons now, thanks for clarifying.

> 
> 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?

totally!

> 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.

honestly I like this convenience a lot when it applies and when it doesn't
fail.

> 
> 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.

I like this flow too...

> 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.

... but I prefer we try to keep the automatically identification of
the tags like we do with drm-intel-next... no need to always force
listing the tags.

And about failures possibility, my version here loop on tags checking
if they are valid and sorting it from newest to oldest, so I don't
see many risk on the tags itself.

But biggest risk would be cases like sending old tag on the same bucket
and in this case I don't know if the end of apply pull is smart enough
to filter it.

Thanks,
Rodrigo.

> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center