Re: Moving from SVN to git - finally!
Nikita Popov <[email protected]>
| Newsgroups | gmane.comp.php.documentation.general |
|---|---|
| Message-ID | <CAF+90c-XDmb9VS=5-yL6A1nuKoEVMpJu=BMNetqGBCw9U7GNfw@mail.gmail.com> |
On Wed, Dec 30, 2020 at 5:48 PM G. P. B. <[email protected]> wrote: > On Wed, 30 Dec 2020 at 17:25, Mikhail Miroshenko <[email protected]> > 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 :) Though I should say that if someone wants to make edit.php.net usable with git, I don't think there's any problem with that either -- though we should probably restrict it's usage to people with a php.net account. As girgias mentioned, patches submitted by 3rd-party contributors on edit.php.net have always been a major PITA to deal with. Regards, Nikita