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 |