On Thu, Sep 26, 2019 at 6:56 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > 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? > Yes, if we can achieve that, then that would be good for me. I personally would like to have my pushes checked in some way. And if this achieves that, then I would like to see it. Troy _______________________________________________ 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
