I am willing to help maintain older branches of this package
nicolas-grekas opened this issue · 7 comments
The versioning policy of this package creates a lot of friction with other OSS projects.
The option to "pay for maintenance" that is advertised in the readme doesn't work for the other OSS maintainers: we do spend too much time over our weekends working around this policy. But we can "pay you" with our time.
One reason for the policy that I understand is that you don't have the resources to maintain eg a workable 2.1 branch, that would support a wider range of PHP versions, from 7.1 to upper.
The code in this repo is great and I certainly do not want to duplicate the effort.
I see only two solutions to the current situation:
- maintain a fork that I would spend part of my OSS time syncing with this one. I'd backport patches to make them work on PHP >=7.1. I did it on my last weekend and that was pretty easy, so this looks sustainable on my side. Many Linux distributions do a similar thing already, maintaining their fork in a way that fits their policies.
- become a co-maintainer of this repo, especially responsible for supporting a wider range of PHP+Composer versions. Thus this issue.
The third option, which is accepting the existing policy, is too painful. See also similar discussions around the package-versions package. I wish there was more cooperation between OSS maintainers. That also means between you and me.
As I posted elsewhere, I admire your work at many levels. I'm just sooooo annoyed by the policy (and I know I'm not the only one) that I want to do something about it. Please help us.
@nicolas-grekas FWIW, I really appreciate this as a much better and more cooperative way of reaching out for discussion, kudos 👍 so much better!
It is a bit sad that the new holy war of the PHP ecosystem is now system version requirements.
I do agree that in an ideal world, we are always everywhere on the newest version.
In reality there are various constraints, be it being required to be on a LTS version, having business requirements not leaving time to work on upgrades for a longer while, using some software which is actually outdated and does not yet work on a newer version, ...
And then it's supremely annoying to not being able to regularly install the newest version of the package containing crucial fixes or features.
I wish we could have an ecosystem-wide consensus on how much to push it. I am strongly in favor of having at least a branch with regular bugfixes for a fixed period of time after the release of a PHP version throughout the ecosystem. That way support windows would also be much more predictable.
Maybe that period is just 2 years, maybe we'll find 4 years to work out better. 2 years would be the active bugfixing window of PHP itself. 4 years is the (sec) bugfixing window of e.g. Ubuntu LTS releases.
Fortunately PHP is largely backwards compatible, and mostly, keeping compatibility is just not using the newest features (which happens to be anyway the case often, there are quite some packages requiring 7.3 right now, but still working fine under 7.1), the effective overhead is typically quite negligible.
Another possibility would be adding a possibility in composer itself to add some repository as fallback for the "default" repository if version constraints are impossible to fulfil with the default. So that, when another OSS contributor wishes to extend support to other versions, adding polyfills for system deps or such, he is able to provide it for everyone without much hassle.
On the other side I am hypothesizing there are also financial interests on the open source maintainers and they are more likely to be asked for support on a 2 year old version than a 4 year old one. I hope this is an irrelvant point, but possibly needs to also be considered...
[As a side note @nicolas-grekas forking was fine (that's what open source empowers you to), but not putting it under an org name mocking Marco (even if not intended that way)... But for sure bringing the topic to a constructive issue is better :-)]
putting it under an org name mocking Marco (even if not intended that way)
Just to clarify this (but please don't make this the topic of this issue), I created the org a few months ago and @Ocramius was aware of its existence; he commented on a PR I then created and didn't raise any issue about the name at the time. It was a funny tribute to me, nothing more. But yes, I get that intentions and receptions are two different things, sorry if ppl's feelings (esp. Marco) were hurt by that aspect.
I guess I should go with option 1.?
Hi @Ocramius,
I may be wrong, but I'm interpreting your silence as a way of telling me that you don't want to have a branch with another policy than the one you decided to use here. That's totally fine to me of course. Tell me if I made a mistake btw.
Based on this interpretation, I plan to create and maintain a fork of this repo under the FriendsOfPHP organization. The package should be named friendsofphp/proxy-manager-lts. Of course, this fork would not accept bugfixes/features without first asking them to be fixed/implemented upstream - aka on this very repo.
Open-source dynamics FTW.
TL;DR: (for the people that mostly upvoted/liked the convos above)
- I've written a more formal policy on dependency upgrades and why I do them
- I've written a "why I do OSS", which is in direct conflict with what is asked by OP
- there's already a policy on bugfixes in old releases, but it's now spelled out in my support policy
Addressing #630 (comment) (OP)
Ok, first of all, sorry for not reacting to this: the amount of people and interactions that stressed me over the entire absurdity of supporting ancient dependency versions (specifically PHP and composer) caused me some serious nervous problems, and I therefore muted all topics and took refuge in videogames for a while.
After searching for support with people I hold dear, and talking in-depth about this, I am now taking the time to answer.
That said, I did initially consider to "shoot this down" by saying "I hate symfony's maintenance policy" and stuff like that. I'm glad I didn't, because now I wrote down a precise maintenance policy at ocramius/.github.
The versioning policy of this package creates a lot of friction with other OSS projects.
This is intentional, with the final aim to make the ecosystem shift to newer dependencies, instead of relaxing dependency ranges. Too many times I've encountered tech teams where the step of upgrading dependencies comes at a high price due to management/politics pushing it back, and I do use my power on this end of the stick to transform this problem into a lever that can be used by tech teams to prioritize these upgrades. This is described in my dependency upgrade policy, and I will stick to it.
The option to "pay for maintenance" that is advertised in the readme doesn't work for the other OSS maintainers: we do spend too much time over our weekends working around this policy. But we can "pay you" with our time.
I've revised this too: indeed, being paid to do OSS would be nice, but it also goes against the reason why I do OSS and these versioning polices. In fact, the friction and negative interactions I had here and on twitter came from people that are paid to work on OSS, which is an interesting data-point. There have been numerous interactions in which people keep pushing company problems into OSS problems that are out of my problem-space by decision.
What I've done is an introspection on "why do I do open source", what my goals are, and what to expect, and I wrote it down in https://github.com/Ocramius/.github/blob/master/why-i-do-open-source.md
That clarifies that I'm indeed not in for the money, but to express my opinion on how things should be done, even if it goes against giants like symfony, with whose approach I grew more and more divergent, especially since you (@nicolas-grekas) started controlling it more and more. We diverge on opinions, but I'm fighting on my turf for my turf over here, and since 7.1 I've sticked to this dependency policy precisely because I do have evidence (although behind NDA) that it helps tech teams achieve beautiful transformations.
One reason for the policy that I understand is that you don't have the resources to maintain eg a workable 2.1 branch, that would support a wider range of PHP versions, from 7.1 to upper.
I don't want this to happen, basically: you are free to fork and to do it, but I explicitly DO NOT WANT to support older releases. If you are on an older PHP version, your pressure should be in upgrades, not in pushing your problem into upstream libraries. Even if you proposed to help and work on it, I would still ultimately reject the patches, because they go against https://github.com/Ocramius/.github/blob/6d4561515513f6d59fb144d838971d4a7715e3e4/version-support.md#dependency-upgrades
Me stirring so much noise in the ecosystem shows that I do have a voice in this, but it's being stepped upon by people that didn't try to reach out and try to understand that this approach does help.
you don't have the resources
Saying this was a mistake on my end: work is happening, and it's proceeding quite alright, but I do not have the nerves to fight with angry and salaried OSS maintainers, especially if they try to push their unhealthy/unrealistic LTS maintenance efforts onto everyone else. I would totally do LTS if someone were in to pay me 10kEUR/year, but it's not for the time, it's literally a bribe.
maintain a fork that I would spend part of my OSS time syncing with this one. I'd backport patches to make them work on PHP >=7.1. I did it on my last weekend and that was pretty easy, so this looks sustainable on my side. Many Linux distributions do a similar thing already, maintaining their fork in a way that fits their policies.
If you really want to go that way, you do certainly not have my approval, but you are free to do so under the permissive licenses that this package is released under.
become a co-maintainer of this repo, especially responsible for supporting a wider range of PHP+Composer versions. Thus this issue.
I appreciate the wish to help, but we're doing fine: I have @malukenho as co-maintainer (and designated heir) to this repo, should something happen to it, and bugs and maintenance, including support on newer versions, is being worked on when we can.
In addition to that, I do not like the way you operate, since you and I already had interactions (on this repository specifically) where symfony monkey-patched a fix that never got merged here due to lack of testing or patience. In practice: OSS is the corner of my life where I am allowed to not cut corners, and in contrary you are cutting corners regularly, and that's where we simply wouldn't agree.
The third option, which is accepting the existing policy, is too painful. See also similar discussions around the package-versions package. I wish there was more cooperation between OSS maintainers. That also means between you and me.
Cooperation has been there, but effectively there is a mismatch between what my beliefs are, and what other people's beliefs are. People can't really come here and push their opinion on me, after I've explained exactly that this friction is introduced on purpose. I'd defer further discussions on this topic on the dependency upgrade policy documentation, but they need to be based on how to push my agenda while still following your needs, rather than ignoring the reasons why I do OSS.
As I posted elsewhere, I admire your work at many levels. I'm just sooooo annoyed by the policy (and I know I'm not the only one) that I want to do something about it. Please help us.
That's OK - my suggestion is to start releasing minors with more restrictive dependency ranges also in your projects, or else helping me in advertising people to upgrade their dependencies in a more speedy way, instead of letting projects decay due to 5 years old deps. Should we achieve that together with more permissive ranges, then I will certainly help with the cause, but right now I am indeed using my technical capabilities to push what I believe in.
Addressing #630 (comment) (@bwoebi's comment)
There's nothing blocking you from using an older version of ocramius/proxy-manager. In fact, 2.0.2 works just fine with PHP ~7.0.
Line 22 in 001e730
(as a side-note: interesting how both PHP 7.0.6 and 7.4.6 were totally broken :D)
Every minor release bumps dependencies by introducing new features, and that's fine, since security issues will be handled for anything that is still supporting 7.3 or newer, according to PHP's own security policy.
I've written about it in my support policy, but TLDR critical bugs get fixed in old branches, where still in use.
Generic bugs should (IMO) not even be in LTS, since they destabilize everything, and I already encounter this problem often when working on symfony-related projects.
Addressing #630 (comment) (@nicolas-grekas')
It was a funny tribute to me, nothing more.
Sorry about my burst of emotions there: it's a topic that I hold very dear, and it pisses me off so much to see that there's so little understanding for the amount of care I put into it (yes, also including the additional dependency restrictions).
Some people got as far as saying that "I don't care", which is something that literally broke me for some hours.
To conclude
- dependency upgrades will keep being applied as before: it's a sensible choice, and it has been a problem only because some "giants" made a ridiculous noise about it (yes, I tickled the dragon), for something that would otherwise have been as easy as "just keep doing your regular upgrades"
- there is already some sort of "LTS" in place, and I do apply it when critical stuff comes up
- we disagree on context and philosophy, and therefore I cannot have you being a co-maintainer on this repo. I already have @malukenho helping out when/if I'm incapacitated.
- you are free to fork the repo, but you are only achieving nullifying my efforts to improve the ecosystem, since we disagree on what "improving" means
Thank you for your answer @Ocramius.
I understand that this is a sensitive topic for you. You put a lot of effort into building this package and I totally get why this discussion is stressful for you.
I apologize that some of my actions made you feel bad. I’m certainly not happy about that and it was never my intention. The interactions we have on this topic, either on Twitter or on Github, cause me a lot of stress too. I don’t like that feeling at all and I don’t wish that feeling on anybody.
I appreciate that you took some time to elaborate and clarify your thoughts. I've read your "CoC", "why I do OSS", "policies" and I appreciate your frankness. It's pretty clear to me that I cannot abide by these rules and I think many others will think the same. I don't mean that the rules are bad. They're just too wild to me: you make it clear that this is your playground and that's a "take all or leave" offer. Fortunately, you also choose to put your work under a permissive OSS license and as you might have noticed already, I've decided to repackage it under "friendsofphp/proxy-manager-lts". This is my way to "put my OSS-time where my mouth is" and free you from having to take care of extra considerations you explicitly reject.
Having solved the issue I had, I'm happy to contribute here again. I know it's hard because you have super high standards of CI checks and test coverage, but that's fair: I always prefer contributing upstream instead of monkey-patching when my fixes can bubble down to my use cases. That's the case now. Thanks for considering my modest PRs.
Our fundamental disagreement can be summarized as you thinking that narrow ranges for core dependencies (PHP / composer) are best, vs me thinking that wider ones are. I don't expect to change your mind on the topic, but I can shed some light on why I have this opinion: wide ranges enable ppl to upgrade only one dep at a time, in the order they want (either "php" or "composer" or "friendsofphp/proxy-manager-lts" in this case.) Nothing is more discouraging and risky than trying to upgrade PHP and discovering that you cannot unless you also upgrade a bazillion of other deps before. Because narrow deps create these situations, they create "market fragmentation": islands of projects that are stuck in legacy, with a very high cost to upgrade. It is my belief and experience that wider dep ranges smoothen these migrations and are actually better to achieve the same goal as yours, which I do share: having projects as up to date as possible.
Last but not least, I sincerely value diversity of thoughts more than my own thoughts, so I'd like to say thank you for pushing the boundaries of what ppl do in PHP. This is an inspiration for many, no matter the policies around your contributions.