Re: Moving from SVN to git - finally!

On Wed, Dec 30, 2020 at 9:49 PM Nikita Popov <[email protected]> wrote:

> On Wed, Dec 30, 2020 at 10:20 PM Jakub Zelenka <[email protected]> wrote:
>
>>
>>
>> On Wed, Dec 30, 2020 at 4:56 PM Nikita Popov <[email protected]>
>> wrote:
>>
>>> 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 :)
>>>
>>>
>> 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