Re: [PHP-DEV] PHP 8.2 Release Manager Selection
Hello Internals, I would like to support Eric Mann's efforts as release manager. I've followed Eric's work for several years now and have been fortunate to meet in person at various conferences. I believe he would be an asset to the PHP project as a release manager. On Tue, May 3, 2022 at 8:25 PM Ben Ramsey wrote: > > On May 3, 2022, at 12:23, Aaron Junker wrote: > > > > Hi all, > > > > The week, where applications were open is over. And I also saw the > available candidates already got mentioned on the wiki page of PHP 8.2. So > I'm curious when will voting start and how long will it last? > > > > Thanks in advance > > > > Aaron > > > Our release manager selection process doesn’t specify a timeframe during > which applications should remain open, and Christoph didn’t specify any > dates/times in his initial email[^1]. In the past, we’ve left the > application period open for over a month or longer[^2]. > > However, given the late start to this process and the impending approach > of the first 8.2 alpha, we’ll speed things along a bit. > > According to the Release Process RFC[^3], “a week between the last call > and the vote should be sufficient.” > > **Consider this the “last call” for volunteers.** > > We will close applications on 10 May and open the polls for voting for one > week, with voting closing on 17 May. This will give the new RMs just under > a month to prepare for the Alpha 1 release on 9 June. > > Earlier, Joe tossed his name into the hat as the veteran RM “if no other > veteran comes forward.” He and I have discussed that it might be a good > practice to have one of the rookie RMs from the current release serve as > the veteran for the next release. In this way, any new advances or changes > to the process will be carried forward to the “next generation” much more > smoothly. (Please note, we’re not making this a formal rule. If we want to > codify this as a requirement, someone will make an RFC.) > > With that in mind, I’m volunteering as the veteran RM for 8.2. This > shouldn’t stop other veterans from volunteering. If that happens, we’ll > vote on the veteran RM, as well as the rookie. > > Best of luck, everyone! > > Cheers, > Ben > > > [^1]: https://externals.io/message/117595#117595 > [^2]: https://externals.io/message/113334#113334 > [^3]: https://wiki.php.net/rfc/releaseprocess#release_managers_selection > -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
On 8/14/2020 09:34, Paul M. Jones wrote: (That presumes the need for the RFC even exists, which I submit it does not -- but that's a separate topic.) The most frustrating part of this entire bike shed and devolution into finger pointing of rule breaking could have all been avoided if Internals had a proper governing body which was capable of empowering release managers to make a decision that the 2nd runner up of the Short Attribute Syntax RFC should have been used when the original implementation raised several questions after the vote. Internals needs governance and the ability to empower decision makers. And a code of conduct (The Python CoC is quite fantastic), but I digress, as to not cause too many simultaneous aneurysms. "The bike shedding will continue until morale improves" Joe Ferguson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Sun, Aug 2, 2020 at 10:11 AM Derick Rethans wrote: > On Thu, 30 Jul 2020, Benjamin Eberlei wrote: > > > I think it has become clear that we need to revisit this syntax question > > again, including the elephpant in the room of delaying this feature to > 8.1. > > > > The reason is not only Joe's desire to revote on #[], but also that there > > are now more syntax proposals such as @[] by Derick or @@ in comments by > > Tyson (though no patch exists for it yet). At this point a lot of > syntaxes > > are potentially viable (except single @, please don't suggest it). > > > > I feel the choice between many syntaxes is 80% subjective, 20% objective > > facts, so tensions are to be expected. > > > > As the author of the original RFC and patch, I hope I have some klout in > > suggesting the following procedure (RMs would need to extend their > approval > > for revote to this). > > This seems like a sensible solution. > > cheers, > Derick > Sounds good to me as well. I'll update this RFC to Declined. Thanks, everyone for the discussion and everyone who reviewed the RFC and gave feedback on ideas and code examples. -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei wrote: > I think it has become clear that we need to revisit this syntax question > again, including the elephpant in the room of delaying this feature to 8.1. > > The reason is not only Joe's desire to revote on #[], > > No, I *do not* want to revote. This RFC simply takes a formal approach to approve the syntax that came in 2nd based on concerns raised with the @@ syntax. Now that it seems the technical concerns around @@ have been resolved by another pending, passing, RFC, I'm still here wanting us to talk about the impact of @@ on static analysis tools. Apparently, internals doesn't care about these projects. I care and I'm trying to help. I'm not trying to revote until I get the vote I want. I'm just a dude that had some free time while on vacation when he saw a chance to contribute. I see two possible outcomes: Release Managers collectively should decide what we do to move forward. Either accept @@, we'll decline this RFC and we can move on to the next nearest bikeshed. OR If Release Managers don't want to, or can't collectively make a decision then this RFC should go to a vote and we'll see what 2/3s of the group want. I'm fine with either outcome. https://wiki.php.net/rfc/shorter_attribute_syntax_change -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown wrote: > > Hi Joe, > > From the perspective of looks alone I don't care much one way or the > other between @@ and #[]. However, I don't find the arguments for #[] > in this RFC very compelling, and it ignores some of the other downsides > of #[] compared to @@ that should be highlighted. Let's go through the > arguments from the RFC: > Theodore, thanks for your comments, time, and work on the Shorter Attribute Syntax RFC. I appreciate your feedback and I'm also of the mind where I don't care based on looks alone. The RFC also notes the @@ issues have been resolved by the RFC closing at the end of the month. My motivation for this RFC is based on 2 things: Firstly, the @@ syntax makes parsing harder (although not impossible) on CLI tools such as PHPCS. Therefore IMHO internals should make the best effort to avoid this when possible. Secondly, I'd like to see internals use this as a point in the future to avoid this kind of issue where we need to vote on something yet again instead of taking the runner up in a ranked-choice vote. Originally this was my main motivation until I saw the issues raised by the PHPCS users. I don't want this to become an issue of "keep voting until we get the vote we like" as Paul mentioned. This RFC is my attempt to set a precedent where internals allows itself to be some measurement more autonomous than it currently is today. And also to try to make the 8.0 upgrade process a bit friendlier to our fiends writing userland code. https://wiki.php.net/rfc/shorter_attribute_syntax -- - Joe Ferguson JoeFerguson.me osmihelp.org
[PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hello Internals, I've been working with Derick Rethans and others (thanks all!) on a Shorter Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax would be preferred over the currently agreed upon "@@" syntax for Shorter Attribute Syntax. An important part of the research that went into this proposal demonstrates how "@@" will make handling attributes more difficult for PHP_CodeSniffer (and similar tools) and shows how the alternative "#[]" syntax is more friendly for these tools. You can find the RFC https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to answer any questions as best I can. -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
On 7/28/2020 08:31, Nikita Popov wrote: However, with my RM hat on, I need to feel like we're as sure as we can be about this syntax before it's public. I'm willing to extend an additional period (up to the tagging of beta3, in just under six weeks) for a re-vote on the syntax as changing that will be less violent of a change than merging the entire implementation after branching. So, does anyone plan to pursue this? Nikita Yes. I'll have an RFC to announce shortly. Waiting on one last review before sharing here.
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
Hello, Internals, I would be happy to author an RFC on replacing @@ with #[] but based on Larry's comments it sounds like the weighted voting already solved this issue for us? We as internals just need to decide that @@ isn't a solution and defer to the next ranked vote? I'd be the first one to +1. On Wed, Jul 22, 2020 at 9:38 AM Gabriel Caruso wrote: > On Wed, 22 Jul 2020 at 14:00, Derick Rethans wrote: > > > Hi all, > > > > I know we've voted twice on this already, but are we really sure that > > the @@ syntax is a good idea? > > > > - There are lots of grumbles, both on here, room 11, as well as in the > > wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/) > > - It has the distinct possibility to cause further parsing issues, akin > > to what ended up happening with what Nikita is addressing at > > https://wiki.php.net/rfc/namespaced_names_as_token > > - There is no "end symbol" to make finding occurences easier. > > - It is a syntax *no other language* uses. > > - @ is never going to go away, so the possibility of @@ moving to @ is > > also 0. > > > > Please, let's do the sensible and use the Rusty #[...] syntax. > > > > cheers, > > Derick > > > > -- > > PHP 7.4 Release Manager > > Host of PHP Internals News: https://phpinternals.news > > Like Xdebug? Consider supporting me: https://xdebug.org/support > > https://derickrethans.nl | https://xdebug.org | https://dram.io > > twitter: @derickr and @xdebug > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > Hello Derick. > > I do understand your concerns, and I appreciate that you've reached out. > > Although we are very close to the Feature Freeze date for PHP 8.0 ( > https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for > this specific case and let you (or someone), create an RFC proposing to > change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2), > and that only! > > I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as > well. > > -- Gabriel Caruso > -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] PHP 8.0 Release Manager Selection
Hello Internals, I'd like to also throw my hat in the ring for 8.0 Release Manager. I've quietly followed internals for a couple of years and have most recently been involved with FIG as a project representative for the Phergie IRC Project. Having recently retired Phergie I've stepped back from FIG. I also am one of the maintainers of Joind.in and have release management experience in several other open source projects. My primary motivation is to learn more about the PHP internals process as well as working together with you fine folks. Thanks for the consideration! On Thu, Mar 19, 2020 at 10:27 AM Derick Rethans wrote: > Hi all! > > With the first alpha of 8.0 due in three months, I think it's time to > start the process of finding and electing release managers for the next > release of PHP. > > We are looking for two developers to take on this role. Whomsoever is > elected will be guided and helped by the previous RMs and the excellent > documentation in php-src:README.RELEASE_PROCESS. > > Candidates should have a reasonable knowledge of internals (without > necessarily being a C guru), be confident about merging pull requests > without breaking backward compatibility, doing triage for bugs, liaising > with previous release managers, and generally getting the branch in good > shape, as these are among the activities you will be undertaking as > release manager. > > Please put your name forward here if you wish to be considered a > candidate. An initial TODO page has been added to the wiki and contains > provisional dates for GA and pre-releases: > https://wiki.php.net/todo/php80 > > cheers, > Derick > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- - Joe Ferguson JoeFerguson.me osmihelp.org
