Unsubscribe Re: Moving from SVN to git - finally!

Unsubscribe

> On 6 Jan 2021, at 9:52 pm, Davide Pastore <[email protected]> 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 <[email protected] <mailto:[email protected]>> ha scritto:
> 
> 
> On Wed, Dec 30, 2020 at 9:49 PM Nikita Popov <[email protected] <mailto:[email protected]>> wrote:
> On Wed, Dec 30, 2020 at 10:20 PM Jakub Zelenka <[email protected] <mailto:[email protected]>> wrote:
> 
> 
> On Wed, Dec 30, 2020 at 4:56 PM Nikita Popov <[email protected] <mailto:[email protected]>> wrote:
> On Wed, Dec 30, 2020 at 5:48 PM G. P. B. <[email protected] <mailto:[email protected]>> wrote:
> On Wed, 30 Dec 2020 at 17:25, Mikhail Miroshenko <[email protected] <mailto:[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 <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