jdv79 AlexDaniel brings up a good point - will this steering council supercede the pre-exiting problem solving "thing"? 00:01
*pre-existing
timotimo no it is a separate thing 00:02
AlexDaniel` timotimo: yeah, a complete mess 00:05
timotimo: but you sound like you know something about it. Tell us, what is it about? 00:06
00:06 Altai-man_ joined 00:08 sena_kun left
jdv79 oddly i seem to have a commit bit to nqp but i can't find any commits by me 00:09
timotimo github.com/Raku/problem-solving/is...-647661433 00:10
AlexDaniel` oh god 00:12
jdv79 ah, a bit of history - i thought it felt familiar - forgot about the after Guido stuff
timotimo as I understand it the committee members will be responsible for the final voting 00:16
for the problem solving issues
AlexDaniel` WHY?
there was like what, one PR that we actually voted on? 00:17
timotimo I will read the document again
I just only looked at the very first email
not the discussion that was had
AlexDaniel` if you want to change how the problem-solving repo works, you should propose a change to the problem-solving repo 00:18
so let's say you have this council thing, sure, but the problem-solving repo can't stay intact, you need to adjust it
and no, the council thing can't just coexist separately, that makes no sense 00:19
jdv79 interesting times. hope some good comes of it all.
AlexDaniel` jdv79: maybe? probably? I was always surprised as to how much of the decision making happens in private messages. Maybe there's a good reason for this all, but I can't know 00:20
jdv79 iirc this all started because liz got frustrated with how "slow"/"broken" the problem solving process was. i don't know how this fixes that but i'm intersested to learn. 00:21
timotimo I assume you have read the steering council code
AlexDaniel` if someone wants to distort what the problem-solving repo is, I'm fine with that, but please define what you are going to do with it. At the very least I'm just curious, as I've created the damn thing 00:22
timotimo it looks like the thing about the final vote was not actually in there 00:23
AlexDaniel` > It's better to establish a Code of Conduct committee than to rule on individual cases 00:26
except that it's what problem-solving already is, amazing!
but we never got more than one person working on any specific topic 00:27
ehhhhhhhhā€¦ 00:28
I'll tell you this 00:31
liz specifically dislikes the problem-solving repo, as I understand because it doesn't allow you to have things done your way immediately 00:32
when the Raku thing was happening, she was telling me how it's not going to work because we'll never get all reviewers to agree on the thing
and was consistently trying to subvert the process
well, guess what, human beings are actually alright, they can discuss and understand 00:33
I didn't let it happen, and we still managed to peacefully rename the project. 00:34
timotimo I'm looking forward to more comments on issue number six 00:35
AlexDaniel` now I'm reading this new thing and, honestly, I don't like it. It's disgusting. Describes how to eject people, how it can be a ā€œcourt of final appealā€ 00:36
as if all hope for human decency is lost
timotimo it also stipulates that these things are going to happen rarely
00:37 oddp left
AlexDaniel` if it's such a rare thing, why set a bad mood like this? 00:38
timotimo I don't know I never had to create a governance model from scratch 00:43
I can only assume this is founded on experiences made by others before us
AlexDaniel` yes, it's totally fine by itself 00:44
but then get rid of the problem-solving repo, or change it
or, you know, at least describe what's actually going to happen to it
timotimo this is valuable input I don't have answers for you just yet 00:46
but also I think this is meant as a minimum boot strapping
AlexDaniel` facepalm
we already bootstrapped it once!
but there's no bootstrapping that I see, btw 00:48
at least it's very different from the one we did for the problem-solving repo, where the details were being adjusted in the process 00:49
timotimo all can really say I don't know
maybe the tasks for the council are management activities that do not have the shape of a task to be solved 01:02
like recurring things
looking out for things that need to be addressed
whereas problems solving is for individual tasks where the focuses on how it should be done 01:04
I likely need to sleep on this
ugexe it makes one wonder if one process can just replace another process, can one not just create a third process to replace that one forever and ever? 01:06
or should each new process not be bound by the existing proess?
i.e. what is to say that in 6 months i declare this new process is not working, and that we will now do things some other way? 01:07
note i have not read anything about this new proposed process and have no opinion on it yet 01:09
ShimmerFairy I just read the proposal and it seems good to me. I don't see the issues AlexDaniel` is having wrt to the problem-solving repo; it seems obvious to me that the RSC just implements a more organized and visible way of dealing with & resolving tickets in the repo, and wouldn't supplant it or change how it operates. 01:48
(also, the "code of conduct" example has nothing to do with problem solving, but rather with codes of conduct) 01:53
AlexDaniel` well, explain to me then how will the repo function 02:04
because it's very not obvious to me, even though I created the thing 02:06
ShimmerFairy like it does now, except you're not waiting for somebody with some informal authority to eventually remember to make a decision on it?
AlexDaniel` decision on what?
02:07 sena_kun joined
ShimmerFairy a ticket 02:07
02:08 Altai-man_ left
AlexDaniel` so what is currently stopping anyone from making well-thought-out decisions? 02:08
like, why do we need to have an election on the team that will be making these decisions? 02:09
ShimmerFairy but who is part of that "anyone"? The point of an explicit governing committee is that it's obvious who's in charge of making changes to the language, among other responsibilities. 02:11
AlexDaniel` so you're basically saying 02:12
that 7 people will be added under the `language` label here? github.com/Raku/problem-solving#la...sible-devs 02:13
or all labels? or what?
ShimmerFairy I take it that you wouldn't need to maintain a list of specific people at the problem-solving repo anymore, but it would be nice to get clarification. 02:14
(Also, please keep in mind that there's more to the RSC proposal than just problem-solving, so don't treat it like that's all it's doing.) 02:15
AlexDaniel` I don't care if it lists 7 people or if it just says ā€œCouncilā€ or whatever, it's a minor detail
so this team will be simply providing opinions on how things should change, that's it? 02:16
I'm asking you because you just said that it's obvious, and that no changes to the problem-solving repo will be made.
major changes that is, I assume 02:17
ShimmerFairy What I got from the RSC is that it changes who's responsible for making decisions on those tickets and how the "who" gets defined. No changes to how the repo operates aside from the "who". 02:18
AlexDaniel` but tickets, generally, only define problems 02:19
solutions are in pull requests. PRs are merged when no reviewers object
so what are you saying, actually? That the current list of reviewers will be substituted with 7 people? 02:20
what's obvious to me is that this whole situation is not really obvious to you, so I don't know why would you say that. 02:21
if it brings changes to the reviewers, then I assume that Raku-Steering-Council way of doing things will replace what's already there 02:22
for example, that only a majority of votes will be required, instead of no objections at all 02:23
ShimmerFairy I have said multiple times that how I read RSC on the subject of the problem-solving repo is that it just changes who has authority to make decisions on what tickets propose. If you can't figure out how the repo works in a world where only the people in charge, and the specific ways in which they make decisions, has changed, then that tells me you don't know how the repo works today, and lizmat may just be right about it being a poor 02:24
process.
AlexDaniel` not just who, but how as well 02:25
but yeah, that last messageā€¦ kinda tells everything to me
basically ā€œyou don't know how the thing you made worksā€, alright alright 02:26
ShimmerFairy You're the one who expresses utter confusion at my understanding of what the problem-solving repo would look like under the RSC, I really don't know how else to see it. 02:28
AlexDaniel` that's correct
ShimmerFairy When I say "A=X+Y+Z except X is a different value now", and you say "I don't know what A is", how can I not conclude that you don't know what Y and Z are?
AlexDaniel` because you're not able to explain how it will work, this conversation started with you saying that no changes to the repo will happen
you don't even know what X is 02:31
is it responsible devs or reviewers?
ShimmerFairy OK. As I understand it, the point of the problem-solving repo is that people propose changes to the language, discussion happens, and somebody with authority decides whether we should do it or not. 02:32
AlexDaniel` well, no 02:33
ShimmerFairy What RSC changes: it brings in a different method of deciding who has authority, and perhaps gives those with authority clearer guidelines on how to decide whether we should do it or not.
vrurg AlexDaniel`: I'm not going to read through the whole discussion here, so might miss something. But let me put it this way: we've encountered some problems about problem-solving process. We're trying to resolve them. One of the biggest problems is that Jonathan is often taken as the main and final authority.
AlexDaniel` using your simplification: people report problems, then people discuss possible solutions, devs assigned to that topic provide guidance and suggest which solution they should go with, then someone commits to resolving a problem in a specific way, and reviewers basically give a nod saying that it won't interfere with their work 02:35
vrurg I hope Liz will clarify better than me. I had very hard day and drained out completely to have clear thinking now.
AlexDaniel` vrurg: that problem can be resolved by jnthn if he simply delegated his part to others 02:36
but he made it very clear that he is not fine with that
vrurg: much shorter summary is here: github.com/Raku/Raku-Steering-Council/issues/6
vrurg AlexDaniel`: not exactly. The quote you used was about _language_ problems. Besides, he might have changed his mind since then. 02:37
Ok, I'm not going to get deeper into this now. Maybe tomorrow. 02:38
AlexDaniel` vrurg: changing your mind is ok, then what about just adding more people to the `language` label?
02:38 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Merge pull request #3531 from Kaiepi/rank-n-exceptions 02:38
travis-ci.org/rakudo/rakudo/builds/710182722 github.com/rakudo/rakudo/compare/5...a13eb2a2d5
02:38 travis-ci left
AlexDaniel` or creating another label for whatever is missing, with a team of 7 or whatever you want 02:38
vrurg BTW, I'm so tired that can't recall p6lanet domain. Google seems to be useless. Anybody to point me at it? 02:39
AlexDaniel` planet.raku.org/
vrurg Thanks!
AlexDaniel`: really, IRC isn't the best place to have this kind of discussion. I'll see if I have anything to add tomorrow. 02:40
AlexDaniel` well, there's a ticket
I was just watching a movie, but then people started telling me that it's very obvious how it's going to work and that problem-solving repo is not going to change 02:41
which, you probably understand, is completely false
unless somebody actually defined what's going to happen in one of your private emails but didn't post it as a document
vrurg AlexDaniel`: not much is about to change about problem-solving, to my view. Little changes are possible, but minimally necessary. Simply because RSC is about to do as little as possible. 02:43
AlexDaniel` vrurg: will the voting process be changed? 02:44
vrurg There is nothing about problem-solving because there is no RSC yet. When elected it will design a paper on this if necessary, I think.
Not the first one. But for the following I'd appreciate some changes to be implemented. 02:45
AlexDaniel` not the first one what?
vrurg It's already too late but I planned to submit a few PRs, including election rules changes.
Not the first election. 02:46
AlexDaniel` how is this relevant to problem-solving?
I'm asking you if the voting process in the problem-solving repo will change
very simple question, actually 02:47
ā€¦ 02:48
vrurg AlexDaniel`: that's why I don't like IRC for this kind of things. Because it's easy to get lost. I meant RSC election. No idea about problem-solving process for now. But my prediction would be it won 02:49
't change
AlexDaniel` I'm also going to tell you this
if you have any respect to the problem-solving repo, then none of the RSC changes will apply to it unless they go through the repo as well 02:50
but then, this is only true as long as people think this way, if everyone is like ā€œah whatever we can change it willy-nilly nowā€ then of course no problem
which makes me really wonder why didn't you do it this way in the first place 02:51
but whatever
there's a ticket where you can describe all this in detail
vrurg AlexDaniel`: o/ :) 02:53
ShimmerFairy Why should changes have to go through the problem-solving repo at all? Where was it established that everything to do with Raku _must_ go through there? 02:54
vrurg ShimmerFairy: I'd put it this way: it was a community agreement. 02:56
AlexDaniel` also I'm talking about the problem-solving repo itself
if you're doing changes to it then, yeahā€¦
ShimmerFairy Like, the point of RSC is that it sets up a more formal & structured organization over the whole of Raku; why would it have to get approval through a process that would be subordinate to it? It's community agreement either way.
vrurg is afk& 02:58
04:06 Altai-man_ joined 04:08 sena_kun left 04:22 squashable6 left 04:24 squashable6 joined 06:07 sena_kun joined 06:08 Altai-man_ left
nine Ouch.... PR 3785 Xliff/rakudo-precomp-nolock2 was not ready for merging :/ 07:31
07:43 finsternis left
nine AlexDaniel`: creating the RSC doesn't change the problem-solving process per se. The RSC however is the body that can change the problem-solving process. It should also deal with questions like who's the lead designer, what are the high level goals for the next language release and who represents the project legally? 07:56
AlexDaniel`: if you say, "but we already have answers to those" then yes, that's correct. For now. But things may change. If jnthn loses interest, we need a new designer. If the TPF decides to focus on Perl only, we need a new foundation. It's good to have a deciding body ready by then rather than to have to make up things on the spot. 07:57
AlexDaniel`: the problem-solving process requires a BDFL to have the final call if unanimity cannot be achieved. The RSC can take over this role as we don't really have a BDFL at hand. 08:00
AlexDaniel`: does that make it clearer?
AlexDaniel` no 08:05
08:06 Altai-man_ joined
nine Btw. the build is broken: build.opensuse.org/package/live_bu...5.2/x86_64 08:08
AlexDaniel`: any hint on how I could make it clearer?
AlexDaniel` nine: well, what about this: github.com/Raku/Raku-Steering-Council/issues/7
08:09 sena_kun left
AlexDaniel` it's a bit simpler question 08:09
the BDFL ā†’ team change sounds like a good idea at first, but it's a bit wrong when considering the details. So, the list of reviewers will likely be roughly the same as the list of the council, meaning that for any PR where people didn't reach agreement yet you can just say ā€œah whatever, will take it to the teamā€ where just 4 people can push it through even if 3 others object. 08:15
that's my understanding, correct me if I'm wrong
nine I think your understanding of the mechanism is correct. I would like to point out that the list will not necessarily be the same. I for example am not in the problem-solving reviewers, but am a candidate for the RSC. 08:17
As to why the problem-solving process was not used. Well it was up to a point: github.com/Raku/problem-solving/issues/203 \ 08:19
AlexDaniel` but #7 isā€¦ interesting to say the least. The idea that anyone can just gather together and say ā€œok, this set of people will now be able to override the problem-solving repoā€ was definitely not part of the plan, you know
nine There's the suggestion to form a council like the Python people did in there. \
AlexDaniel` are you serious? Just talking about stuff on the ticket is definitely not how the repo worksā€¦ 08:20
nine So lizmat read up on that and slowly came to the conclusion that this might be the way to go. She did first contact a couple of people she's close to to get a sanity check first. \
AlexDaniel` and?
that's enough? 08:21
nine I'm just guessing here as to her motives, but the simplest explanation for why we diverged from problem-solving was that since the proposal was to not invent something ourselves, but follow what others did and the reports on the Python council included the full bootstrap, she simply forgot that we already had a bootstrap process in place. 08:22
And none of the people in the loop pointed that out either.
AlexDaniel` see, this is what I said previously. If people believe they can just blatantly ignore the problem-solving repo and override it at will, then it can't serve its purpose. If everyone agrees on that then whatever, but you don't need the damn repo then
nine In retrospect, yes the problem-solving process would have been perfectly applicable.
AlexDaniel` well, you could've pinged me, for example 08:23
offering free advice for the repo that liz loves to misuse so much :) 08:24
nine As you pointed out, the problem-solving process is meant for _all_ issues. In practice so far it's been used mostly for technical stuff and that's how - at least - I picture it. Which is a skewed picture, no doubt. It's now corrected.
AlexDaniel` I don't think it's unintentional, liz already tried to cheat the process in the past for the name change, except that I guess at the time I managed to convince her that there's no need
08:25 leont joined
nine AlexDaniel`: please, by calling her out using words like "cheat", you are presuming malevolence. I don't see enough evidence to conclude that. Frustration perhaps. Lack of surety about what the process is really supposed to look like maybe. 08:27
AlexDaniel` you wouldn't see enough evidence, it was mostly private messages 08:28
nine I simply don't see a motive here. Why subvert or cheat the process when by following, she could get the same results?
AlexDaniel` exactly, so why not follow the process?
you can still do it, by the way 08:29
because the tweaks in the problem-solving repo will not happen by themselves anyway 08:30
nine Well it's hard to speculate on someone else, so I stick with me. After all I did not point out that we ought to use problem-solving for the RSC and indeed, it didn't occur to me either. And why? Because I didn't have that "for all issues" secured in my mind and I was distracted by the complications and far reaching consequences of the topic at hand.
AlexDaniel` right, and stuff like this is actually prevented by the problem-solving repo 08:31
nine I disagree and would point out that the repo by itself did not prevent this. Otherwise we wouldn't have this discussion, would we? 08:32
AlexDaniel` anyway, there are two tickets where you can fill in the gaps on what's going
nine Processes don't follow themselves. Otherwise I wouldn't have had to deal with www.nachrichten.at/oberoesterreich...t4,3274054 which kinda distracted me the past week 08:33
AlexDaniel` yes, if everybody ignores that the repo exists, then surely it cannot prevent anything
nine We are simply fallible humans.
AlexDaniel` but it's not just that the process wasn't followed in this case, you are actually changing the process while not following the process 08:34
nine Error is simply much more likely and much more common than intent.
AlexDaniel` or intend to, at least
ok fine, then do it right, no biggie
and, as I already mentioned, you will need to tweak the README anyway
08:37 oddp joined
Kaiepi will take a look at those test failures after the recent merge 08:43
AlexDaniel` nine: another way is to have the voting and everything as proposed currently, and then submit a PR to the problem-solving repo after the steering council finalizes its own process and everything 08:45
basically ā€œhere's a team that we preselected, and this is how the process is going to changeā€
lizmat clickbaits rakudoweekly.blog/2020/07/20/2020-...tion-time/ 08:46
tellable6 2020-07-21T01:05:50Z #raku <guifa> lizmat OOPS, as per seems the usual, Iā€™m a terrible ecosystem citizen and forgot to add Intl::Timezone to the ecosystem file list. My bad =/
lizmat and starts reading the backlog
nine lizmat: keep in mind that we have cleared at least some of the confusion already :)
AlexDaniel` so it's no biggie either way, but the problem-solving repo simply remains exactly as it is with its existing power until the new PR is merged 08:47
I'm going to bed now, have a nice day everyone 08:49
lizmat will refrain from reacting until all is read
09:00 djinni` joined
lizmat nine: re > PR 3785 Xliff/rakudo-precomp-nolock2 was not ready for merging :/ 09:08
it was spectest clean, ran ok with Inline::Perl5 *and* allowed to me install modules
s/to me/me to
re test failure in t/02-rakudo/13-exceptions.t : I pushed a fix for that to the branch before merging? 09:10
Files=1308, Tests=113042, 215 wallclock secs (29.07 usr 8.56 sys + 3006.95 cusr 291.16 csys = 3335.74 CPU)
Kaiepi can't reproduce the failures locally 09:25
lizmat neither on MacOS 09:27
nine lizmat: yes, it works, but the implementation needs more work. E.g. it introduces a CompUnit::PrecompilationStore::Item role which in contrast to CompUnit::PrecompilationStore::File is not a CompUnit::PrecompilationStore and in my view is not needed at all. The new initiate-lock method (which other than the name suggests doesn't just initiate a lock, but actually locks) takes an arbitrary string when a 09:32
store can contain just 2 types of items that need locking.
Well I'm not even talking about the implementation, but the API here 09:33
lizmat ok, then why wasn't the PR marked as a WIP ?
nine There are commit messages with non-sensical subjects like "Once again, we have what appears to be a working version of a rakudo" 09:34
lizmat anyways... we're at the start of a new release cycle, do you think the issues can be fixed before the next release ? 09:35
or should I revert ?
nine Not sure yet
lizmat ok... lemme know when a revert is needed, and I'll do that
nine I meant to give it a thorough review. API design takes time and a clear mind. Is there a way to mark a PR as "don't merge yet?" 09:36
lizmat mark it as a Work In Progress ? 09:37
Altai-man_ On creation there is a new "Draft" feature for this.
nine how?
lizmat there's also a WIP tag
nine Ah, a label!
I fear reverting won't undo the damage anyway. The history is going to be confusing 09:39
Though frankly, there's almost nothing I'd leave in as-is :/ 09:41
lizmat ok, so maybe I should just take the state before the merge, and after, and make that into a single commit ?
Altai-man_ Another PR can be created from master, improving-addressing. 09:42
nine Let's leave it for now. Have to concentrate on $work for a while
Altai-man_ lizmat, rewriting history is dangerous in this case.
lizmat Altai-man_: I wouldn't suggest changing history, just making the revert into a single commit ? 09:43
Altai-man_ Ah.
I don't think there is a need in reverting, because nothing is technically very broken. The design of the API (nobody has used yet?) can be different, but this can be addressed in another PR. 09:44
(i
(if I understand correctly, if something was broken - then yes)
Anyway, release time&
lizmat true, but I *am* sensitive to nine's point of an API that has issues 09:45
Altai-man_ While I did stand (and still do) against broken master, pointing out such things is a delicate matter, humans are very good at taking technical points as personal criticism. 09:48
lizmat "You are not *your* code, you are just the person who wrote that code" 09:49
Altai-man_ As a matter of fact, I once spent a couple of hours debugging concurrency issue caused by jnthn's copy-paste of his typo. Guess he is horrible now. :P 09:51
lizmat terrible! :-)
Altai-man_ Also, this is the type of issues which could be prevented by PR-only explicit-approval-required model I suggested at github.com/Raku/problem-solving/issues/206 and then it diverged into CI solutions. 09:53
lizmat having worked on a project under pressure that used that model, I found that it soon became a matter of getting someone else to quickly ok a PR to be able to continue working on problems at hand 09:56
Altai-man_ Is rakudo pressured somehow? 09:57
I think we are kind of generous on not having hard deadlines.
lizmat just before a release it is ?
I've seen many deadlines in my life, they all just pass, this is true :-) 09:58
Altai-man_ Sometimes, but when we have a release blocker, it is not a question of "quickly ok a PR". We usually test solutions for blockers, because, well, that's important. I don't see why implicit approval I require now as release manager is different from explicit approval.
Anyway, I better to focus on my Comma deadline;) right now. If you want, I will gladly discuss this exact matter the other time, trying my best. :) 10:00
lizmat yes, I think it warrants a good discussion and attention to the ticket at hand 10:01
10:07 sena_kun joined 10:08 Altai-man_ left
lizmat has hopefully taken away a lot of apprehension about the RSC by answering github.com/Raku/Raku-Steering-Council/issues/6 and github.com/Raku/Raku-Steering-Council/issues/7 10:13
Geth_ rakudo: Kaiepi++ created pull request #3812:
Make Blob.gist work for all sizes of Blob		 11:06
ShimmerFairy It seems to me the problem-solving repo isn't well designed if multiple people (myself and nine being at least two people) think it only exists to resolve language design issues. 11:13
lizmat afk for a few hours& 11:30
nine ShimmerFairy: it's not really that either. It clearly states that it's for all issues and we have discussed non-language-design issues there, too. I just meant that our usage of it didn't leave the impression that it's the tool for working on government issues in my mind. 11:38
ShimmerFairy Yeah, when I first encountered the problem-solving repo it was in context of a language issue, and so I went "oh, github.com/raku/problem-solving clearing is a repo where you file issues to discuss language issues in one neat location. Name checks out and everything." 11:39
*clearly
11:40 patrickb joined
patrickb o/ 11:40
I'm currently reading the RSC documents. I really like what I read. lizmat++
I have two questions about the Steering Council call for election. 11:41
nine Of course AlexDaniel knows best what he inteded the problem-solving repo for and I can understand his frustration when he sees us struggling to find a solution to a problem when he sees the solution being there already and getting ignored.
It's clearly all about details and in the end the RSC is supposed to solve a subtely different problem. 11:42
ugexe tbh Iā€™m confused why it didnā€™t go through the problem solving process either. I mean I assume it would just go through anyway in the end... and I say this as someone who stopped participating as a reviewer after watching some people rubber stamp stuff they didnā€™t understand or fully review 11:44
nine Well in hindsight it's kinda obvious :) Luckily it's not too late either
ugexe Also Iā€™m the one who suggested Xliff pass a string instead of an IO::Path, so Iā€™m partly to blame there 11:48
nine If we're playing the blame game, then it mostly starts and ends with me. I goaded Xliff into taking on this issue and take ages to give feedback which I'd clearly have 11:51
patrickb sena_kun: I have created and uploaded the pre-compiled release builds. 12:00
sena_kun patrickb, very nice! I'll post email announcement this evening then. 12:01
Geth_ rakudo: patrickbkr++ created pull request #3814:
Fix release pipeline to not delete the linux build		 12:04
12:06 Altai-man_ joined 12:08 sena_kun left 12:09 finsternis joined 13:04 patrickb left
dogbert17 I guess the test failure in t/02-rakudo/13-exceptions.t is known ... 13:24
13:33 MasterDuke left
ugexe when merging old PRs without testing the integration locally one can push an empty commit to refire with --allow-empty to refire the CI testing 13:59
13:59 [Coke]_ joined, [Coke]_ left, [Coke]_ joined
ugexe which doesn't require knowing anything about any of the CI platforms or acting on them individually 13:59
that would have avoided the t/02-rakudo/13-exceptions.t issue 14:00
or exposed it before it got into master rather 14:01
14:02 [Coke] left 14:07 sena_kun joined 14:08 Altai-man_ left
Geth_ rakudo/new-disp: 186eb59507 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Use correct kind of atpos to index an array

Fixes a bunch of broken multi dispatches using the new dispatcher.		 14:12
rakudo/new-disp: 3feeb3ccc0 | (Jonathan Worthington)++ | 2 files
Complete move of assign spesh plugin to dispatcher

This is the last spesh plugin that was still to be switched over. There's probably some opportunities here for further improvements, but for now this is a fairly straight mapping.		 14:16
rakudo/new-disp: cd928b493d | (Jonathan Worthington)++ | 3 files
Eliminate spesh-plugins.nqp from the build
 14:23
14:28 [Coke]_ is now known as [Coke]
Geth_ nqp/new-disp: bec40a0c27 | (Jonathan Worthington)++ | 2 files
Remove spesh plugin ops and test case
 14:34
14:46 patrickb joined 15:54 MasterDuke joined 16:06 Altai-man_ joined 16:08 sena_kun left 16:15 sena_kun joined 16:44 sena_kun left 17:44 patrickb left 18:07 sena_kun joined 18:08 Altai-man_ left 18:21 cognominal joined, cognominal left 18:25 Altai-man_ joined 18:27 sena_kun left 18:32 sena_kun joined 18:34 Altai-man_ left
ugexe master is pretty borked 19:05
github.com/rakudo/rakudo/commit/88...484f9587b4
work from that commit was lost to the recently merged github.com/rakudo/rakudo/commit/4a...e1cf34e15b
github.com/rakudo/rakudo/blame/mas....pm6#L1209 here is master 19:07
i guess thats another point towards requiring reviews. and maybe a good argument for using release branches 19:15
as in no more PRs targeting master, just the release manager merging in the release branch as they see fit 19:16
19:21 squashable6 left 19:22 squashable6 joined
[Coke] (release branches)++ 19:34
(clean master)++
lizmat can someone explain to me how it can be that an error message in the setting, that *did* test clean for me in "make test", "make spectest" *and* "make test" on Inline::Perl5 is breaking master on CI ? 19:39
and how I can actually see what is breaking it ? 19:40
[Coke] different versions of Perl? (I assume different OS?) 19:42
is there a broken travis report?
lizmat t\02-rakudo\13-exceptions.t seems to be the issue 19:44
I'm starting to be *real* confused now 19:45
Geth_ rakudo: 1eb712d5f9 | (Elizabeth Mattijsen)++ | t/02-rakudo/13-exceptions.t
Unbreak the build

I don't understand how this fix, which I pushed to kaipei's branch did not make it to the merge. :-(		 19:48
[Coke] weird. 20:04
lizmat the only explanation I have, is that I was still on the branch when testing? 20:06
but yeah
[Coke] well, glad you found it. 20:07
lizmat it looked *very* familiar :-) 20:08
ugexe did you test it after merging it into master? or did you test the 5 month old PR as-is? 20:13
lizmat I tested the 5 month old PR as is in the branch 20:16
found the error, pushed the fix, then merged
at least, that's my recollection 20:17
gfldex looks like under high load Proc::Async.write is loosing step 20:21
what is easy to test because travis is under high load all the time :-/ 20:25
20:32 Altai-man_ joined 20:35 sena_kun left
ugexe so do we see what the issue with that is process wise? 20:43
lizmat ugexe: yes, I do 20:44
MasterDuke i'm thinking very slowly tonight. i'm trying to install Inline::Perl5 and zef says `Failed to find dependencies: perl:from<native>`. i'm on arch linux and i do have perl installed. what am i missing? 20:48
lizmat move back one release on zef, and you'll be fine :-)
ugexe: I will be committing my non-hot fix commits as PR's in the future, and watch as they will or will not be merged 20:49
vrurg On macOS I have fixed it by symlinking libperl into my home lib/. 20:50
It was weird because I know there is system default libperl somewhere... 20:51
MasterDuke i have installed it before, don't remember having to do anything special
ugexe setting LD_LIBRARY_PATH will allow it to find the native dependency as well 20:52
why it didnt complain anytime recently is the nativecall trick it was using to determine if some nativelib was installed stopped working
github.com/ugexe/zef/commit/87b5ad...155689ee46 20:53
you can also do --exclude=perl
20:53 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Unbreak the build 20:53
travis-ci.org/rakudo/rakudo/builds/710515074 github.com/rakudo/rakudo/compare/8...b712d5f978
20:53 travis-ci left
MasterDuke huh. also, why does `zef --version` report `*`? 20:53
moritz maybe it's installed from source, not from a release? 20:55
MasterDuke moritz++ 20:56
ugexe i dont think thats it
one way that used to happen was from old rakudo star installs (from when zef didnt declare its version) 20:58
because it would be inside the $home repo it would get seen by *all* perl6/raku installations
gfldex I wonder if we got any more like #3817 but never notice because we spend to much money on fast hardware. 20:59
MasterDuke i have had some confusion because of a system installed rakudo and my built-from-source one, but i've removed the system one 21:00
lizmat R#3817
linkable6 R#3817 [open]: github.com/rakudo/rakudo/issues/3817 Proc::Async.write loses data on systems with high load
MasterDuke `[Inline::Perl5] DESTROY created new reference to dead object 'Foo' during global destruction.` is this expected?
ugexe the only other way i can think of to make zef give version * is not have zef installed and instead have it lib folder in RAKULIB 21:03
`raku -Ilib bin/zef --version` (version *)
`perl6 -I. bin/zef --version` 0.8.4
MasterDuke yeah, the first is how i've been running it
ugexe not `zef --version`? 21:04
MasterDuke correct
ugexe ah ok
MasterDuke fwiw, `git describe --tags` gives v0.8.5 21:05
ugexe right, but -Ilib doesnt get the luxury of knowing the version
the version being * for -Ilib is also a developmental feature -- that library will always be considered the highest version 21:06
(this is for all raku distributions)
MasterDuke huh. not sure i really care if --version give * or not unless it would mean problems elsewhere
`Aborting due to test failure: Inline::Perl5:ver<0.50>:auth<github:niner>` after doing `LD_LIBRARY_PATH=/usr/lib/perl5/5.32/core_perl/CORE/ raku -I lib/ bin/zef --install-to=inst#/home/dan/Source/perl6/rakudo/t/../gen/build_rakudo_home/site install Inline::Perl5` 21:07
`===SORRY!=== Error while compiling /home/dan/.zef/store/Inline-Perl5-0.50.tar.gz/Inline-Perl5-0.50/t/raku_block.t`, `Lexing code internal error (lex_read_to) at t/lib/RakuBlock.pm line 6.`, `Compilation failed in require at (eval 1) line 158.` 21:09
ugexe wait a minute 21:12
github.com/rakudo/rakudo/commit/1e...019deee7fb
this isnt a fix
github.com/rakudo/rakudo/commit/8c...4e15bR1205 21:13
not only is $.what unused now, but the .naive-word-wrapper call was removed
it really seems like work was overridden in that merge 21:14
changing the test just hides that
- "Default value '{Rakudo::Internals.MAYBE-GIST: $!got}' will never bind to a $.what of type '{$!expected.^name}'.".naive-word-wrapper 21:15
+ "Default value '{Rakudo::Internals.MAYBE-STRING: $!got}' will never bind to a parameter of type {$!expected.^name}"
is it intended that is this 5 month old PR is removing that 16 day old call to `naive-word-wrapper`? 21:16
lizmat no
ugexe that is the issue i was trying to point out earlier
lizmat then please make a PR to fix this (no sarcasm intended) 21:26
timotimo was this a case of git helpfully merging stuff that didn't look like it conflicted? 21:38
lizmat possibly, I just checked out the branch, built it, make tested and make spectested and Inline::Perl5 make tested and zef install moduled it 21:40
and then when all of that was ok, clicked the merge button on Github
timotimo i believe our CI should have one run for the code as it is at the point of the PR itself and an additional run for how exactly github would merge it, or if you rebased it, or something like that 21:41
ugexe i hate to ask, but did you not look at the diff? the very top of it is the line i mention, and you are the one who added that code 16 days ago
timotimo at least with travis i remember that to be the case
ugexe like i dont know how much of that diff is legit or not, i just happened to remember you making that one change 21:42
lizmat I did not look at the diff, as we had just had a release, and Altai-man_ mentioned a backllog of PRs and I just went down the PRs that looked like ready for merging 21:43
ugexe timotimo: the problem is the PR was 5 months old, so it would have just been based on 5 month old master or merged into 5 month old master. what would have been needed here is to re-fire the CI tests
timotimo ooh
lizmat as the PR in question was *not* marked as a WIP
timotimo the problematic code didn't make it into the release, did it? 21:44
ugexe no
lizmat not that I know, no
fg
oops ww
ugexe fyi on old PRs you can push an empty commit (using --allow-empty) to rebuild on all CI 21:45
or if our CI gets fancy enough (and enough resources) it can do that automatically when the target gets updated
timotimo that'd be a whole load of runs 21:47
ugexe yeah. thats how we do it at $work 21:49
most of my prior $works as well
$$$resoures$$$ 21:50
22:33 sena_kun joined 22:34 Altai-man_ left 23:53 lucasb joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!