Re: Moving from SVN to git - finally!

Hi guys! Thanks for the wonderful work!

We have had some problems to merge pull requests in pt_br doc repository,
as message below:

remote: Welcome geekcom.
remote: You have insufficient Karma!
remote: I'm sorry, I cannot allow you to write to
remote:     doc/pt_br.git/
remote: Have a nice day.
To git.php.net:/doc/pt_br.git

I would like to know if the same permissions from SVN were migrated to git?
If yes, maybe the sync permissions can be with any problem.

Best regards

Rodrigo


On Wed, 30 Dec 2020, 18:21 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.
>
> Thanks
>
> Jakub
>