Re: Moving from SVN to git - finally!

On Wed, Dec 30, 2020 at 10:20 PM Jakub Zelenka <bukka@php.net> wrote: > > > On Wed, Dec 30, 2020 at 4:56 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Wed, Dec 30, 2020 at 5:48 PM G. P. B. <george.banyard@gmail.com> >> wrote: >> >>> On Wed, 30 Dec 2020 at 17:25, Mikhail Miroshenko <vipab.vipab@yandex.ru> >>> wrote: >>> >>>> > How is the workflow for maintainers different than before? >>>> >>>> Oh no, as far as I know, earlier maintainers did not need to do actions >>>> locally -- just the online doc editor and here we go! Currently, each of >>>> the maintainers needs to have own local repository and manually apply >>>> third-party patch from a PR. This is hellish pain! >>>> >>>> BTW what about actualizing a translated doc files? In the online editor >>>> we could see which files were outdated and needed in translation update. >>>> Currently, maintainers need to find out this manually. >>>> Offtop -- oh, it seems to me that you have "buried" the translations of >>>> docs with current migration, because it is much more difficult and >>>> unpleasant to handle this. >>>> I have been a maintainer for a long time and the online editor is the >>>> best tool for me as regular translator! >>>> >>>> I am very sad that you have essentially removed all the tools that >>>> simplify (translation) work. Even using the GitHub interface is impossible >>>> to merge a PR... so what was the point then? It's just a Git mirror, >>>> nothing more, imo. >>>> >>>> > The idea would be to have the maintainers added to the github repo >>>> as maintainers. Then you'd be notified of a new PR. >>>> >>>> It would be great. Although I actually wrote about it before. That you >>>> can use the GitHub's _code owners_ to achieve this. >>>> >>> >>> As someone who extensively used the online doc editor for the French >>> translation I can assure you it has been an utter pain to use the past few >>> weeks as it would randomly not apply some changes and you would need to >>> commit them by downloading the patch and applying it yourself *anyway*. >>> >>> Moreover, it has been relatively slow as a tool but the only reason I >>> used it was for the diffs it generated. >>> Something that was always available via the revcheck available on >>> http://doc.php.net. >>> Yes the revcheck script needs to be redone to accustom the git hashes. >>> >>> Yes it is currently suboptimal for users which have a VCS account. >>> But for anyone new wanting to contribute the online doc editor is IMHO >>> useless, it's impossible to review patches on it, and if they stay there >>> for ages they become out of sync as it doesn't do a diff compared to the >>> HEAD, people also just left stuff in the W.I.P. section instead of making a >>> patch. >>> And there is no way to ping someone on it. All of these issues make a GH >>> mirror a way better user experience. >>> Moreover, it's impossible to collaborate on a large change as providing >>> partial commits is pretty gross. >>> >>> About not being able to directly merge from GH, I must say welcome to >>> the PHP project, all git repos have working like this, and we go through >>> this process for merging patches from GitHub into php-src, and it truly >>> isn't as painful as you make it out. >>> >>> There is a one command which will handle it for you: >>> curl http://url_of_github_patch.patch | git am >>> git commit --am // Add Closes GH-prnum >>> git push origin >>> >>> If you truly want, you don't even need to edit the commit message to >>> close the PR automatically, you'll just need to do it manually. >>> So *please* before complaining about the new process, try it out. >>> >> >> Something I mentioned before but didn't elaborate on: I expect the >> process to get automated in the near future. Basically you'd write >> "@php-pulls merge" on the PR, and it would get rebased into the repository. >> We never bothered with this for php-src because we often need to perform >> complex merge procedures across multiple branches, but for docs I expect >> that things will be much simpler. A bit of patience is needed :) >> >> > That would be useful but guess it would also require some kind of build to > at least chect that it builds fine and possibly some way to preview it. > > I think in the meantime it would be great to manage it in the same way as > php-src and have more people that can assign / label / close PR's. Could > you maybe give the same perms for the doc-en repo to php-src team in github > or create a new team? Think the reviews or PR's in src and doc-en are some > kind of related. For example just noticed that there's FPM PR which I would > like to take care of. So think it would make sense for php-src team (or > people from that team if new team is created) to have that access and > handle it in the same way as php-src PR's. > I've given the php-src team triage permissions to doc-base and doc-en now, so it should be possible to assign / label / close PRs. For closing merged PRs we usually prefer to close them via commit though, as this leaves a bi-directional link between the PR and the commit. Nikita