Re: [PHP-DEV] GitHub RFC workflow

[Mike Schinkel]

> All are real problems, today. Spain's exams is the smallest one. Other cases 
> affect many people already with Github (at large).

You misunderstood my comments.

I did not mean they were not real problems for the people who they affected by 
those issues; they absolutely are. And I have empathy for them and if I how 
power to change it I would. But alas, I do not.

What I instead meant was that those are not problems that affect — or are 
likely to affect — people's access to Github with respect to contribution to 
PHP.  And, unless I am somehow mistaken, that is primary shared issue of 
concern for people subscribed to the PHP internals  email list. And nothing 
more.

-Mike

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

On Wed, Nov 6, 2019, 10:00 AM Mike Schinkel  wrote:

> .
>
> So given all those concerns are currently hypothetical



All are real problems, today. Spain's exams is the smallest one. Other
cases affect many people already with Github (at large).

best,

Re: [PHP-DEV] GitHub RFC workflow

[Mike Schinkel]

> 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 .

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

Re: [PHP-DEV] GitHub RFC workflow

[Björn 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GitHub RFC workflow

[Joe Watkins]

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  wrote:

>
>
> On Mon, Nov 4, 2019, 2:35 PM Joe Watkins  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.
>
>>

Re: [PHP-DEV] [RFC] Add WeakMap

[Benjamin Morel]

Hi Nikita,

After reading the RFC, I have no comments to make, but I just want to thank
you for working on this. I regretted a lot that this wasn't implemented
together with WeakReference in PHP 7.4 ,
as the use cases for WeakReference vs WeakMap are really narrow.

Cheers,
Benjamin

On Tue, 5 Nov 2019 at 10:24, Nikita Popov  wrote:

> Hi internals,
>
> This is a follow up to the addition of WeakReference in PHP 7.4.
> WeakReference is an important primitive, but what people usually really
> need are weak maps, which can't be implemented on top of WeakReference (at
> least, not as exposed in PHP).
>
> This RFC proposes to add a native WeakMap type for PHP 8:
> https://wiki.php.net/rfc/weak_maps
>
> Regards,
> Nikita
>

Re: [PHP-DEV] GitHub RFC workflow

[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  wrote:

>
>
> On Mon, Nov 4, 2019, 12:54 PM Joe Watkins  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  wrote:
>>
>>>
>>>
>>> On Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei 
>>> 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,
>>>
>>

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

sorry, bad roads and writing from my mobile. I am not driving but still ;-)

On Mon, Nov 4, 2019, 7:33 PM Pierre Joye  wrote:

>
>
> On Mon, Nov 4, 2019, 7:25 PM Joe Watkins  wrote:
>
>> 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.
>>
>
> It will go a bit off topic however let me take another real example.
>
> In Brunai, lgbt* lost all their rights. Promotions, many areas are
> affected if not all. one will break the law one or another by helping or
> doing some activities with "proven" LGBT.
>

-promotions


> In 1930s and later, everything done to the Jews and other communities were
> followed the laws.
>

+In Europe


> What I seriously question, and this is a debate we sadly have to have
> these days, is our stand about all laws being promulgated in so many
> countries, laws that would raise revolt or more in most of my or your
> countries.
>
> The not so dramatic case in spain belongs to that as well. Btw.
>
> best,
>
>
>> > 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  wrote:
>>
>>>
>>>
>>> On Mon, Nov 4, 2019, 2:35 PM Joe Watkins  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.
>>>

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

On Mon, Nov 4, 2019, 12:54 PM Joe Watkins  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  wrote:
>
>>
>>
>> On Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei 
>> 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,
>>
>

[PHP-DEV] Re: VCS Account Request: dual

[Christoph M. Becker]

On 10.06.2019 at 02:04, Ekin Karadeniz wrote:

> Hello, my name is Ekin. I\'m senior backend developer and blog writer. I 
> would like to contribute to PHP.

Did you already contribute to the project so far?  Perhaps some pulls
requests, or other references?

Thanks,
Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: FFI & Security

[Joe Watkins]

Morning internals,

Sorry about the delay, this has now been updated.

> There was an unexpected problem communicating with SMTP: Unexpected
return code - Expected: 250, Got: 451 | 451 4.3.0 Error: queue file write
error

Because infrastructure ...

Cheers
Joe

On Wed, 30 Oct 2019 at 12:41, Christoph M. Becker  wrote:

> On 14.10.2019 at 09:44, Joe Watkins wrote:
>
> > Recently we voted on classification criteria for security bugs [1], we
> > include under "not an issue" any issue that "requires invocation of
> > specific code, which may be valid but is obviously malicious".
> >
> > I would like to add an explicit clause under the "not an issue" section
> for
> > anything related to FFI.
> >
> > It hardly seems worth it to run an RFC, although I'll be happy too if
> there
> > is a single dissenting voice.
> >
> > If there are no objections, I'll modify the document 7 days from today
> > (Monday 21st October).
> >
> > Cheers
> > Joe
> >
> > [1] https://wiki.php.net/security
>
> What is the status here?  It seems the security classification document
> has not yet been updated.
>
> Cheers,
> Christoph
>

Re: [PHP-DEV] GitHub RFC workflow

[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  wrote:

>
>
> On Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei  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,
>

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Dmitry Stogov]

Hi Dik,

On 11/3/19 12:44 AM, Dik Takken wrote:
> On 25-10-19 12:22, Nikita Popov wrote:
>> For reference, here are the results I get with/without JIT:
>> https://gist.github.com/nikic/2a2d363fffaa3aeb251da976f0edbc33
> 
> I toyed a bit with the benchmark script (union_bench.php) as well and
> wanted to share some observations. First of all I noticed the benchmark
> script has a typo on line 90 where it is calling the wrong function. It
> should read:
> 
>func6(1, 2, 3, 4, 5);
> 
> When running the corrected script I see that adding 5 argument type
> checks and a return type check cause almost 4x slowdown. My results
> (with opcache / jit):
> 
> func($a,$b,$c,$d,$e)   0.6800.583
> func(int $a,$b,$c,$d,$e): int  2.1062.009

Thanks for catching this. At least, now I see 2 times slowdown without 
JIT, that I expected, but didn't see.

func($a,$b,$c,$d,$e)   1.7461.555
func(int $a,$b,$c,$d,$e): int  3.6473.455

JIT will able to eliminate type checks only if it exactly knows the 
called function at caller site. Unfortunately, this is quite rare case, 
because the functions may be declared in different files, OOP, type 
variance, etc.

> 
> However, this appears to be entirely due to the return type check
> lacking a JIT implementation, as pointed out by Nikita. Adding one more
> test to the benchmark shows this nicely:
> 
> func($a,$b,$c,$d,$e)   0.6750.575
> func(int $a,$b,$c,$d,$e)   0.5740.475
> func(int $a,$b,$c,$d,$e): int  2.1062.009
> 
> Now we can see that the argument type hint actually improves
> performance, I guess due to it narrowing down the number of possible
> types that need to be considered for the function arguments.
> 
> Union types allow for more accurate type hinting as well as type hinting
> in places where this is currently not possible. As a result union types
> can be used to obtain performance gains. As an example, consider the
> case where the return type hint matches the type information that
> opcache has inferred about the variable that is returned. In that case,
> the return type check is optimized away. Let us try and leverage union
> types to make this happen. From the benchmark script we take func6:
> 
>function func6(int $a, int $b, int $c, int $d, int $e) : int {
>return $a + $b + $c + $d + $e;
>}
> 
> and adjust it to read:
> 
>function func6(int $a, int $b, int $c, int $d, int $e) : int|float {
>return $a + $b + $c + $d + $e;
>}
> 
> Now the return type hint matches what opcache infers the result of the
> expression will be and the cost of return type checking disappears
> completely:
> 
> func($a,$b,$c,$d,$e) 0.6630.568
> func(int $a,$b,$c,$d,$e) 0.5740.475
> func(int $a,$b,$c,$d,$e): int|float  0.5610.466
> 
> Then, on to another observation. The SSA forms currently produced by
> opcache show union types like string|int. This suggests that opcache
> supports union types for type inference already. It explains why opcache
> can nicely optimize type checks away even when union types are used.
> 
> This is not true for unions of classes though. A union type like int|Foo
> copies into the SSA form just fine while Foo|Bar becomes 'object'. Code
> like this:
> 
>class Foo {}
>class Bar {}
> 
>function func(): Foo|Bar {
>return new Foo();
>}
> 
>func();
> 
> produces the following SSA form:
> 
>func: ; (lines=4, args=0, vars=0, tmps=1, ssa_vars=2, no_loops)
>; (before dfa pass)
>; /php-src/sapi/cli/test.php:6-8
>; return  [object]
>BB0: start exit lines=[0-3]
>; level=0
>#0.V0 [object (Foo)] = NEW 0 string("Foo")
>DO_FCALL
>VERIFY_RETURN_TYPE #0.V0 [object (Foo)] -> #1.V0 [object]
>RETURN #1.V0 [object]
> 
> which will still perform a return type check even though the return type
> hint matches the actual type of the variable. Apparently the union type
> support in opcache is present but incomplete.
> So, while union types can incur higher type checking cost they also
> provide more powerful means to help type inference and improve
> performance. As opcache improves over time I think we can expect the
> cost to decrease while the gain increases. Or am I too optimistic here?

In my experience, static optimizations are not able to eliminate most 
type checks in PHP. Probably, if we developed more complete type-system 
and used type declaration everywhere we could achieve better results.
Introducing more type checks and more complex rules will increase 
run-time overhead.

I'm currently working on attempt of speculative optimizations based on 
run-time feedback, and the results might change the whole picture a bit.

Anyway, I'm especially against of mixing multiple classes in unions, not 
because of performance, but because of complex rules of method 
inheritance compatibility checks in conjunc

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

On Mon, Nov 4, 2019, 2:35 PM Joe Watkins  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.

>

Re: [PHP-DEV] GitHub RFC workflow

[Johannes Schlüter]

On November 4, 2019 8:35:16 AM GMT+01:00, Joe Watkins  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Add WeakMap

[Nikita Popov]

Hi internals,

This is a follow up to the addition of WeakReference in PHP 7.4.
WeakReference is an important primitive, but what people usually really
need are weak maps, which can't be implemented on top of WeakReference (at
least, not as exposed in PHP).

This RFC proposes to add a native WeakMap type for PHP 8:
https://wiki.php.net/rfc/weak_maps

Regards,
Nikita

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

On Mon, Nov 4, 2019, 7:25 PM Joe Watkins  wrote:

> 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.
>

It will go a bit off topic however let me take another real example.

In Brunai, lgbt* lost all their rights. Promotions, many areas are affected
if not all. one will break the law one or another by helping or doing some
activities with "proven" LGBT.

In 1930s and later, everything done to the Jews and other communities were
followed the laws.

What I seriously question, and this is a debate we sadly have to have these
days, is our stand about all laws being promulgated in so many countries,
laws that would raise revolt or more in most of my or your countries.

The not so dramatic case in spain belongs to that as well. Btw.

best,


> > 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  wrote:
>
>>
>>
>> On Mon, Nov 4, 2019, 2:35 PM Joe Watkins  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.
>>
>>>

Re: [PHP-DEV] GitHub RFC workflow

[Côme 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GitHub RFC workflow

[Pierre Joye]

On Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei  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,