Re: PHP version retirement
Hi Adam, > Am 12.08.2019 um 02:17 schrieb Adam Weinberger : > > On Sun, Aug 11, 2019 at 5:50 PM Martin Waschbüsch > wrote: >> >> Hi Adam, >> >>> Am 11.08.2019 um 23:22 schrieb Adam Weinberger : >>> >>> On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner >>> wrote: Quarterly is essentially useless if the decision is to immediately axe a deprecated release. 3 months are nothing in production environments, if you get 3 months (1,5 months mean) at all and also all other updates and security relevant bug fixes in the same quarterly that you desperately need. Yeah, we know that won’t happen so please don’t suggest it. That deprecation policy is nice and well all by itself except when it wreaks havoc over the ports infrastructure like in the case of PHP version support where numerous ports are immediately unavailable and incompatible with upgrades. Furthermore, the argument that it is more more work to maintain an abandoned version is silly because it’s more work to delete a port that to just keep it in the tree for a while longer. >>> >>> That last part isn't correct. The work of deleting the ports is >>> largely automated and simple, and it will always happen eventually. >>> The work involved is in supporting unsupported versions. Our php team >>> is spread very thin, and they simply cannot support php versions >>> outside of upstream development. There are no resources to backport >>> fixes that may or may not be designed to work with older versions >> >> I do not understand this. At all. >> And I sort of hope I misunderstood you, because it sounds like you think a >> maintainer is or may be regarded as someone who can be expected to provide >> product support of some kind? >> I find that notion worrying to say the least. > > If you believe that handling updates, analyzing submitted and upstream > patches and development, and answering a bevy of questions for every > major update is effortless, then you drastically underestimate the > amount of work that goes into the ports tree. You completely misunderstand me. I know there is a lot of effort going into this. I disagree only in that I do not believe there should be any expectations towards maintainers. It is voluntary work. Spare time, etc. I am grateful for the effort people put into this, but I strongly believe no one should act towards volunteers with any expectations as to what they should do, how much time they spend, etc. So, I find it wrong to say, as I understood you, to remove a package from the ports tree because otherwise others people, for instance users of FreeBSD, would have the *expectation* of receiving support for those packages. That perception of any kind of entitlement towards volunteers is wrong, IMHO. And that is why I answered that part of your message because it is not (for reasons stated above) a valid argument against having outdated software in the ports tree. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: INDEX build failed for 11.x
fixed with https://svnweb.freebsd.org/ports?view=revision&revision=508709 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 11.x
___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Franco Fichtner wrote on 2019/08/12 08:20: That „while“ is debatable, but it’s neither indefinitely nor immediately. The people responsible for FreeBSD ports and packages would be wise to enrich their policies with a more graceful way of dealing with legacy software, especially if it relates to more than a handful of ports in a single deprecation decision. TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading mails like these. Part of the contract in providing packages includes providing support for them. Other OSes provide packages for software that they can never support, and there are definitely consequences for that paradigm. This is doubly true for PHP, which is extremely common and for which security fixes can be vitally important. Well, you are arguing against a grace period for obsolete software which is quite pointless because the software is not bad per se. It will be eventually and it should be removed and nobody argued against that. In the case of PHP 5.6 a clear error of judgement was made based on a reasonable decision at the time. It should give enough incentive to not let this happen again so quickly and try to learn from how it negatively impacts users. +1 from me. Removing PHP 5.6 before the last version was released by upstream was very inconvenient and we end up doing 5.6.40 version ourself. Then deploy on servers which cannot be updated to 7.x at that time. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch wrote: > Furthermore, the argument that it is more more work to maintain an > abandoned version is silly because it’s more work to delete a port that > to just keep it in the tree for a while longer. > >>> > >>> That last part isn't correct. The work of deleting the ports is > >>> largely automated and simple, and it will always happen eventually. > >>> The work involved is in supporting unsupported versions. Our php team > >>> is spread very thin, and they simply cannot support php versions > >>> outside of upstream development. There are no resources to backport > >>> fixes that may or may not be designed to work with older versions > >> > >> I do not understand this. At all. > >> And I sort of hope I misunderstood you, because it sounds like you think a > >> maintainer is or may be regarded as someone who can be expected to provide > >> product support of some kind? > >> I find that notion worrying to say the least. > > > > If you believe that handling updates, analyzing submitted and upstream > > patches and development, and answering a bevy of questions for every > > major update is effortless, then you drastically underestimate the > > amount of work that goes into the ports tree. > > You completely misunderstand me. > I know there is a lot of effort going into this. I disagree only in that I do > not believe there should be any expectations towards maintainers. > It is voluntary work. Spare time, etc. I am grateful for the effort people > put into this, but I strongly believe no one should act towards volunteers > with any expectations as to what they should do, how much time they spend, > etc. > > So, I find it wrong to say, as I understood you, to remove a package from the > ports tree because otherwise others people, for instance users of FreeBSD, > would have the *expectation* of receiving support for those packages. > That perception of any kind of entitlement towards volunteers is wrong, IMHO. > > And that is why I answered that part of your message because it is not (for > reasons stated above) a valid argument against having outdated software in > the ports tree. Ah! You're right, I did completely misunderstand you. You're correct that we don't provide any semblance of support for the upstream software. Absolutely, and under no circumstances should anyone have to. I'm referring to support of the port itself. Maintainership requires responding to private emails asking for help; evaluating, testing, and approving submitted patches; responding to PRs about changes or fixes or poor behaviour (90% of the time related to portmaster); responding to error reports; and so on. We do expect those things from maintainers, because those are what are required to keep the ports tree running. And we actively drop maintainership from ports where maintainers routinely ignore those responsibilities, regardless of whether they have a commit bit. As decke noted, maintainership of a small port with relatively low deployment is pretty smooth (and don't get me wrong, they're as or more important than the big packages). But a huge and complex framework like php is a massive undertaking, with a near-constant barrage of complex patches that require highly complex testing strategies, and thousands of dependent ports to worry about for every change. I suggested that it might be possible for stale languages to remain in the tree, as long as the above support wasn't required or expected. But, honestly, Franco's response mocking the offer made my desire to help him somewhere at or below zero, and has pretty much ensured that nobody else in portmgr is going to be eager to get skin in the game. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> On 12. Aug 2019, at 16:29, Adam Weinberger wrote: > > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch > wrote: >> Furthermore, the argument that it is more more work to maintain an >> abandoned version is silly because it’s more work to delete a port that >> to just keep it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I do not understand this. At all. And I sort of hope I misunderstood you, because it sounds like you think a maintainer is or may be regarded as someone who can be expected to provide product support of some kind? I find that notion worrying to say the least. >>> >>> If you believe that handling updates, analyzing submitted and upstream >>> patches and development, and answering a bevy of questions for every >>> major update is effortless, then you drastically underestimate the >>> amount of work that goes into the ports tree. >> >> You completely misunderstand me. >> I know there is a lot of effort going into this. I disagree only in that I >> do not believe there should be any expectations towards maintainers. >> It is voluntary work. Spare time, etc. I am grateful for the effort people >> put into this, but I strongly believe no one should act towards volunteers >> with any expectations as to what they should do, how much time they spend, >> etc. >> >> So, I find it wrong to say, as I understood you, to remove a package from >> the ports tree because otherwise others people, for instance users of >> FreeBSD, would have the *expectation* of receiving support for those >> packages. >> That perception of any kind of entitlement towards volunteers is wrong, IMHO. >> >> And that is why I answered that part of your message because it is not (for >> reasons stated above) a valid argument against having outdated software in >> the ports tree. > > Ah! You're right, I did completely misunderstand you. > > You're correct that we don't provide any semblance of support for the > upstream software. Absolutely, and under no circumstances should > anyone have to. > > I'm referring to support of the port itself. Maintainership requires > responding to private emails asking for help; evaluating, testing, and > approving submitted patches; responding to PRs about changes or fixes > or poor behaviour (90% of the time related to portmaster); responding > to error reports; and so on. > > We do expect those things from maintainers, because those are what are > required to keep the ports tree running. And we actively drop > maintainership from ports where maintainers routinely ignore those > responsibilities, regardless of whether they have a commit bit. > > As decke noted, maintainership of a small port with relatively low > deployment is pretty smooth (and don't get me wrong, they're as or > more important than the big packages). But a huge and complex > framework like php is a massive undertaking, with a near-constant > barrage of complex patches that require highly complex testing > strategies, and thousands of dependent ports to worry about for every > change. Sure, if you feel like that is so there is no need to argue about it. I still feel the latent drift of “php is high profile and low profile is easy” like a sneaky way out of a fruitful discussion ignoring the request made by users: don’t kill software on tight schedules if there is no technical need for it. Unless you want to state a valid technical reason. For PHP 5.6 removal especially one has to assume that general arguments are merely made up here to fit the general lack of disagreement on the grace period issue. That’s fine and easier to say you don’t want to do it vs. it cannot be done. :) > I suggested that it might be possible for stale languages to remain in > the tree, as long as the above support wasn't required or expected. > But, honestly, Franco's response mocking the offer made my desire to > help him somewhere at or below zero, and has pretty much ensured that > nobody else in portmgr is going to be eager to get skin in the game. I‘m merely pointing out you‘re unwilling to do it and your offer was impractical for users running any PHP extension but you were not straight forward in your answer previously. This segment at least makes it clear so thank you for being frank about it. To sum it up there is no desire by maintainers to do what users requested here so yay for that conclusion at least. Cheers, Franco ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailm
Re: PHP version retirement
Hi Adam, > Am 12.08.2019 um 15:29 schrieb Adam Weinberger : > > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch > wrote: >> Furthermore, the argument that it is more more work to maintain an >> abandoned version is silly because it’s more work to delete a port that >> to just keep it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I do not understand this. At all. And I sort of hope I misunderstood you, because it sounds like you think a maintainer is or may be regarded as someone who can be expected to provide product support of some kind? I find that notion worrying to say the least. >>> >>> If you believe that handling updates, analyzing submitted and upstream >>> patches and development, and answering a bevy of questions for every >>> major update is effortless, then you drastically underestimate the >>> amount of work that goes into the ports tree. >> >> You completely misunderstand me. >> I know there is a lot of effort going into this. I disagree only in that I >> do not believe there should be any expectations towards maintainers. >> It is voluntary work. Spare time, etc. I am grateful for the effort people >> put into this, but I strongly believe no one should act towards volunteers >> with any expectations as to what they should do, how much time they spend, >> etc. >> >> So, I find it wrong to say, as I understood you, to remove a package from >> the ports tree because otherwise others people, for instance users of >> FreeBSD, would have the *expectation* of receiving support for those >> packages. >> That perception of any kind of entitlement towards volunteers is wrong, IMHO. >> >> And that is why I answered that part of your message because it is not (for >> reasons stated above) a valid argument against having outdated software in >> the ports tree. > > Ah! You're right, I did completely misunderstand you. > > You're correct that we don't provide any semblance of support for the > upstream software. Absolutely, and under no circumstances should > anyone have to. got it. I am glad that we are on the same page here. > I'm referring to support of the port itself. Maintainership requires > responding to private emails asking for help; evaluating, testing, and > approving submitted patches; responding to PRs about changes or fixes > or poor behaviour (90% of the time related to portmaster); responding > to error reports; and so on. Understood. If I wanted to offer my help maintaining a no longer supported version of php, where would I look to try and identify the amount of work likely to be involved? Would bugs.freebsd.org be a comprehensive source for such an evaluation? There are a total of 10 issues in 2018 and 2019 when searching for php 5.6: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&bug_status=__closed__&bug_status=New&bug_status=Open&bug_status=In%20Progress&bug_status=Closed&bug_status=UNCONFIRMED&f0=OP&f1=OP&f10=OP&f11=product&f12=component&f13=alias&f14=short_desc&f16=CP&f17=CP&f2=product&f3=component&f4=alias&f5=short_desc&f7=CP&f8=CP&f9=OP&j1=OR&j10=OR&o11=substring&o12=substring&o13=substring&o14=substring&o15=substring&o2=substring&o3=substring&o4=substring&o5=substring&o6=substring&order=changeddate%20DESC%2Cpriority%2Cbug_severity&query_format=advanced&v11=5.6&v12=5.6&v13=5.6&v14=5.6&v15=5.6&v2=php&v3=php&v4=php&v5=php&v6=php I assume there is more work involved (at the very least compiling php and all its modules with poudriere, for different platforms and / or versions of FreeBSD, etc.). > We do expect those things from maintainers, because those are what are > required to keep the ports tree running. And we actively drop > maintainership from ports where maintainers routinely ignore those > responsibilities, regardless of whether they have a commit bit. Also understood. I took up maintainership of archivers/lz4 a while back when it was without a maintainer, so I am a little familiar with how this works. > As decke noted, maintainership of a small port with relatively low > deployment is pretty smooth (and don't get me wrong, they're as or > more important than the big packages). But a huge and complex > framework like php is a massive undertaking, with a near-constant > barrage of complex patches that require highly complex testing > strategies, and thousands of dependent ports to worry about for every > change. Would you agree that in the case of software that is no longer maintained upstream, the support would mostly consist of ensuring the packages s
Re: PHP version retirement
On Sat, 10 Aug 2019 13:22:25 +0200 Kurt Jaeger wrote: > Hi! > > [...] > > Would it not be better to have, say, the last two versions before > > current stable still in ports but with a huge disclaimer saying: > > use at your own risk, etc.? > > > > What do y'all think? > > You make the case for something other systems call backports, > basically, keeping stuff in working order in the tree. > > Backports in other systems need someone to take up stewardship. > > So, either a group steps forward and takes responsibility to > keep them in working order in the generic tree, e.g. by > - having a mailing list, e.g. backports@, > - and changing the maintainer from ports@ to backports@ > - and fixing PRs as they come up > > Or a group provides their own pkg repo that the normal pkg-user can > reference to retrieve those older packages. > > Both approaches sound possible, but need a non-trivial amount of > investment. > Just wishing one day someone come up with it... I do more and more builds from souce last years because more and more ports disappearing due to deprecated dependencies or themselves (last time it was Natron->qt4 for ex.) what's about php5.6, it isn't big deal to me to build it from source, but if I'll ask people from low budget hosting companies around "Why not FreeBSD?", I think this will be one of significant points, cause many of them hire low-budget engineers, who only can or want install something from ready distro/packages and copy pre-written configs. But maybe FreeBSD indeed isn't right OS for them. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On 12 Aug 19, at 01:04 , Martin Waschbüsch wrote: > So, I find it wrong to say, as I understood you, to remove a package from the > ports tree because otherwise others people, for instance users of FreeBSD, > would have the *expectation* of receiving support for those packages. There is not expectation that any code is being maintained, but there *IS* an expectation that the software in ports is being maintained, supported, and is functional. -- Im finding's you'r mis'use of apostrophe's disturbing. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
