On Monday, December 16, 2019 10:41:57 AM MST Adam Williamson wrote: > On Sun, 2019-12-15 at 22:59 -0700, John M. Harris Jr wrote: > > > This is not the only change I am referring to. We've been in the > > habit of dropping things that work, with no real reasons lately. > > For example, look at dropped x86 support, and soon we will be > > dropping Python 2. We have already had several Python 2 packages > > dropped simply because they refused to move to Python 3. This is an > > ongoing issue, where everything considered "old" is just abandoned, > > and it is hurting the user base. > > > So, as far as I can tell, you have done no work on anything to do with > x86 support or Python 2: you have run seven package builds, ever, all > of one package in 2016. > > You also have never run a Fedora validation test (or edited anything on > the wiki besides your own user space, the Council page to nominate > yourself, and the 3D Printing SIG page to add yourself). > > According to your badges you've certainly made some useful > contributions to Fedora in other areas, which is great! COPR builds, > package tagging, writing articles, running meetings and so on. But you > haven't actually done any work in any of the areas you're complaining > about here, as near as I can tell. > > All of the changes you refer to were changes made for the benefit of > the people doing that work (and *thus* for the good of the project as a > whole, because the resources of the people who do the work are limited > and must be allocated properly). You claim that they were done for "no > real reason", which I think is a symptom of the fact you haven't done > any of that work, which perhaps makes it harder to understand the > actual reasons. 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. > Upstream authors are caring less and less about 32-bit support in their > code. This meant Fedora on x86 was working less and less well over > time, while at the same time sucking up considerable QA, releng and > developer time. The way Fedora is currently set up, if a package fails > to build on *any* arch, the entire build fails and is not pulled in. So > if we needed to fix a problem but the package didn't build on x86, the > problem wasn't fixed until someone figured out why not, or just blocked > the package on x86, which over time would have rendered the arch dead > by stealth. Because we do actually care about what we ship, if a > compose went on but was entirely broken on x86 we in QA and releng and > devel would try and figure out why (just as we do for ppc64le, for > instance) and that was taking up our time too. Building for x86 also > cost in terms of hardware resources, resources which could otherwise be > used for building faster on x86_64. > > 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. > 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. 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. > 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. > With optical media: as I mentioned in another post, your '25 minutes' > estimate for running an optical media boot test is substantially off, > it is closer to an hour factoring in time to write the medium and run > the consistency check. It is true that I didn't account for a media check, but I did account for write time. > That may not sound like a lot, but we frequently produce release candidates > less than 48 hours before we intend to sign off on them. (Sometimes we have > done it less than *24* hours before we signed off). In the context of us > having less than 48 hours to test the entire release compose, some of which > we spend, you know, sleeping, 2 hours (there are two images to test) of > testing time is a *lot*, which could otherwise be spent running other tests. > Time has different value at different points in the cycle: I can easily > spend an hour writing this email right now because we're not in a release > crunch, in fact I am on PTO right now so I'm spending my own time on this > when I could be playing Luigi's Mansion 3 (boy, what a sucker I am). But > when the RC is going to finish in eight hours and we have to sign off on the > release tomorrow morning, an hour suddenly seems like rather a *lot* of > time. 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. > 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. > Sometimes someone will propose that we've crossed the line when we > haven't, and usually we realize this and the proposal fails (excellent > example: the recentish "x86-64 micro-architecture update" proposal, > which met such universal raspberries it's probably not coming back for > a long time). It's possible that sometimes we get this call wrong, > we're only human. But it's wrong to suggest that decisions about what > we can and can't maintain, test and support are made for "no real > reason" or (as you suggested elsewhere) "arbitrarily". They aren't. To paraphrase what you said earlier about "old" tech, "In with the new, and out with the old" is a fairly arbitrary way of making such decisions, especially with relative figures. -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
