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. 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". 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. 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. 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. 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. 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
