Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Den tir. 10. sep. 2019 kl. 13.14 skrev Rowan Tommins : > That's a reasonable point; that (and the inverse: governments blocking > access to github in response to some perceived offence) would be a > potential issue to weigh up against the risks of running our own > infrastructure. We are already under the US law when it comes to distribution of software as our binaries (like Windows) which contains encryption software for export since we potentially allow countries which the US have an embargo with, such as Iran (or more recently Venezuela). If I remember correctly its partly the reason why PHP is registered as an entity in the US to comply with EAR. How this is dealt with under the hood of the project and all of that I have no idea, but even as it is, we are not currently operating in a noman's land and already live with restrictions imposed by the governments of the world. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Tue, 10 Sep 2019 at 10:39, Lynn wrote: > > Are you aware of any heavy-handed moderation on github, or is this, again, >> a hypothetical problem? >> > > As much as I like Github for these kind of things, we're forgetting about > a critical part here; The US trade restrictions. Github being a company in > the US, is required to block certain access to users from certain countries. > That's a reasonable point; that (and the inverse: governments blocking access to github in response to some perceived offence) would be a potential issue to weigh up against the risks of running our own infrastructure. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Tue, Sep 10, 2019 at 11:02 AM Rowan Tommins wrote: > On Tue, 10 Sep 2019 at 08:37, Côme Chilliet wrote: > > > It’s not the same when the project can act to fix it and when the project > > is powerless. > > If github blocks someone from commenting we cannot do anything about it. > > > Are you aware of any heavy-handed moderation on github, or is this, again, > a hypothetical problem? > As much as I like Github for these kind of things, we're forgetting about a critical part here; The US trade restrictions. Github being a company in the US, is required to block certain access to users from certain countries. Regards, Lynn van der Berg
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Tue, 10 Sep 2019 at 08:37, Côme Chilliet wrote: > > > PHP have no control over github, and cannot know how it will evolve. > > > > > > (they can change the platform tomorrow and internal won’t be able to > do anything about it). > > > > Those are hypothetically problems. But they do not appear to be > > currently problems. > > The fact that PHP has no control over github is current, this is not > hypothetical. > The idea that the platform will change overnight in a way that makes it unusable by the project is hypothetical. > It’s not the same when the project can act to fix it and when the project > is powerless. > If github blocks someone from commenting we cannot do anything about it. > Are you aware of any heavy-handed moderation on github, or is this, again, a hypothetical problem? As you will see from my other responses on this thread, I'm not totally sold on github in particular, but I can see pros and cons more generally: - our own systems, fully in our control, but used by nobody else, and managed by a handful of volunteers - or: a well-established third-party system, which could change in unpredictable ways, but is widely used, and supported by hundreds of paid staff Even the mailing list relies on third-party software; I presume it gets updated regularly, and those updates could include changes in functionality we disagree with. There is a pragmatic decision to be made between building absolutely everything from scratch, and trusting some third parties, with contingency plans if that trust proves ill-founded. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Le vendredi 6 septembre 2019, 16:47:52 CEST Nikita Popov a écrit : > * GitHub would not be the exclusive venue for RFC discussion. All RFCs are > still announced on internals and the top-level discussion can and should > still happen here. My remark on the mailing list regarding string|true was unanswered and I had to go over to github to see that the concern was discussed there. This is the kind of problems splitting the discussion will cause, people will have to check both places or miss things. Regarding the github PR as a practical point of view, I find it hard to check if there are new messages since last time I visited the page. Is there any way to browse messages by time? (backwards ideally). Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Le jeudi 5 septembre 2019, 13:07:28 CEST Dan Ackroyd a écrit : > On Thu, 5 Sep 2019 at 12:27, Côme Chilliet wrote: > > > > PHP have no control over github, and cannot know how it will evolve. > > > > (they can change the platform tomorrow and internal won’t be able to do > > anything about it). > > Those are hypothetically problems. But they do not appear to be > currently problems. The fact that PHP has no control over github is current, this is not hypothetical. > And in case anyone says "some people might not be able to comment on > Github" the same is true for our email lists. The signup process was > apparently broken for ages, and I've seen multiple people ask for how > to persuade the system to accept their messages. Which probably means > there are more people who never contributed because they couldn't get > past that first barrier. It’s not the same when the project can act to fix it and when the project is powerless. If github blocks someone from commenting we cannot do anything about it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On 8 September 2019 11:42:07 BST, Brent wrote: > - We could add community guidelines, clearly stating that RFC comments >should stay on topic > - People could be appointed to moderate the comments, allowing >contributors to focus on the code instead of community management > - Conversations on GitHub can be locked as a last measurement. >Repository members can still comment. > >I fear that separating the main discussion from the PR will cause >unnecessary confusion: important, generals remarks could be made on the >"main thread", and I think there's value in keeping these remarks >together with everything else. I'm sceptical of that as a solution for two reasons: Firstly, the conversations weren't necessarily wrong, they were just a slight drift of topic. The problem is not removing them from the PR, it's encouraging them to move somewhere else. I fear that saying "sign up to the mailing list and repeat that point in a completely different format" will be taken up less than "make a new thread on this same list/forum". Secondly, the problem is partly a technical one: GitHub PRs have very poor support for replies and sub-threads, so even on-topic discussions that don't relate to a specific part of the text are hard to follow. I think Nikita's suggestion is a good one: use a PR for making targeted suggestions to the RFC text itself, but raise the general points on the main list. That might even include saying "I've added a handful of suggestions relating to X" and discussing the wider issue that links them. I agree it would be interesting to experiment further, and I think this hybrid approach would be a good one to try next. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Happy to read your thoughts on this Nikita, I think you've drawn some good conclusions. If I may add a thought or two: I wouldn't make any final decisions based on one experiment, especially a big RFC as this one. I think the GitHub discussion got extra attention because it was the first one, and because of the scope of the RFC. I would try to have two or three more RFCs discussed on GitHub, maybe smaller ones? Second, there are more things we can do in order to keep the main thread on topic. Three things come to mind: - We could add community guidelines, clearly stating that RFC comments should stay on topic - People could be appointed to moderate the comments, allowing contributors to focus on the code instead of community management - Conversations on GitHub can be locked as a last measurement. Repository members can still comment. I fear that separating the main discussion from the PR will cause unnecessary confusion: important, generals remarks could be made on the "main thread", and I think there's value in keeping these remarks together with everything else. Kind regards Brent On 6 Sep 2019, 16:48 +0200, Nikita Popov , wrote: > Here are my own thoughts on how the pull request discussion for union types > went... > > I think the main takeaway for me is that inline comments (on specific lines > in the RFC) were really invaluable. Each comment thread discussed a > specific issue and most of them have resulted in a direct improvement to > the RFC. > > Generally there was a lot of discussion of specific technical details that > we very rarely see in RFC discussions. Current RFC discussions on the > mailing list tend to be rather high level (which is fine in itself), with > nobody ever discussing the details (which is very bad). > > Thinking back to https://wiki.php.net/rfc/engine_warnings, I think that RFC > could have really benefited from this discussion medium. While the mailing > list discussion ended up talking circles around more or less one single > question (undefined variables), pretty much none of the other parts of the > RFC have seen so much as a comment. I'm sure that there would be a lot more > discussion regarding specific classifications if this went up as a pull > request. > > Another nice thing is that it's possible to mark a comment thread as > resolved, once the RFC has been adjusted to address the comments. That way > you don't have to see issues that were already addressed (though you can if > you like). > > Having thumbs-up and thumbs-down reactions to comments was also helpful to > judge whether some comment represents a minority opinion or not, something > that is notoriously hard with current mailing list discussions (which are > almost dominated by "negative" opinions which mysteriously don't show up in > voting results). > > However, while the inline comments were pleasantly insightful, the same > cannot be said for the top-level comments on the pull request. The majority > of them was borderline off-topic. While some in principle interesting > discussion happened there, it simply didn't belong in the RFC thread for > union types. The top-level comments also suffered from a lack of threading > -- I would have been less bothered about tangential discussions if they > were threaded. (To be fair: I use gmail, so I don't get threading on the > mailing list either.) > > If this kind of discussion behavior is representative, then I would suggest > a workflow alone the following lines... > > * RFCs are submitted as PRs on GitHub, but must be announced on the mailing > list. > * The PR description should have a fat warning that top-level comments > belong on the mailing list. We can mark all top-level comments on PRs as > "off-topic" as a matter of general policy. > * Top-level commentary stays on the mailing list. > > This is a shift from what I originally had in mind (completely moving the > RFC process to GitHub), towards providing a way for more detailed and > specific feedback on the RFC text. > > Regarding GitHub as a 3rd party. I think there are a few things to > considered: > * We're already very heavily reliant on GitHub. Most of my day-to-day > interaction with PHP core development is via GitHub and most of the > day-to-day decisions also happen there. Only the major stuff everhits this > mailing list. > * The RFC repo would of course be hosted on git.php.net as usual and only > be mirrored to GitHub. > * GitHub would not be the exclusive venue for RFC discussion. All RFCs are > still announced on internals and the top-level discussion can and should > still happen here. > > Disclaimer: I'm trying to draw conclusions here from an experiment with a > sample size of 1, which may not be representative. Union types are a pretty > significant proposal (and also the first one to be on GH), and other, > smaller proposals might well have different discussion dynamics. > > Regards, > Nikita > > On Thu, Sep 5, 2019 at 12:22 PM Côme Chilliet wrote: > > > Le jeudi 5
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Here are my own thoughts on how the pull request discussion for union types went... I think the main takeaway for me is that inline comments (on specific lines in the RFC) were really invaluable. Each comment thread discussed a specific issue and most of them have resulted in a direct improvement to the RFC. Generally there was a lot of discussion of specific technical details that we very rarely see in RFC discussions. Current RFC discussions on the mailing list tend to be rather high level (which is fine in itself), with nobody ever discussing the details (which is very bad). Thinking back to https://wiki.php.net/rfc/engine_warnings, I think that RFC could have really benefited from this discussion medium. While the mailing list discussion ended up talking circles around more or less one single question (undefined variables), pretty much none of the other parts of the RFC have seen so much as a comment. I'm sure that there would be a lot more discussion regarding specific classifications if this went up as a pull request. Another nice thing is that it's possible to mark a comment thread as resolved, once the RFC has been adjusted to address the comments. That way you don't have to see issues that were already addressed (though you can if you like). Having thumbs-up and thumbs-down reactions to comments was also helpful to judge whether some comment represents a minority opinion or not, something that is notoriously hard with current mailing list discussions (which are almost dominated by "negative" opinions which mysteriously don't show up in voting results). However, while the inline comments were pleasantly insightful, the same cannot be said for the top-level comments on the pull request. The majority of them was borderline off-topic. While some in principle interesting discussion happened there, it simply didn't belong in the RFC thread for union types. The top-level comments also suffered from a lack of threading -- I would have been less bothered about tangential discussions if they were threaded. (To be fair: I use gmail, so I don't get threading on the mailing list either.) If this kind of discussion behavior is representative, then I would suggest a workflow alone the following lines... * RFCs are submitted as PRs on GitHub, but must be announced on the mailing list. * The PR description should have a fat warning that top-level comments belong on the mailing list. We can mark all top-level comments on PRs as "off-topic" as a matter of general policy. * Top-level commentary stays on the mailing list. This is a shift from what I originally had in mind (completely moving the RFC process to GitHub), towards providing a way for more detailed and specific feedback on the RFC text. Regarding GitHub as a 3rd party. I think there are a few things to considered: * We're already very heavily reliant on GitHub. Most of my day-to-day interaction with PHP core development is via GitHub and most of the day-to-day decisions also happen there. Only the major stuff everhits this mailing list. * The RFC repo would of course be hosted on git.php.net as usual and only be mirrored to GitHub. * GitHub would not be the exclusive venue for RFC discussion. All RFCs are still announced on internals and the top-level discussion can and should still happen here. Disclaimer: I'm trying to draw conclusions here from an experiment with a sample size of 1, which may not be representative. Union types are a pretty significant proposal (and also the first one to be on GH), and other, smaller proposals might well have different discussion dynamics. Regards, Nikita On Thu, Sep 5, 2019 at 12:22 PM Côme Chilliet wrote: > Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit : > > > Huge "no" from me on using github for discussing RFCs. > > > > Care to elaborate why? The majority seems to like it. Though I am also > curious about Nikita's experience with it, as he is the one having to > process the feedback. > > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository > is at git.php.net . > > Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
> > That's pretty much the opposite of your previous question. For one thing, > it's unanswerable without knowing the scope - e.g. would it just be for > RFCs, or all discussions? I'm thinking about a generic "forum" for all discussions that happen on the mailing lists right now, something that could be used for internals but also for other PHP mailing lists. Then, its scope can be expanded specifically for internals, to better discuss RFCs, etc., but that's not what I had in mind right now. Until we know what we're looking for, I'm really not clear why GitHub > issues should have any starting advantage over Discourse, or PHPBB, or > Trac, or Phabricator, or Bugzilla, or probably hundreds of suggestions we > could evaluate. I chose GitHub because it was mentioned several times in this thread, because it's already used to discuss PRs, and because I suspect pretty much everyone on this list either uses GitHub on a daily basis, or has at least *some *experience with GitHub issues (let's face it, I google stuff every day for many open-source projects, and most of the discussions I stumble upon are on GitHub issues/pulls), so at least we have a* starting point* that everyone knows and has learned to love or hate. Now the whole point is, if you think another software does things better, please share! Now obviously, should you hate GitHub issues from start to finish, then indeed I can understand you consider this starting point a poor choice, in this case I'd be interested to know what you dislike so much! — Benjamin
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Fri, 6 Sep 2019 at 14:14, Benjamin Morel wrote: > As a code collaboration platform, GitHub is pretty good, but it's not built >> as a discussion forum, and there are plenty of limitations to using it as >> one. > > > Could we work on agreeing on a set of requirements for such a discussion > "forum" to replace mailing lists? > That could be an interesting exercise, yes. Ideally, we should consider RFC drafting, voting, and bug tracking as well - not because we have to replace all of them with one platform, but because we might want to divide things up differently from how we do at the moment. > Using GitHub Issues as a starting point, what would you change? > That's pretty much the opposite of your previous question. For one thing, it's unanswerable without knowing the scope - e.g. would it just be for RFCs, or all discussions? Besides that, if we're going to introduce an anchor that we compare everything to, surely we should say "using the setup we have as a starting point, what would you change?" Until we know what we're looking for, I'm really not clear why GitHub issues should have any starting advantage over Discourse, or PHPBB, or Trac, or Phabricator, or Bugzilla, or probably hundreds of suggestions we could evaluate. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
> > As a code collaboration platform, GitHub is pretty good, but it's not built > as a discussion forum, and there are plenty of limitations to using it as > one. Could we work on agreeing on a set of requirements for such a discussion "forum" to replace mailing lists? That would make it easier for anyone wanting to give it a shot, to come up with a first version that has a chance to convince everyone that this is the direction we want to follow. Using GitHub Issues as a starting point, what would you change? — Benjamin
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Fri, 6 Sep 2019 at 12:31, Peter Kokot wrote: > > Plastic analogy - adding "127.0.0.1 github.com" to your /etc/hosts > file shows that developer cannot bring most of the today's (PHP) > projects to any working state without using it. That's what is meant > by inevitable because everything open source today is either on GitHub > and some minor ones scattered around custom Git repos and other Git > hosting providers. > Ah, I see. Yes, having some usage of GitHub is currently pretty much inevitable in that sense. Of course, that may change eventually, just as SourceForge fell out of favour, but that's not something we need to worry about. However, projects over a certain size generally *don't* use it as their main or only discussion platform, which is what we're talking about here. > PHP is already using GitHub. Is it moving to > something else? No, so let's not complicate things more with other > hosting providers now. > The question is not "should PHP ban the use of GitHub for any kind of activity?" it's "should PHP abandon the discussion processes it's been using for most of its history and use GitHub as a discussion forum?". As a code collaboration platform, GitHub is pretty good, but it's not built as a discussion forum, and there are plenty of limitations to using it as one. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Fri, 6 Sep 2019 at 11:11, Rowan Tommins wrote: > > On Thu, 5 Sep 2019 at 22:45, Peter Kokot wrote: > > > GitHub usage is inevitable. > > > > Did you use the wrong word here, or are you saying that, of all the > hundreds of different platforms we could investigate, there is no chance > that we would end up using something other than github? Plastic analogy - adding "127.0.0.1 github.com" to your /etc/hosts file shows that developer cannot bring most of the today's (PHP) projects to any working state without using it. That's what is meant by inevitable because everything open source today is either on GitHub and some minor ones scattered around custom Git repos and other Git hosting providers. PHP is already using GitHub. Is it moving to something else? No, so let's not complicate things more with other hosting providers now. USA political issues and embargo on some countries are indeed a reason I'm also willing to accept that PHP won't be using GitHub otherwise. For other reasons presented here, none is convincing enough to me honestly. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, Sep 5, 2019, 5:51 PM Joe Watkins wrote: > > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions > > This is obviously your opinion, but you haven't actually told us why this > is the case, and it's not at all obvious. > > > should not encourage (some would say force) people to use such platforms. > > In any case it's not a choice for the contributor, internals chooses the > medium and the contributor has to use it. Whether we force them to use a > mailing list from last century or something from this century makes no > difference with regard to choice for the contributor. I am not worrying when one uses it for draft. However anything after that should happen in the wiki and on our git as it is the correct process. I really like github, or gitlab, however int he current context, almost all contributors may lose access to github (or other US based) companies based on the US government policies or directives. Without starting a political discussion whether or not this is valid, it is definitely a big risk. A risk I am not really willing to take for php itself, if I may say. best,
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 22:45, Peter Kokot wrote: > GitHub usage is inevitable. Did you use the wrong word here, or are you saying that, of all the hundreds of different platforms we could investigate, there is no chance that we would end up using something other than github? > The interface is so good with clear discussion and review options > As my previous message, and those of several other people, show, that is far from an established consensus. The power of an e-mail list is that different users can use different interfaces - I've yet to see a forum suggested that I would find easier than Thunderbird's tree view. There are certainly downsides to e-mail, and upsides to GitHub, but let's stay calm and evaluate our options rather than jumping at the first thing we see. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Den tor. 5. sep. 2019 kl. 13.22 skrev Côme Chilliet : > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository is > at git.php.net . As an old timer around here, I feel very strongly about moving the medium and I prefer to be on the PHP.net infrastructure. Clearly one of our biggest issues with that as the PHP organization is that we poorly maintain it, and I think it could be time to rather invest into renewing that effort instead. It seems like many have an issue with subscribing to internals (I know it was broken for the longest time by using the webform), but that is something we can telegraph better on the php.net website for one thing and try to put resources into figuring this problem out to gain momentum for more developers to join the effort of internals development. Using Github for PRs and relevant discussions for that is perfectly fine with me, but switching to Github for RFCs is a big -1 from me, it is really difficult to read new comments if you are not email subscribed and even then it still remains hard to follow. The individual moderation required to also sort out irrelevant comments is also one thing I personally would not want to deal with either. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On 05/09/2019 22:45, Benjamin Morel wrote: . One thing that could be checked, is whether their API allows retrieving the whole discussion history programmatically. If so, one could setup a database to sync all messages to on a regular basis, so that the PHP project could move the discussions back to their own system should something bad happen. Certainly appears to https://developer.github.com/v3/pulls/comments/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
I've thought about this many times while reading messages on internals, but from another perspective: the inability to "+1" a message without having to reply. I very often find myself agreeing (or disagreeing) with someone, but refrain myself from posting a one-liner to show my support. Having something like GitHub reactions to be able to "+1" or "-1" a message could be invaluable to get the overall sentiment of the participants (even the silent readers) when browsing through the thread. When I browse an issue or a PR on GitHub, the reactions help me quickly see which messages stand out of the crowd, be it positively or negatively, and usually help me get quickly a good idea of what's going on there, when I don't have the time to read through every single message. IMO, replacing the mailing list with a GitHub-like discussion would bring several advantages: - no more top-posting, etc.: this would be a web app, not a dumb email software that (sometimes unreliably) quotes everything by default. - possibility to use markdown: invaluable to make a message more readable - possibility to add reactions to messages, even from silent readers - possibility to react to previous messages, for someone who just joined the list, without having to invoke ezmlm black magic Also, I think this would lower the level of entry to internals for a lot of PHP developers who aren't otherwise interested in participating in discussions, but could appreciate being able to give their opinion on the future of PHP. And for maintainers, this would represent invaluable feedback to see the sentiment from the crowd, not only from the usual suspects. Externals.io does a pretty good job, but suffers from many drawbacks that can hardly be solved: - it's still reading emails, so while it does a good job at putting everyting together quite nicely, it's sometimes confused by the syntax, especially quoting - you can vote on threads (stackoverflow-style), but not on individual messages; and because externals.io is not everyone's main way of reading through internals, this lowers the number of potential reactions - there is no way to reply to a message, you have to get back to your email - there is no real support for markdown; a few things are supported, but I find them quite unreliable and am never really happy with how my hand-crafted message looks over there Ideally, we could create a custom web app to move the discussions to. I'd love to participate in creating it, even initiate the project, if time permits. This would also allow adding interesting stuff, like user statistics, user post history, etc.) Finally, regarding GitHub, I'm personally not against moving the discussions there; I'm using it every day and find it very convenient to discuss software; I do understand the concerns expressed above though. One thing that could be checked, is whether their API allows retrieving the whole discussion history programmatically. If so, one could setup a database to sync all messages to on a regular basis, so that the PHP project could move the discussions back to their own system should something bad happen. — Benjamin
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Hello, On Thu, 5 Sep 2019 at 12:22, Côme Chilliet wrote: > > Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit : > > > Huge "no" from me on using github for discussing RFCs. > > > > Care to elaborate why? The majority seems to like it. Though I am also > > curious about Nikita's experience with it, as he is the one having to > > process the feedback. > > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository is > at git.php.net . > > Côme If I may put few random thoughts here. GitHub usage is inevitable. The interface is so good with clear discussion and review options that it would be really worthy to check it out for all PHP RFCS in the future. The main worry here is basically that one day GitHub will go offline and that discussion will be lost. Repository however will stay in the Git repo and will be "timeless". Very rarely one will want to look at the old (several 10 years) discussion comments. This is not a problem because even with having an email archive online very rarely someone will return to such discussion. RFC content is there and will be there for PHP to move "elsewhere" though if such hypothetical case comes. Tank you. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 13:05, Mark Randall wrote: > Something I am finding hard on Github, and maybe it's just because I > haven't found the option yet, is finding new posts. > Yes, so far, I've been forced to choose between two imperfect options: - follow the discussion using the e-mail notifications only, giving worse context for the sub-threads than I'd get on a mailing list - scanning all the sub-threads on the PR to see if there are new replies I haven't read yet The ability to attach sub-threads to lines in the PR is certainly useful for some types of discussion, but a lot of the longer threads would be better off with just a subject line. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 14:29, Brent wrote: > > I believe GitHub is the way to go. Several large communities manage their OSS > on it and have proven it works, PHP should simply do the same. At the risk of giving advice, you will find conversations are far more productive if you ask why something can't be done, rather than just stating it will be simple. Not only will that elicit more useful information to you, it avoids being subtly insulting, as you're implying that something will be easy and people are being stupid for not doing it*. In this particular case you could have asked "what would be the problems with moving the build systems to github?", and the answers would include: * PHP has karma (aka permissions) system which github could not support. I don't know how that could be solved/avoided. * There is very strong reluctance to be dependent on other people's infrastructure for things that could take a long time to migrate. e.g. we can move discussions from one medium to another, by just telling people to go talk over there. But for actual software CI, it's a big deal to move from one system to another. btw it's not obvious that the projects you linked actually have their build systems integrated with Github. I'm pretty sure you're making assumptions about how simple their systems are. cheers Dan Ack * in pithier form: https://signalvnoise.com/posts/439-four-letter-words -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 14:29, Brent wrote: > I believe GitHub is the way to go. Several large communities manage their > OSS on it and have proven it works, PHP should simply do the same. > I think this is just as simplistic as saying "never". What are these communities using it for, and what would we want to use it for? Are our requirements the same as theirs, and is GitHub the best solution for those requirements? For instance: - Rust does not use GitHub as its primary co-ordination mechanism, it has an online forum at https://internals.rust-lang.org/ - The ECMA TC39 committee has a specific membership structure and holds regular in-person meetings - There are undoubtedly more open-source communities _not_ using GitHub than who _are_ using it To be clear, I'm not saying these are reasons against GitHub in themselves, but it's a rather huge leap from "here are four repos I found" to "GitHub is the way to go"; we should be making specific arguments for why it will meet our needs, and evaluating it among all the alternatives. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Let's name a few examples of large OSS projects managed on GitHub: - ECMA (https://github.com/tc39) - Rust (https://github.com/rust-lang/rust) - React (https://github.com/facebook/react) - Node (https://github.com/nodejs/node) Also, let's not forget the hunderd of thousands of PHP packages hosted on GitHub. While GitHub might _in theory_ one day decide to stop, there is no way it will happen in practice, GitHub has proven itself as a reliable platform over the past ten years. On the topic of self hosted GitLab: let's not reinvent the wheel. Managing your own platform will take more manpower and resources, which are better invested somewhere else — the development of PHP perhaps? I believe GitHub is the way to go. Several large communities manage their OSS on it and have proven it works, PHP should simply do the same. Kind regards Brent On 5 Sep 2019, 15:14 +0200, George Peter Banyard , wrote: > One idea could be to use a self hosted GitLab instance, > > I'm pretty sure there are multiple ways via OAuth to connect to an > independent GitLab instance. > > This would allow to have PR like thread on PHP's own infrastructure (even > though it seems the project is pretty bad at keeping it's infrastructure up > to date) while keeping control over it. > > Best regards > > George Peter Banyard
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
One idea could be to use a self hosted GitLab instance, I'm pretty sure there are multiple ways via OAuth to connect to an independent GitLab instance. This would allow to have PR like thread on PHP's own infrastructure (even though it seems the project is pretty bad at keeping it's infrastructure up to date) while keeping control over it. Best regards George Peter Banyard
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 12:27, Côme Chilliet wrote: > > PHP have no control over github, and cannot know how it will evolve. > > (they can change the platform tomorrow and internal won’t be able to do > anything about it). > Those are hypothetically problems. But they do not appear to be currently problems. I'm pretty sure that if new problems with a medium were encountered, we could adapt to either work around them or move to a different system. And in case anyone says "some people might not be able to comment on Github" the same is true for our email lists. The signup process was apparently broken for ages, and I've seen multiple people ask for how to persuade the system to accept their messages. Which probably means there are more people who never contributed because they couldn't get past that first barrier. Actual problems I can see with having the discussion on github: i) There is no off-topic space. For example, apparently some people don't understand the RFC and could do with a brief explainer on type systems. Doing that inline to the github comments would make the on-topic discussion harder to read. ii) It means that the discussion is harder to track. However.that is already a problem. When I was putting together the info for https://github.com/danack/RfcCodex which attempts to document why certain ideas that keep coming up haven't succeeded yet, it was a massive pain trying to track email threads to the RFC. Both of those things are not really technical problems. They are documentation problems. They would be best solved (imo) by having a paid member of staff on the PHP project writing lots of words. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On 05/09/2019 12:08, Rowan Tommins wrote: but at least views like externals.io and news.php.net can let you navigate the tree. The lack of a full tree-like structure isn't the worst thing in the world. If only because it discourages certain types of individual from wanting to reply to every single sub-branch individually to get the final word. Something I am finding hard on Github, and maybe it's just because I haven't found the option yet, is finding new posts. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Le jeudi 5 septembre 2019, 12:50:48 CEST Joe Watkins a écrit : > > Because the PHP project should avoid depending on a privately owned > > centralized service for its technical discussions > > This is obviously your opinion, but you haven't actually told us why this > is the case, and it's not at all obvious. I thought it was obvious, sorry. So, the problem is PHP have no control over github, and cannot know how it will evolve. GAFAM organizations have closed people accounts before, sometimes without giving reasons. I think PHP project should not let other organisations choose who can or cannot participate in PHP development. > > should not encourage (some would say force) people to use such platforms. > > In any case it's not a choice for the contributor, internals chooses the > medium and the contributor has to use it. Whether we force them to use a > mailing list from last century or something from this century makes no > difference with regard to choice for the contributor. With a mailing list the contributor can choose its email server and email client. He does not have to agree to term of service of a third party. https://tosdr.org/#github With github, internal chooses to delegate to github, and github (currently microsoft) chooses who can take part in the discussion and how the discussion works. (they can change the platform tomorrow and internal won’t be able to do anything about it). Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
On Thu, 5 Sep 2019 at 11:22, Côme Chilliet wrote: > Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit : > > > Huge "no" from me on using github for discussing RFCs. > > > > Care to elaborate why? The majority seems to like it. Though I am also > curious about Nikita's experience with it, as he is the one having to > process the feedback. > > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository > is at git.php.net . > The "privately owned" and "centralized" parts don't bother me particularly, but there's potentially an issue in splitting the discussion between multiple platforms, with different logins required. An example of this is the discussion on this RFC about type aliases - Nikita requested it to be split into a separate discussion, but the people involved may not be subscribed to this list, and if they are, it's hard to maintain context when jumping between different forums. That conversation also highlighted a limitation of the particular platform: inline comments on GitHub PRs show as threads, but comments on the whole PR don't, so that interleaved discussions are hard to follow. Admittedly, that's true on a lot of e-mail clients as well (thanks to GMail popularising "conversations" rather than "threads"), but at least views like externals.io and news.php.net can let you navigate the tree. I wonder if a hybrid approach would work better - the RFC is a PR (perhaps against the language spec repo, as Andrea suggested) but the main discussion stays on the list. Suggestions to improve the RFC itself could be made inline on the PR by anyone who wanted to, but non-inline PR comments would be heavily discouraged so that wider comments on the proposal would stay here. Either way, I think it's interesting to experiment with different ways of working, and maybe there are other platforms we should trial as well. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
> Because the PHP project should avoid depending on a privately owned centralized service for its technical discussions This is obviously your opinion, but you haven't actually told us why this is the case, and it's not at all obvious. > should not encourage (some would say force) people to use such platforms. In any case it's not a choice for the contributor, internals chooses the medium and the contributor has to use it. Whether we force them to use a mailing list from last century or something from this century makes no difference with regard to choice for the contributor. Cheers Joe On Thu, 5 Sep 2019 at 12:22, Côme Chilliet wrote: > Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit : > > > Huge "no" from me on using github for discussing RFCs. > > > > Care to elaborate why? The majority seems to like it. Though I am also > curious about Nikita's experience with it, as he is the one having to > process the feedback. > > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository > is at git.php.net . > > Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit : > > Huge "no" from me on using github for discussing RFCs. > > Care to elaborate why? The majority seems to like it. Though I am also > curious about Nikita's experience with it, as he is the one having to process > the feedback. Because the PHP project should avoid depending on a privately owned centralized service for its technical discussions, and should not encourage (some would say force) people to use such platforms. PHP is already on github but it’s only a mirror, the main git repository is at git.php.net . Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
