On Mon, Sep 27, 2021 at 8:52 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Sun, 26 Sept 2021 at 16:35, Christopher <ctubbsii@xxxxxxxxxxxxxxxxx> wrote: > > > > I think part of the problem is that Java is too big. There are too > > many libraries to fit into a single community. I think there's > > probably willing volunteers to maintain some libraries and application > > packages, but these are not necessarily the same people willing to do > > all the work of maintaining OpenJDK packages or the whole Eclipse > > stack. > > > > When modularity took out the whole Java stack, it did a lot of lasting > > damage that is going to be hard to recover from. In order for the vast > > majority of Java packagers to return, there needs to be a reliable > > I am going to disagree here greatly. The Java stack was in exactly the > same mode it is in now before then. There was 1 person 'maintaining' > hundreds of packages for a long time. There were other 'maintainers' > listed but they were not around or ignoring things from burnout. > People had brought this up year after year and all that would happen > is everyone would say "we can't ever let things down" and pitch in to > fix things (or make the 1 person who was over-committed feel guilty > for asking to lighten the load). I didn't mean to imply that there wasn't a problem before. I was merely using the mass orphaning of the traditional packages in favor of the modules as a point of reference in the timeline. I don't know about the prior problems, only that there were problems that were subsequent to, and worsened by, the mass orphaning event, regardless of what led to it. My main point here was that treating the community as a single SIG makes no more sense than treating all packages whose software is written in C as a single "C SIG" community. It's too overwhelming for people to be able to know how to step in and help. It needs to be pieced back together from the bottom up. OpenJDK packages seem to be reliable and healthy. Eclipse seems to have some serious problems (it's unclear to me how important Eclipse is, since upstream binaries seem sufficient to me). I'm uncertain about XMvn and all the common dependencies that used to be present, but I suspect this is where the most damage was done, and the greatest room for volunteers... if it weren't so overwhelming. > > Then when the defacto Java maintainer moved stuff into modules to make > his life easier.. there was a 'well we can find new people to do this > instead' and various initiatives were tried to make it. Those have all > failed because > > 1. Java and Fedora have a long back history of ugly fighting which > makes it hard for 'older' Java people want to work with Fedora. Like > old feuds, there are landmines which flare up fights no one remembers > exactly but they come up. > 2. That ugly fighting is sort of written into the packaging guidelines > because it is a long 'compromise' between how Java wants packages done > and how Fedora wants it done. This makes it hard for 'new' Java people > because they are whiplashed between different world views. And vice > versa, if you aren't a Java person and try to make it fix a Java > package it can be a brain hurt as you try to do things like in other > packages and it all fails. > 3. Most Fedora consumers just want the tools to work and pile onto the > smaller pool of developers about 'why is X always broken?' This has > caused continual burnout when new teams came up. It was also what was > burning out the previous people. I came in with none of that history. I saw XMvn, thought it was awesome, and started packaging with it. Perhaps some of that history/conflict affected some packagers, but I never saw it play a big role, based on the timing of when I started contributing. Maybe it played a big role, maybe it didn't. I think people who have been around longer and have been more deeply involved might have a different perspective than people who are newer and more casual contributors. I worry that the long-timers may not be able to understand how the new packager experiences contribute to Fedora's problems (particularly the ability to keep up with attrition), and only focus on the deep and/or historical problems, even when they have little to no impact on newer folks who aren't aware of any of that. > > Basically Java has been 'broken' for as long as I have been part of > Fedora. The 'good' times are usually just after the last time Java was > going to be pulled out in the next release, and finally everyone drops > the things they really care for and works on it. Then everyone goes > back to their real pleasures and it falls apart again. Later, rinse, > repeat. > My experience differs. I didn't find Java in Fedora broken at all when I started. I actually found the set of available packages in Fedora to be quite functional prior to the mass orphaning. It may have had its community problems, and some out-of-date packages, but the overall experience from this casual packager maintaining a few Java application packages was quite sufficient. It wasn't perfect, but it worked, and I could file tickets and occasionally help when something didn't work. When the mass orphaning happened, it became impossible to keep up with the loss of dependencies, and modularity was too confusing (and didn't seem appropriate for my packages). But, before that, it definitely wasn't broken for me. In fact, it was amazing, especially how functional XMvn was to help me package easily. > > -- > Stephen J Smoogen. > I've seen things you people wouldn't believe. Flame wars in > sci.astro.orion. I have seen SPAM filters overload because of Godwin's > Law. All those moments will be lost in time... like posts on a BBS... > time to shutdown -h now. > _______________________________________________ > 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 > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
