Hi,
First of all the intention of this email is to try to clarify and later
better define the current RFC process and project decision processes. The
ultimate goal is to have a single document that would define project bylaws
and except other things be a guide for new contributors to quickly get an
idea how the project decisions are done.
Currently the RFC voting in defined in [1]. This defines all necessary
details about a discussion, proposing changes and voting. However it
doesn't say anything about the actual proposals so it can be more or less
anything impacting PHP. Also it doesn't say anything about implications of
the accepting of the idea (e.g. if it needs be merged) or when it should be
used.
There is another accepted RFC about release process [2] that defines better
for what RFC should be used. Specifically it states that it should be used
for the features in the following sentence:
New features or additions to the core should go through the RFC process.
It is important to note that the RFC specifically states "SHOULD" and not
"MUST" which is something that has been probably applied to many smaller
features that didn't go through RFC over the years. It is not exactly clear
if this is actually allowed as there is a conflicting note regarding
release cycle that kind of says that the feature can get to the next
release as long as it gets accepted:
The shorter release cycle also ensures that a given feature can get into
the next release, as long as the RFC has been accepted.
This could be taken that only RFC accepted feature can go to the next
release which kind of conflict with the "SHOULD" above.
As you can see it's pretty vague and not exactly something that has been
really accepted in practice. The fact is that there is also no definition
of the feature so if we took it to the extreme, it could mean any technical
change would also need an RFC. I think we all agree that would be really
inconvenient so that's something that we should probably better clarify.
We then have rules for RMs but they are mainly based around releases. I
think it would be good to define that part as well but will leave it aside
for now as it is much clearer and less impacting the core development. The
only important thing to note is that RM decides about bugs going to the
release.
It seems that in the current definition, the RFC is just for blocking
rejected features to get to the next release rather than requiring accepted
features to be in the next release. It means if the RFC is accepted, it can
get to the next release but it does not mean that it must get to the next
release. Obviously if RFC is rejected, it means that it cannot get to the
next release.
The implication of that is that to fully accept the feature, it requires
someone to merge it and no one to revert it... It means it requires some
sort of consensus between core developers or at least no objections from
some core developers. This is largely undefined as almost always the core
developers would follow the decision in RFC but technically there is
nothing in our process that would require them to do so.
In terms of conflicts between developers, the RFC does not even have much
meaning because of the above. It could be used just as some sort of poll
and honour the decision as such but it has no deciding factor in it.
This is at least how I understand the linked RFCs so please comment if you
think that the analysis is incorrect or I missed anything. I think it would
be good to define this somewhere so we can potentially make tweaks into it
in the future.
The idea is to maybe create a single document in the wiki collecting both
linked RFCs with extended clarifications and maybe mirror it in git so the
future proposal are easier to do.
Thoughts?
[1] https://wiki.php.net/rfc/voting
[2] https://wiki.php.net/rfc/releaseprocess
Cheers
Jakub
It seems that in the current definition, the RFC is just for blocking
rejected features to get to the next release rather than requiring accepted
features to be in the next release....It means it requires some
sort of consensus between core developers or at least no objections from
some core developers.
It might be better to think of the RFC process for new features to be
a decision on "should this feature be in PHP?" rather than a "must
this feature be in PHP?".
As far as I can remember, there is a single RFC that wasn't merged in
the next planned release:
https://wiki.php.net/rfc/null_coalesce_equal_operator
The vote was passed on 2016/04/02 so 7.1 was the next release version,
but it wasn't merged until 2019/01/22 and so was in PHP 7.4.
That was due to a technical problem with the implementation - I don't
recall/understand the exact details. But it wasn't (afaik) a
controversial decision to not merge it until the patch was good
enough.
This was possible to happen because we don't require a complete patch
that is ready to merge. Ironing out all of the minor details for a new
feature is a huge amount of work (that people in userland are usually
completely oblivious to) which would increase the burden of passing
RFCs.
Seeing as one of the big long term problems PHP has, is that many
contributors stop contributing after they get burnt out by doing an
RFC, I would oppose making RFCs take more work.
Once an RFC is passed the conversation changes from whether the RFC is
a good idea or not, to being a conversation about how to best
implement it, and whether the patch has some show-stopper issues or
not.
This is largely undefined as almost always the core
developers would follow the decision in RFC but technically there is
nothing in our process that would require them to do so.
Technically correct. Though the situation where all of the core
contributors refuse to merge a PR, probably means the PR shouldn't be
merged.
The idea is to maybe create a single document in the wiki collecting both
linked RFCs with extended clarifications and maybe mirror it in git so the
future proposal are easier to do.
At the risk of being a senior programmer; what problem are you trying to solve?
I mean, clearly there have been problems that could do with clarifying:
-
when are and what types of code cleanups allowed to happen? What
notice should be given, to avoid causing work for other developers,
who might have large existant branches they've been working on? -
are pull-requests that merely add comments allowed? This is
something some long-time core contributors have strong feelings about,
which I and other people disagree strongly with, but we haven't had a
framework to discuss it without shouting.
And there are probably other non-userland affecting code maintenance tasks.
But as far as as I'm aware, there hasn't been a problem with an RFC
passing and the core contributors refusing to accept it. So please can
we discuss the exact problem you want to solve, so that we can agree
it's the right problem to solve, before suggesting solutions?
If nothing else, some problems are unsolvable by lots of documentation
and bye-laws.
cheers
Dan
Ack
Hi,
It seems that in the current definition, the RFC is just for blocking
rejected features to get to the next release rather than requiring
accepted
features to be in the next release....It means it requires some
sort of consensus between core developers or at least no objections from
some core developers.It might be better to think of the RFC process for new features to be
a decision on "should this feature be in PHP?" rather than a "must
this feature be in PHP?".
Yes this exactly what I was trying say. One of the reasons for this thread
was actually to prevent misconception that accepted RFC is a final decision
which I have feeling some voters might think.
This is essentially mainly meant for technical changes where such RFC
decision does not make any sense IMHO. Basically we decide about anything
technical in RFC that explicitly allows leaving decision of merging for
later.
As far as I can remember, there is a single RFC that wasn't merged in
the next planned release:
https://wiki.php.net/rfc/null_coalesce_equal_operatorThe vote was passed on 2016/04/02 so 7.1 was the next release version,
but it wasn't merged until 2019/01/22 and so was in PHP 7.4.That was due to a technical problem with the implementation - I don't
recall/understand the exact details. But it wasn't (afaik) a
controversial decision to not merge it until the patch was good
enough.
Just to clarify I don't have any problem with that. Personally I think the
RFC process works fine for user facing changes and proposing changes with
minimal implementation is fine in my eyes.
This was possible to happen because we don't require a complete patch
that is ready to merge. Ironing out all of the minor details for a new
feature is a huge amount of work (that people in userland are usually
completely oblivious to) which would increase the burden of passing
RFCs.Seeing as one of the big long term problems PHP has, is that many
contributors stop contributing after they get burnt out by doing an
RFC, I would oppose making RFCs take more work.
I agree and I would personally prefer not to do RFC for changes that are
not controversial. Certainly I wouldn't want to make it worse.
Once an RFC is passed the conversation changes from whether the RFC is
a good idea or not, to being a conversation about how to best
implement it, and whether the patch has some show-stopper issues or
not.This is largely undefined as almost always the core
developers would follow the decision in RFC but technically there is
nothing in our process that would require them to do so.Technically correct. Though the situation where all of the core
contributors refuse to merge a PR, probably means the PR shouldn't be
merged.The idea is to maybe create a single document in the wiki collecting both
linked RFCs with extended clarifications and maybe mirror it in git so
the
future proposal are easier to do.At the risk of being a senior programmer; what problem are you trying to
solve?
The proposed single document is not meant to solve problems but improve
things and make the rules clear and easy to find for new contributors. It
should also remove all conflicting statements and it should also make the
modification easier.
I mean, clearly there have been problems that could do with clarifying:
- when are and what types of code cleanups allowed to happen? What
notice should be given, to avoid causing work for other developers,
who might have large existant branches they've been working on?
Yes this is exactly something that should not be addresed by the RFC IMO
- are pull-requests that merely add comments allowed? This is
something some long-time core contributors have strong feelings about,
which I and other people disagree strongly with, but we haven't had a
framework to discuss it without shouting.
This is in some way the same as the above. Basically for me the main issue
is that the RFC is the only place where conflicting technical issues
between developers are decided.
I think having such framework is really something that would be great to
have. The TC proposal is such an attempt actually.
And there are probably other non-userland affecting code maintenance tasks.
But as far as as I'm aware, there hasn't been a problem with an RFC
passing and the core contributors refusing to accept it. So please can
we discuss the exact problem you want to solve, so that we can agree
it's the right problem to solve, before suggesting solutions?
As I said it was mainly about improvements and making things clear at this
stage which should allow further changes in the future. In terms of those
chnges that I would like to see is to mainly having some framework for
dealing with technical changes.
Cheers
Jakub