IRC channel logs
2022-06-03.log
back to list of logs
<rekado>will rebuild numpy with gfortran-7 because that’s what scipy needs, and mixing different versions of gfortran might be the reason why the tests fail. <rekado>or maybe we need an older variant of openblas <zimoun>rekado: I have thought again about master/staging/core-updates and your argument sayings up-front vs side effects. I agree that the side effects are reducing etc. But we have a human bias: loose aversion https://en.wikipedia.org/wiki/Loss_aversion Therefore one unique failure is more visible than 20k+ perfectly working packages. The weight of side effects is higher than fpr up front, IMHO. <PurpleSym>As for that “people with commit access are expected to review patches”: Institutional developers may not have the freedom to use their time for that. <zimoun>PurpleSym, I agree. But since there is Sign-Off, it is possible to report that activity, IMHO. As civodul said elsewhere, and I agree, it is also important to provide the message to our institutes that scientists cannot be just freeriders. Well, the message is difficult and I agree some “bosses“ do not let such freedom. Bah difficult topic. :-) <rekado>one thing that doesn’t come up often enough, I think, is that the increase in packages also dramatically increased the amount of maintenance. <rekado>yes, review is important, but we also have a lot of existing stuff that doesn’t stay fresh on its own <zimoun>yeah, teams could really help, IMHO. <rekado>I’m almost completely occupied with the occasional R package review and unbreaking stuff that was broken because of some unrelated upgrades. <rekado>this Python 2 purge is an exception, of course, but we’ve got similar things happening all the time. <rekado>some python package got upgraded, which broke other Python packages, and now a bunch of bioinfo packages cannot be installed, etc <zimoun>I cannot agree more. Hence my proposal to change where we push by default vs what users pull by default. <rekado>I feel like I’m going from one fire to the next; and all the interesting hacking just falls by the way side. <rekado>and at the same time I feel that we don’t have *enough* people putting out these fires <rekado>even aside from review, which is in a much worse state now than ever before. <rekado>I’d love to rest assured that someone feels responsible for this big blob of Python that everything seems to be built upon <rekado>but in reality Python packages are just … in the way of getting something else working. <rekado>so there’ll be a haphazard upgrade here and there when some other package absolutely refuses to be built with whatever version we happen to have. <rekado>this mass of Python packages needs segmentation and continuous frequent upgrades to prevent these big breaking changes every once in a while. <zimoun>I am totally aligned with these words. Although I did really few in maintaining things these couple of past months. <rekado>I fear that maybe of those committers who still regularly contribute *most* of them are locked up in maintenance work. <rekado>another problem that afflicts me personally is a complete lack of awareness of what activities are happening in the world of patch review. <rekado>I made mumi show ‘forgotten issues’ to address at least one part of the problem <rekado>I don’t think anyone with commit access would be okay with the majority of the review work to be done by just two people. <rekado>dilution of responsibility is powerful — there are so many committers, surely there are many who are reviewing patches right now … right? <rekado>mumi can highlight some of these problems <rekado>gamify the review process with leaderboards *rekado opens up the mumi working dir <zimoun>Yeah, I am just pointing how other are trying to fix similar issues. <rekado>zimoun: you wanted URL redirection for message ids, right? <rekado>this seems easy enough, so I’ll hack on it next when I manage to carve out some time. <zimoun>yeah, I think it could be nice to have. But as for many things, I am often too lazy to jump in give a try. <rekado>one thing that’s a bit depressing about issues.guix.gnu.org is that ‘forgotten issues’ looks pretty static <rekado>and when I look inside it’s mostly stalled discussion that cannot easily be moved forward. <PurpleSym>zimoun: I’m not sure how detailed I’m allowed to get, but visibility has no value if the team (which is one person, usually) is stuck in maintenance work and cannot move the product forward. <PurpleSym>Because that’s what they are paid for and not maintenance of Guix – even in science. <zimoun>rekado: I am doing my best for unstalling. But I really feel alone. I have never did stats but I guess only apteryx and me are digging old issues and try to close. <PurpleSym>We desperately need automation of everything that can be automated, because we, the humans, cannot keep up any more. And imo that also means using existing automation approaches and not spending more time inventing new ones. <zimoun>PurpleSym: I am not sure to understand your words about Instution. <zimoun>To me, there is no free lunch and everything has a cost. The question is how to collectively (public money, public code) share this cost. <zimoun> As I am explaining to my colleagues, CRAN or Biocondcutor are not automagically working; people are investing ressources. It saves some of my own Institute ressources, what my Institute is giving back? The answer is more than often: nothing and so? Ask about the maintenance of the commons in the picture of the scientific activities is something difficult for sure, but asking is free. ;-) <rekado>zimoun: about indexing msgids for mumi: we’re currently indexing *issues*, not individual messages. <rekado>but I guess we could store all message ids that are part of an issue and at least redirect to the correct issue. *rekado pushed python2-scipy to guix-past <rekado>PurpleSym: do you need help with getting guix-science fixed? *rekado received first bug reports about ‘guix pull’ not working <rekado>this is not quite how I imagined this week to go <rekado>PurpleSym: never mind; I see you removed the python2-* packages <rekado>maybe we can recover them by using (past packages python27)? <rekado>I’ll try to resurrect python2-pysam and bamm next