[go-rpm-macros] PR #16: make it use the actual code that was merged in redhat-rpm-config-130
nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` make it use the actual code that was merged in redhat-rpm-config-130 ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
nim merged a pull-request against the project: `go-rpm-macros` that you are following.
Merged pull-request:
`` make it use the actual code that was merged in redhat-rpm-config-130 ``
ignatenkobrain commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` I would appreciate if you would not merge your own PRs in one minute after opening. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
nim commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` @ignatenkobrain sorry, I didn't know there was much interest in reviewing such a trivial commit (or in go-rpm-macros PRs in general). If you have any comment on the result, please report it, code is not set in stone, merge or no merge. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
ignatenkobrain commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` I mean, if it is trivial - just commit it. I this not first PR where this happens.
``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
nim commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` Ah, that
Just because it is trivial does not mean stupid typos can not happen, so the commits cook in a private feature branch (where I can rewrite git history without bothering anyone) and are merged when they pass testing.
The commit state that get merged is rarely the first version I wrote.
Is there a simpler/better method to move reliably a set of commits from a forked feature branch to the main project? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
bex commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` @nim it is customary in almost every project I have been in that someone doesn't merge their own commit unless time has passed/emergency situations.
I think what @ignatenkobrain is getting at is that there are multiple membes of this repo and the whole Go SIG. It is perhaps worth putting the commit policy in writing to prevent confusions and misunderstandings.
In my own experience I have seen my trivial patches viewed as non-trivial by others (and vice versa) and one-line commits get a lot of commentary. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
nim commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` @bex sadly there are not many (any?) good wills to do regular reviewing. The repo history shows long periods of one-man commits, be it now or when the maintenance was done by others. @eclipseo does most of the second level checking/testing nowadays (thanks a lot!) but that does not happen in PR tickets (and sometimes he tests pre-versions of code before they even end up in a PR)
So it's not a SIG policy set in stone, just a side effect of the small kernel of people that work on Fedora Go tooling. It can change any time people show up and propose to take ownership of something (be it reviewing, documenting, or anything else that could benefit from more contributions).
If anyone here volunteers to conduct a formal review of the next PRs, there's no problem to keep them open some more. As long as it's not just gathering up dust in the hope some hypothetical reviewer will eventually show up. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
jcajka commented on the pull-request: `make it use the actual code that was merged in redhat-rpm-config-130` that you are following: `` @nim if you are not looking for feedback keep it open for some time and then merge it with something like tested here in this way forks for me or just commit and push directly in to the master branch this kind of looks really bad. I have been trying to provide you with feedback in the past, but you made to me obvious that you are not wanting it by shaming and blaming me and others. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/16
golang@lists.fedoraproject.org
-
Brian Exelbierd (bex) -
Igor Gnatenko
-
Jakub Čajka
-
Nicolas Mailhot