GitHub RFC workflow

  107747
November 2, 2019 16:32 nikita.ppv@gmail.com (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
  107748
November 2, 2019 18:40 krakjoe@gmail.com (Joe Watkins)
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 ppv@gmail.com> wrote:

> 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 >
  107749
November 2, 2019 20:02 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
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
  107751
November 3, 2019 00:30 kontakt@beberlei.de (Benjamin Eberlei)
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.
> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107752
November 4, 2019 04:54 pierre.php@gmail.com (Pierre Joye)
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,
  107759
November 4, 2019 05:54 krakjoe@gmail.com (Joe Watkins)
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 php@gmail.com> wrote:

> > > 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, >
  107762
November 4, 2019 07:19 pierre.php@gmail.com (Pierre Joye)
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.
> 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 php@gmail.com> wrote: > >> >> >> 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, >> >
  107764
November 4, 2019 07:35 krakjoe@gmail.com (Joe Watkins)
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 php@gmail.com> wrote:
> > > 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. > > > >> 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 php@gmail.com> wrote: >> >>> >>> >>> 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, >>> >>
  107753
November 5, 2019 08:38 come.chilliet@fusiondirectory.org (=?ISO-8859-1?Q?C=F4me?= Chilliet)
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
  107767
November 5, 2019 19:28 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
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
  107771
November 6, 2019 11:35 derick@php.net (Derick Rethans)
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
  107772
November 6, 2019 11:42 george.banyard@gmail.com ("G. P. B.")
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?!)