Re: Current state of my ideas on moving docs to GIT

From: Date: Sat, 18 Nov 2017 05:59:29 +0000
Subject: Re: Current state of my ideas on moving docs to GIT
References: 1 2  Groups: php.doc 
Request: Send a blank email to phpdoc+get-969386807@lists.php.net to get a copy of this message
W dniu 13.11.2017 o 23:24, Peter Cowburn pisze:
Hi Andreas and doc geeks,
Hi Peter!
Thank you for putting in all of this work. Let's run ahead with this experiment and see how it goes.
I like such approach! We can spend many hours discussing all the details but actually trying seems to be the best option to have it working quickly and have an opportunity to catch up all the annoyances or missing parts of the process. I assume that you meant to (somehow) set up the new git-related infrastructure alongside the current one, correct? So in worst case scenario we can easily give up and still use what we have now.
Let's give it a go and see how it works in practice.
I would love to and appreciate this call to action but there are many steps in the plan that cannot be done without karma/permissions all over the PHP.net - like creating new git.php.net repositories (I think that at first step we can avoid setting up GitHub mirrors to speed up and add it later if it will turn out to be a success; it would also prevent the confusion for newcomers which would see github repos for the manual which is still primarily using SVN). Then I think we should focus on trying to make doc.php.net working like it is now (but with git obviously). Once we will have the solution for translators to update their language versions against English one, I would assume it's quite safe to proceed. But the thing here is that we cannot really have both at the same time. Let's assume I can cooperate with Andreas and prepare the branch to migrate whole doc.php.net to support git... but how can we test it then? The only things I can think of are setting up new doc.php.net instance (with the sources from other branch than master) but it requires spinning up new machine which is money and time consuming OR switching between SVN's and git's implementations with some hidden URL parameters which requires a transition state with the code full of conditionals (and we know that temporary things tend to stay forever...). I can be wrong, of course, but for me it seems like the minimal plan to check whether git-based documentation can actually work - and the one that we could set up quite independently from current one - focusing on the *read* part first.
My preference is to have git.php.net <http://git.php.net> be the canonical repo host with GitHub as only a mirror for the source. This way, we can keep using existing tooling (such as the commit karma checking). That said, I'm not a dictator so if there are good reasons, or strong consensus, not to do the above then I am all ears.
Agreed.
At this stage, I don't really mind if there are more "manual labour" steps than automated ones. Things like automated build-on-merge tasks can come later (the cron job builds work fine, for now).
I can only agree. As someone else suggested in this thread I would focus on keeping feature-parity with the current solution first. Then we can actually introduce git and improve the process where it allows us to.
We want to be using Git. So let's make that happen.
Exactly! Cheers, Maciej.

« previous php.doc (#969386807) next »