Unsubscribe Re: Moving from SVN to git - finally!

Unsubscribe > On 6 Jan 2021, at 9:52 pm, Davide Pastore <pasdavide@gmail.com> wrote: > > Hi guys, > > first I want to say thanks for your commitment on this heavy task. A migration to git was > discussed for a lot of time and you had managed to do it in the right way. > > Anyway I want to ask you some questions: > Do you have news about the revcheck script? I tried to use the one > <http://doc.php.gpb.moe/tools/revcheck/> suggested by George > P. Banyard and it seems to work fine, but I just want to know if we have progress in this sense so > we can easily launch it on our local machines; > As of now IT documentation build is broken but it's strange because the error reported > there ("Entity 'language.types.pseudo-types' not defined") doesn't come out > when I try to launch the same command on my machine, since it works fine. Could you please help me > in this sense? > Thanks and regards, > Davide Pastore > > > Il giorno mer 30 dic 2020 alle ore 23:14 Jakub Zelenka <bukka@php.net > <mailto:bukka@php.net>> ha scritto: > > > On Wed, Dec 30, 2020 at 9:49 PM Nikita Popov <nikita.ppv@gmail.com > <mailto:nikita.ppv@gmail.com>> wrote: > On Wed, Dec 30, 2020 at 10:20 PM Jakub Zelenka <bukka@php.net > <mailto:bukka@php.net>> wrote: > > > On Wed, Dec 30, 2020 at 4:56 PM Nikita Popov <nikita.ppv@gmail.com > <mailto:nikita.ppv@gmail.com>> wrote: > On Wed, Dec 30, 2020 at 5:48 PM G. P. B. <george.banyard@gmail.com > <mailto:george.banyard@gmail.com>> wrote: > On Wed, 30 Dec 2020 at 17:25, Mikhail Miroshenko <vipab.vipab@yandex.ru > <mailto: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 > <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 > <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. > > > Nice one! > > Thanks > > Jakub