On Tue, Aug 28, 2018 at 10:43:46AM +0300, Jani Nikula wrote: > On Mon, 27 Aug 2018, "Vivi, Rodrigo" <rodrigo.v...@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 _______________________________________________ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools