On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote: > On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote: > > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit : > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > > > IMHO Have to stay optional, making this mandatory being a terrible headache. > > > > What makes it a headache? What can we do to not have this be a terrible > > headache? Can we fix/improve the tooling? > > > > Note: this is the long term vision, as we move towards it things will be > > optional: opt-in, then (maybe) opt-out, then (if we want to) mandatory. > > > > There has to be an easier way to do pull requests. And maybe there > is, I'm not a git expert. > My biggest concern that I see isn't for my own packages, but as a > proven packager, there are times I need to "group change" things. An > example is that I recently helped with the EPEL 7 python34 -> python36 > changeover. This required changing alot of packages. For the sake of > simplicity, we'll say it's 100. > I now have to fork 100 packages. > Download those 100 git repo's. > And for each of those packages I have to then create my fork > pull-request branch. > After that, the steps wouldn't be too different. I would make my > changes, commit and push. > I would then have to create the pull request (I currently don't know > how to do that from the command line), wait for the testing, get the > pull request pulled, and from there it's the same. > > For me, it's those first three steps that are the headache. > Especially with having to fork the repo. I look at that and think > that it's a waste of space, on both my machine, as well as the server > machines. > > If there was a better, easier way of creating the pull request, then > it wouldn't be a headache for me. All what you are describing here should be achievable with some tooling. I mean, we could have all the magic be in `fedpkg push` which suddenly, checks if you have a clone, it not creates it, adds it as a remote to your git repo and do the git push to that remote. We could then have a `fedpkg new-pr` to create the PR or even a `fedpkg push --pr` to do both actions in one step :) Would that make it less of a headache? Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
