Re: Moving from SVN to git - finally!
| From: | Nikita Popov | Date: | Wed, 30 Dec 2020 16:56:28 +0000 |
| Subject: | Re: Moving from SVN to git - finally! | ||
| References: | 1 2 3 4 5 6 | Groups: | php.doc |
| Request: | Send a blank email to phpdoc+get-969387765@lists.php.net to get a copy of this message | ||
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 :)
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