Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » GitHub RFC workflow »

GitHub RFC workflow

php.internals

Nikita Popov

6 years ago
Hi internals, Now that the union types RFC is drawing to a close, I think it's time to discuss the question of RFCs in GitHub pull requests again. Overall I'm fairly pleased with how this went and would like to adopt the process in some form. In particular, I would like to start with the following fairly limited proposal: * RFCs may still be submitted directly against the wiki, using GitHub is optional. For small and straightforward proposals this might be easiest. * After an RFC pull request has been opened against the GitHub repository, the RFC needs to be announced on the internals mailing list. * Before voting starts, the proposal must be mirrored to the wiki (as is now done with https://wiki.php.net/rfc/union_types_v2), and the vote is held on the wiki. * Once voting ends, the RFC pull request on GitHub is closed (not merged) with an Accepted or Declined label. Unlike what I had originally in mind, this keeps the PHP wiki as the ground truth: All proposals must be moved there in entirety before voting starts. The GitHub pull request is just a means to make it easier to iterate on the RFC prior to arriving at the finalized proposal. In the future we may decide to abandon this approach with very little cost (as the actual proposals are all in the wiki), decide to adopt it more broadly (forgoing the wiki entirely) or decide to try a different approach (such as one repo per RFC, similar to ECMAScript RFCs). Thoughts? Regards, Nikita

Joe Watkins

6 years ago
Evening Nikita, This is not really what we imagined when we started to discuss using github for pull requests - everything is going to end up on the wiki anyway. I do think this is a very reasonable first step, given how the discussion went on github and given the general feeling that we ought to "own" the RFC content. I would like to question the reasoning behind wanting to "own" the RFC content: We don't require any such thing for any other kind of PR although we say we require a patch on bugsnet, we actually don't require it. So, I have a hard time telling the difference between a PR for an RFC and a PR for a bugfix or enhancement. Can anyone tell the difference ? Having to move the content before voting starts satisfies the urge to own the content, but it also creates an unnecessary step for the proposer which translates to more noise for everyone. Cheers Joe On Sat, 2 Nov 2019 at 17:32, Nikita Popov <nikita.ppv@gmail.com> wrote:

Johannes Schlueter

6 years ago
On Sat, 2019-11-02 at 19:40 +0100, Joe Watkins wrote:
> I would like to question the reasoning behind wanting to "own" the > RFC content: We don't require any such thing for any other kind of PR > although we say we require a patch on bugsnet, we actually don't > require it. So, I have a hard time telling the difference between a > PR for an RFC and a PR for a bugfix or enhancement. > > Can anyone tell the difference ?
In a bug fix or enhancement the relevant information is in the patch, which in the end lives in php-src.git. If a patch isn't self- explanatory it probably needs an RFC as reasoning. That reasoning shall live in a central place to be found by future generations. And some historic context (do with it what you want :-) ) on why php.net instead of GitHub: When we moved to git I (among others) pushed for using our own infrastructure we control, and not binding the process to an external entity. PHP has seen other platforms like sourforge come and go and migrated from CVS, to svn, to git so other platforms coming and going and versioning systems come and go is likely. While GitHub under current Microsoft probably is more likely to stay than the young startup from years back. :-) (that aside from GH requiring accounts on that platform, eventually blocking countries etc.) johannes

Benjamin Eberlei

6 years ago
On Sat, Nov 2, 2019 at 9:03 PM Johannes Schlüter <johannes@schluete s.de> wrote:
> On Sat, 2019-11-02 at 19:40 +0100, Joe Watkins wrote: > > I would like to question the reasoning behind wanting to "own" the > > RFC content: We don't require any such thing for any other kind of PR > > although we say we require a patch on bugsnet, we actually don't > > require it. So, I have a hard time telling the difference between a > > PR for an RFC and a PR for a bugfix or enhancement. > > > > Can anyone tell the difference ? > > In a bug fix or enhancement the relevant information is in the patch, > which in the end lives in php-src.git. If a patch isn't self- > explanatory it probably needs an RFC as reasoning. That reasoning shall > live in a central place to be found by future generations. >
Outside pull requests don't live in php-src.git, because they are provided by different remotes and these are not as far as I see mirrored back in any way to php.net git. So the question Joe poses is right, pull request descriptions and all their comments are currently only available on Github. I also question the "we must own everything" rule, as its highly unlikely Github will not suddenly remove all php-src data and they provide an API to backup or migrate data if we ever want to do something else.

Pierre Joye

6 years ago
On Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei <kontakt@beberlei.de> wrote:
> > Outside pull requests don't live in php-src.git, because they are provided > by different remotes and these are not as far as I see mirrored back in any > way to php.net git. > > So the question Joe poses is right, pull request descriptions and all their > comments are currently only available on Github. > > I also question the "we must own everything" rule, as its highly unlikely > Github will not suddenly remove all php-src data and they provide an API to > backup or migrate data if we ever want to do something else. >
The question is more accessibility. As mentioned before, GH (and other) increasingly bans countries, or even worse, citizens from a country, or apps (See spain recently). That means some of the valid contributions to php won't be able to participate if we were using only GH. best,

Joe Watkins

6 years ago
Morning, I don't want to follow this tangent for too long on owning content. Pierre, can you point to any contribution that would have been blocked by our use of github ? For all intents and purposes, the majority of new development does actually happen on github. As a result of us being terrible at infrastructure - nobody can deny this - the submit a patch thing on bugsnet was (or is) broken so development had to move to a place that worked. I would find the arguments in favour of owning our content more convincing if we were any good at owning content. We're not, machines go down, forms break, mailing lists stop working ... we suck so hard at this, and github is spending millions on these problems, to not take advantage of what is being offered makes no sense on it's face. I think we should rethink these decisions in light of the current facts about the project. Cheers Joe On Mon, 4 Nov 2019 at 05:54, Pierre Joye <pierre.php@gmail.com> wrote:

Pierre Joye

6 years ago
On Mon, Nov 4, 2019, 12:54 PM Joe Watkins <krakjoe@gmail.com> wrote:
> Morning, > > I don't want to follow this tangent for too long on owning content. >
> Pierre, can you point to any contribution that would have been blocked by > our use of github ? >
Sorry, no time to dig in our list of current active contributors and define the risks for each of them. However I am a big fan of github and all for increasing its usage. When it comes to contributors, votes and rfc, it cannot be the only way. Iran, Spain recently or some south America countries have issues with github. Citizen or countries have been blocked, projects removed without warning based on local gov requests etc. This is a risk we cannot and should not ignore.

Joe Watkins

6 years ago
Morning Pierre,
> Sorry, no time to dig in our list of current active contributors and
define the risks for each of them. That's not what I asked for, I asked for a single concrete example where this would have in fact been a problem. I'm in Spain, and unaware of any access problems ... Can you point me to a story explaining what you're talking about in regards to Spain and South America ? I'm not suggesting we ignore it, and I may in fact be ignorant of some of the problems you are talking about. But, at bottom world politics and political instability are not the problem of an open source project. I'm also not suggesting we move everything to github. I'm simply questioning the "owning all content" mantra because it doesn't make as much sense today as perhaps it once did. Cheers Joe On Mon, 4 Nov 2019 at 08:19, Pierre Joye <pierre.php@gmail.com> wrote:

Pierre Joye

6 years ago
On Mon, Nov 4, 2019, 2:35 PM Joe Watkins <krakjoe@gmail.com> wrote:
> Morning Pierre, > > > Sorry, no time to dig in our list of current active contributors and > define the risks for each of them. > > That's not what I asked for, I asked for a single concrete example where > this would have in fact been a problem. >
Iran, Venezuela (not sure we have some in our contributors) f.e. cannot use github, depends on the case but either by citizenship or actual locations. By paid account, banned if based in either country.
> I'm in Spain, and unaware of any access problems ... >
https://www.vice.com/en_us/article/9kevn7/spain-and-github-are-blocking-an-app-that-helped-protesters-organize
> Can you point me to a story explaining what you're talking about in > regards to Spain and South America ? >
see above.
> I'm not suggesting we ignore it, and I may in fact be ignorant of some of > the problems you are talking about. But, at bottom world politics and > political instability are not the problem of an open source project. > > I'm also not suggesting we move everything to github. I'm simply > questioning the "owning all content" mantra because it doesn't make as much > sense today as perhaps it once did. >
Thanks you for the clarification. I am also all fine to use github. I however would like to ensure everyone can participate. Given the current context, in so many countries, commercial companies are under huge pressures from governments. Not many care about Iran or Venezuela but I feel like other communities could be next if things get worst, and not only nation based communities but religions, orientations, etc. Indeed not in UK or EU, but I am not sure at all about (too) many other countries.

Joe Watkins

6 years ago
Afternoon, It should be clear that if we were in receipt of the kind of notice that the Guardia sent to Github we would be extremely ill advised to ignore it, regardless of the services we use, location of servers, or any other detail you care to mention. The Guardia did not target Github because of their affiliation with any state, country, or company but because of their association with the contravention of the mentioned laws.
> Given the current context, in so many countries, commercial companies are
under huge pressures from governments. Making these things our problem doesn't make a whole lot of practical sense. If we can't find practical reasons not to take advantage of what is being offered, then I don't think we should put theoretical problems in the way of progress. Cheers Joe On Mon, 4 Nov 2019 at 12:57, Pierre Joye <pierre.php@gmail.com> wrote:

Johannes Schlueter

6 years ago
On November 4, 2019 8:35:16 AM GMT+01:00, Joe Watkins <krakjoe@gmail.com> wrote:
>I'm in Spain, and unaware of any access problems ...
In Spain there recently was a court case against an app used to organize protests for an independence of Catalonia. In consequence Github was required to block access from Spain to the relevant repositories. Spanish users can't access the relevant projects anymore. https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-23-GuardiaCivil.md https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-26-GuardiaCivil.md johannes

Mike Schinkel

6 years ago
> https://www.vice.com/en_us/article/9kevn7/spain-and-github-are-blocking-an-app-that-helped-protesters-organize > https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-26-GuardiaCivil.md
It would seem to me that if any country decided that downloading and working with PHP were against the law, it would not matter where we hosted it, GitHub or php.net <http://php.net/>. If for some reason a country got mad and decided to block GitHub, we could easily set up a mirror at BitBucket or some other repository and thus allow people from that country to contribute to PHP/ In addition if it became a problem for someone to access discussions, we collectively could use the GItHub API to write a mirror of discussions so people could read and contribute to support those people in the "banned country" just as easily as building all infrastructure from scratch that nobody have thus far found time to get around to build proactively. So given all those concerns are currently hypothetical — since PHP is not an app for organizing protests nor is it an advocacy group for a maligned minority — maybe we should just keep our eye on potential problems so that if potential problems arise we can implement a workaround, but until then we just use was works best today? #JMTCW -Mike

Côme Chilliet

6 years ago
Le samedi 2 novembre 2019, 19:40:56 CET Joe Watkins a écrit :
> I would like to question the reasoning behind wanting to "own" the RFC > content: We don't require any such thing for any other kind of PR although > we say we require a patch on bugsnet, we actually don't require it. So, I > have a hard time telling the difference between a PR for an RFC and a PR > for a bugfix or enhancement. > > Can anyone tell the difference ?
Whether there is a difference or not, «we already use too much github» is not a reasonable argument for «let’s use more github». It would of course be better if the PRs were not done through github, but as far as I know this is not mandatory and people are allowed to do PR through other systems. I’m still strongly against using github for RFCs, and missed most of the discussion on union types because it was there and hard to follow (things are not chronological, I can’t know easily if there are new comments and which ones are, usability is not the reason I’m against github but it was also bad).
-- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

Björn Larsson

6 years ago
Den 2019-11-02 kl. 17:32, skrev Nikita Popov:
> Hi internals, > > Now that the union types RFC is drawing to a close, I think it's time to > discuss the question of RFCs in GitHub pull requests again. Overall I'm > fairly pleased with how this went and would like to adopt the process in > some form. > > In particular, I would like to start with the following fairly limited > proposal: > > * RFCs may still be submitted directly against the wiki, using GitHub is > optional. For small and straightforward proposals this might be easiest. > * After an RFC pull request has been opened against the GitHub repository, > the RFC needs to be announced on the internals mailing list. > * Before voting starts, the proposal must be mirrored to the wiki (as is > now done with https://wiki.php.net/rfc/union_types_v2), and the vote is > held on the wiki. > * Once voting ends, the RFC pull request on GitHub is closed (not merged) > with an Accepted or Declined label. > > Unlike what I had originally in mind, this keeps the PHP wiki as the ground > truth: All proposals must be moved there in entirety before voting starts. > The GitHub pull request is just a means to make it easier to iterate on the > RFC prior to arriving at the finalized proposal. > > In the future we may decide to abandon this approach with very little cost > (as the actual proposals are all in the wiki), decide to adopt it more > broadly (forgoing the wiki entirely) or decide to try a different approach > (such as one repo per RFC, similar to ECMAScript RFCs). > > Thoughts? > > Regards, > Nikita
Hi Nikita, I think this is a good proposal trying to achieve a balance and also showing some prudence, which in my eyes don't hurt. My impression from the RFC discussion on Github is that it was good for the nitty gritty details, but getting the overall picture on the discussion was more difficult. Looking back I feel it was more valuable during the discussion phase, but after it I only go to the wiki to read up on the RFC. Having a threaded news reader also helps catching up on old discussions (using thunderbird). Another aspect to consider is that RFCs have a lifespan after they are approved, by being used in different books, tutorials etc. Also when doing migrations I often go to the wiki to check on which RFC in which release that generated warnings in the code, e.g. countable RFC. I do like the simplicity and accessibility of the wiki. r//Björn L

Derick Rethans

6 years ago
On Sat, 2 Nov 2019, Nikita Popov wrote:
> In particular, I would like to start with the following fairly limited > proposal: > > * RFCs may still be submitted directly against the wiki, using GitHub is > optional. For small and straightforward proposals this might be easiest. > * After an RFC pull request has been opened against the GitHub repository, > the RFC needs to be announced on the internals mailing list. > * Before voting starts, the proposal must be mirrored to the wiki (as is > now done with https://wiki.php.net/rfc/union_types_v2), and the vote is > held on the wiki. > * Once voting ends, the RFC pull request on GitHub is closed (not merged) > with an Accepted or Declined label.
I think this makes perfect sense! cheers, Derick

Girgias

6 years ago
Morning Internals, To start, I find it ironic that the people claiming that having everything self host is better for accessibility when the exact day most of this discussion occurred I'd wager 99% of the mailing list subscribers weren't able to follow the discussion as there was an issue with PHP's SMTP/NNTP whereas I could follow, and get notified, on everything going on GitHub. Tying this to Joe's comment, we really are bad at infra, because it is not our "job" to handle this infra, our "job" as a project is to maintain/develop/improve PHP, and having this much infrastructure, which the project lacks the manpower to maintain, is taking away resources from our core objectives. I am NOT saying that some of the concerns are invalid, they truly are something to keep in mind when making choices for the project, but they should not dictate them IMHO. If we need to have something in house which allow us to implement the proposed workflow, I suppose we could always create a self-hosted GitLab instance (external users would use OmniAuth to participate in discussions). However the question is who will and is willing to maintain this piece of infrastructure that gets monthly updates? For the actual proposal laid out by Nikita, I fully agree, the ML is good for meta discussion around the RFC but not to go into the nitty gritty details of a particular RFC and how it can be improved. Best regards George P. Banyard PS: I would also like to address the seemingly misrepresentation these corporations get as that they are willingly banning countries/apps, which is not the case as they are obliged to by their local country (for GitHub this would be the embargo on certain countries like Iran). PPS: Also for the love of god can we stop making the assumption that if we move part of our infra to some external entity that we wouldn't be able to claim it back/move it once again? In the super hypothetical case that an entity we use decides to go "nazi" (And how on Earth is this an actual concern?!)