On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote: > > Right, my only contributions to Fedora on this account have been Mindshare > related, and various Copr builds. I'm not currently a packager, nor am I a > member of QA. However, that doesn't change much about my argument. It's still > valid, especially in response to the original reasoning given for this > Change. > If the real reason is simply "The people who currently do it don't want to do > it anymore", which is what you describe, > > I've offered to take on responsibility for these tests in this thread, and > I'm > still open to that. This is still important to many users, and I'm more than > happy to volunteer my time to support those users.
If we can actually rely on you to show up and do these tests - within, remember, sometimes a very short time frame - that'd be great. However, we've gone through this loop before with some other criteria (we propose dropping them, someone complains and promises to do the testing, then doesn't actually do it in the end) enough times that we'd be a bit cautious about this. Still, we have F32 Beta coming up quite soon, we could potentially delay this feature and see how that goes - see if anyone besides RH Fedora QE staff shows up to run the tests... > > The first time dropping x86 support was proposed, people complained and > > said they would look after it as an alternate arch, just as we have > > active teams looking after ARM arches, ppc64le, s390x and so on. An x86 > > SIG was formed. (You didn't join it.) But it barely did anything. Folks > > in QA and releng followed the process - when x86-specific issues > > appeared, we flagged them up in an appropriate tracker and notified the > > SIG about them. But...usually, nothing happened. People *didn't* help > > fix the bugs. It all just fell on the same people again, most of the > > time. These are the reasons x86 support was dropped. If you don't like > > it, that's your right. But there *are* "real reasons". > > I didn't join because I didn't know about it until the followup thread to > kill > x86 entirely, at which point I did look into the work that was required, and > just weeks later x86 was killed. There are real reasons, but it's not the > reasons that were actually proposed. Lack of manpower is one thing, but > that's > not one of the reasons that was cited during the thread. It's an implied reason pretty much any time the proposal is 'stop doing this one thing', because if we had infinite resources we'd never have to stop doing anything. We could do *all the things*. The fact that we have limited resources is such a basic constraint it's not always explicitly *stated* in the Change, but it is always there. > > Python 2 is an even simpler case: Python 2 *is no longer maintained > > upstream*. The Python developers and the community members and > > developers who are most passionate about Python's future desperately > > want projects and users to move *off* Python 2 and *onto* Python 3. > > Fedora is not a museum piece, it's a living, relatively forward-looking > > distribution. A key goal of Fedora is to *drive forward* innovation in > > F/OSS. Fedora's most important job WRT the Python 3 transition is to > > push the adoption of Python 3, not to prop up the existence of Python > > 2. That's not the job Fedora is here to do. > > This doesn't change the fact that many Python scripts *cannot run on Python > 3*. Debian is not a museum piece either, and yet they don't just kill the old > version. The two versions can, and do, work when both installed in parallel. We are, uh, aware of this. They have been installed in parallel on most Fedora installs for like a decade now. BTW, there is another point here which you may not appreciate: Fedora and Debian aren't really in competition. Fedora does not see its job as being to Conquer The World and have everyone run Fedora. Fedora is targeted at particular purposes and particular audiences. If a given feature isn't actually driving Fedora's mission forward in any way, it's reasonable to consider not having it any more, or at least not making it a core part of the distribution and subject to blocking requirements and so on. There comes a point at which we don't need to support Python 2 for the people and use cases at which Fedora is aimed. Will there still be people who need Python 2 for *something* at this point? Probably! But, just as you point out, if so, they can get it somewhere else. Someone using Debian instead of Fedora because they need Python 2 isn't necessarily a *problem* for Fedora. It's only a problem if it would've served Fedora's goals and purposes for that person to be using Fedora. If what they do isn't really a part of Fedora's goals...why should we worry about them using Debian? Debian is a fine distribution. Nothing wrong with it. To put it another way...Debian and Fedora have different purposes and different goals. Us dropping Python 2 earlier than Debian do is *things working the right way*. We (arguably) do more than Debian to drive the adoption and stabilization of new technologies - new stuff tends to show up in Fedora earlier than it shows up in Debian. Debian (arguably) does more than we do to provide long-term support for older software and support for alternate architectures. This is a *good* thing. It's an ecosystem that helps everyone. > This isn't relevant to this thread either, but several packages were simply > dropped from Fedora because the upstream didn't have a "path forward", as it > was put in the FESCo ticket, to Python 3. Yup. This was anticipated. What's the alternative? We never drop Python 2 support in order to keep software that is clearly becoming increasingly out of date in a distribution which has "First" as one of its core principles? This is just another angle on "it is almost never the case that, when Fedora stops caring about something, it's a thing that absolutely nobody and nothing wants". There has to be a cut-off. There's probably *someone* out there who still has a Python 1 interpreter installed. And libc 5. On a 386SX. Should Fedora still work on it? https://docs.fedoraproject.org/en-US/project/#_first > > Again, maintaining Python 2 support is not free, and becomes > > increasingly costly over time. Python is an ecosystem, bits depend on > > other bits; if we hold some of it back to support Python 2 we hurt > > other bits that want to move forward to Python 3. As upstreams > > increasingly adopt 3 and either intentionally use features of 3 that > > don't work in 2, or just stop testing their code on 2 and > > unintentionally introduce 3-isms, it becomes increasingly hard to ship > > new versions while still working on 2; this is work that falls on the > > packagers, it is not free. Time they spend doing that is time they > > don't spend otherwise improving the package or other packages. > > The two can be installed in parallel, and that's the case as it is now. > Having > one doesn't prevent you from having the other. It doesn't "hold back" > anything > to have Python 2 present. Again, you're thinking from the perspective of the user. I'm thinking from the perspective of the project and its maintainers. As a user you're consuming the hard work of the people who build the project. Supporting Python 2 *does* hold them back. That is the "work" that is "not free" which I referred to above, points you seem to have ignored. > I've brought this up several times. I'm more than happy to take on the > responsibility for this if somebody can point me in the right direction, but > this will cause users to suffer if we don't continue to test installing from > optical media. All you have to do is subscribe to the test-announce@ list and, when a mail like this one appears: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/thread/TU5YRBVDQIKUHLZCYVRUMFFPENHL3CPZ/ Go to the 'Installation' result page - so, for that mail, it would be this page: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191209.n.0_Installation grab the relevant ISOs (there is a download table at the top of the page), test them according to https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install , and enter your result in the appropriate cell in the 'Default boot and install' table. You can do `dnf install relval` then `relval report- results` to use a little CLI interface which will edit the page for you, if you're not comfortable editing the wiki syntax directly (it's quite easy, though). It is useful to have results for all the nominated nightly composes, but it's *critical* that we get results any time a candidate compose appears. Those mails look similar but have a topic like "Fedora 31 Candidate RC-1.8 Available Now!". > > To summarize simply: your thesis is that we are dropping things "for no > > real reason" because it's easy to keep things that work working > > (paraphrase, because you've replied to this thread so darn many times I > > can't find the precise quote). There *is* a real reason, and it is > > essentially the same real reason each time: no, it is *not* easy to > > keep things that work working. It takes time and effort. We have > > limited amounts of both, which we have to allocate sensibly. If we had > > infinite amounts of time and effort we could develop, build and test > > every feature, on every machine in the world! We don't, and we can't. > > We have to pick and choose what we can cover. At *some* point, when a > > Thing becomes sufficiently old that it only matters to a very small > > proportion of real or potential users, we cross the line at which it > > still makes sense to spend the same amount of resources on it. The > > number is *never* zero, so we *always* have this argument. But it's not > > wrong to say, okay, we've crossed the line. > > At this point in time, I'd say that line has not yet been crossed. As I've > pointed out in this thread, by a quick look at Walmart, Best Buy and Dell's > RHEL certified offerings, optical media is not dead, and not near it. It's > less common than it has been, in some cases, but it is still a strong > presence, and many systems can ONLY boot from optical media. I think at this point - after you've said it about a dozen times - everyone reading this list is aware that that's your opinion, yes. Since this is proposed as a Change, it would be up to FESCo to decide whether it agrees with you. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
