problem-solving
problem-solving copied to clipboard
Raku
There's a huge PR/issue deficit in the Rakudo repo
Only one issue is closed for every 6 open (roughly), and one PR for every two. There are too many PRs, and that will discourage people from sending new PRs. Someone with a stale PR from two years ago will probably never contribute again to the community. So, can you think about some way to deal with this? Clear the backlog of PRs and try to get a bit more up to date with issues?
Branches are also a problem. There are more than two hundred. That's probably better left to another issue here.
So, some possible ideas to solve that:
- Devote part of the time every release to address and clear old PRs. Maybe devote exclusively a release cycle (maybe the one in the summer?) to review and accept/comment/close old PRs.
- Deal with new issues ASAP: at least label them, vet them (for adequacy, relatedness) and close them if they are not going to be addressed
- Devote one squashathon to them?
Any new idea? What would be the best way to deal with this?
Is the issue solely with old PRs or should we be discussing old tickets here too?
I would say both, but given the size and the optics PRs would be, for me, a priority.
OK, there are 74 in total, that's not too many. Some of them are probably outdated, and there are many submitted by rakudo devs. So maybe a good start would be to ping some authors who are on IRC, and see what number of PRs we have after that.
That's not a solution, of course, because even if we get that number down to 0, a year or two from now we'll have that issue again.
Another thing is that from now on language design issues will be opened here, not in the rakudo repo. Hopefully this will make it easier to focus on actual bugs and other compiler fixes.
Same goes for the MoarVM and NQP repos.
I'm not sure a squashathon can be of direct help here as the job of merging PRs is restricted to the core devs. A squashathon could be useful with doing the legwork before an actual merge. (Do they still compile? rebasing)
I do like the idea to somehow incorporate PR work into the release cycle. The most effective way would probably be to treat unprocessed PRs as blockers. That would be a bad idea though as it would cause PRs to be merged before the release, not afterwards.
There would be too many blockers... There are ~ 70 PRs right now. I think it would be better to devote a "slow" cycle to them, like the one in Christmas, or one of the months in summer. Anyway, taking a look at them from time to time would not hurt...
@JJ True. Turning PRs into blockers now definitely won't be much help (and would probably also offend some people). But in the long run (once we have arrived at a sensible level of open PRs), I do like to have a monthly incentive to do the PR work. I'd say without a general change in procedure to provide such an incentive to do the PR stuff, they'll start piling up again.
I would like to share my latest thoughts on this subject based on own experience.
For a very long time it is assumed that speed is the main problem of rakudo. I've got a feeling that this assumption is erroneous. Over the last year I was trying to implement a couple of projects for own use. None was completed because every time my code bumps into a bug. Each time workarounding the bug would cost me significant rewrites of the code including changes to the interfaces. Eventually, I came to the conclusion that trying to fix these bugs would be of more use to me. But this is me who is a bit of a special case in some respects.
But let's imagine a decent programmer who somehow became interested in particularly Perl 6. He is not bound to any language and may choose of any alternatives on the market equally well. So, the person got attracted by the really amazing features Perl 6 provides. He starts a test project. A 1000 lines of code later – bug. Ok, he gets around it, then proceeds further – and in another 500-1000 lines another bug strikes.
When I imagine myself in a situation like this – my choice is unambiguous: no time wasting, try another lang. Now, if we add what media and other communities think of Perl on top of it then barely 1 out of who knows how many would resist the impulse and stay with us.
Another thing. Lets imagine that our hypothetical apprentice won't just get around the bug but would report an issue. How many of them are never replied? 306 out of 832 opened as of now. Then he goes further and produces a fix and creates a PR. As of now, 20 out of 80 are never commented.
Isn't it really discouraging? Could it be the reason the community doesn't grow as fast as it could? Perhaps time has came to change focus from new features and speed to reliability?
To be sure, not all of the issues might be real bugs, and not all of the PRs real bug fixes. But again, it really needs to be taken care of. Next squashathon will be devoted to rakudo bugs, maybe we could dig into some of these issues... But that will only put a dent on it. We really need a long-term strategy to reduce this amount of issues...
@vrurg I agree with your thoughts. When I was a release manager, I've put extra effort into making sure that at least we're not introducing new bugs. As to fixing existing ones, I have no idea how to drive that forward. The existence of the problem-solving repo will likely result in less new features being added, which is a good thing in that regard (right?). Squashathons are great but are not very efficient for rakudo-related work, specifically because existing hardcore devs don't feel like participating, or so it seems. Then there's also grant work, and i already expressed in 2016 that I'd prefer to see more work on reliability rather than performance. On a more positive note, things mentioned in my comment were actually fixed. Moreover, nowadays I'm actually using perl 6 in production without a fear of constant headache and crashes.
Isn't it really discouraging?
It's less than awesome for sure, but what is your proposal? What can we change to make things better? I'm looking for something actionable.
My point is not about wether they're real or not. It is about newbie reaction to all this. So, the strategy must also do something about returning to people, letting them know that their reports are not thrown into void but considered.
Unfortunately, I know how resourceful the task is. And I know how much people do to react and help and not asking for more. Just maybe change of focus.
@AlexDaniel the final statement of my previous comment is the only proposal I see. Priority should be given to bug fixing. No other solution, considering the lack of resources. I'm a realist and a pragmatist.
This is also the choice I've made for myself: just picking own tickets and trying to develop fixes for them. If at some point I'll have them all closed then would start iterating over other reports.
I'm stealing this issue for now. Thing is, rakudo/rakudo is not the only repo that suffers from this, and I'm currently looking into other related problems, so this ticket is somewhat aligned with my current efforts.
Now that we've had a couple of regular, monthly, cycles devoted to new features, and the PR/issue list has kept growing, could we maybe use next cycle exclusively to PRs? Or issues?
Oldest issues are 2.5 years old. Oldest PR is a whopping 6.5 years old. My proposal is that once we're back on track, reducing that load and addressing them, at least the oldest, would help show responsivity towards the community of users.
Oldest tickets are actually more than 10 years old. It's just that rakudo issue tracker was blocked before 2.5 years ago?
@AlexDaniel We should start with those ones, yet. I can think about several strategies, like for instance every odd month release is devoted exclusively to bugs and old issues (odd =~ old, get it?). Or one developer exclusively devoted to that, out of the group that forms the core. The problem with so many issues is that the origin of some regression issues that arise might be there, but bigger one is that it's impossible to know them all, so many of them might actually be already solved or simply irrelevant.
Well, I understand that my reply was a bit too festive, but it's literally my birthday today. On a more serious note, PRs are a bit easier to tackle. All you need is some time and courage, just hunt down PR authors and ask them what can be done about their PRs. So you can start with that.
Happy birthday! If you mean "you" as in "me", I don't have the commit bit in Rakudo. I can still ask, but the final word will not be mine...
I don't have the commit bit in Rakudo
Invite sent. Now you should be able to take care of tickets and PRs.
Later you can also do this:
https://www.perlfoundation.org/contributor-license-agreement print it out, sign it, scan it in (resize your scan to 250KB or less). Email to trademark -at- perlfoundation.org and don't forget to CC will at coleda.com. PDF: https://github.com/rakudo/rakudo/files/3907678/CLA.pdf
@JJ also, if you can get your ass back to IRC it'll make some things easier.
During confinement, I have too many open messaging applications and I'm starting to be kind of overwhelmed. But I guess that's an order so I'll have to do that too...
@JJ it's not an order, we're all volunteers here. But people have been sending messages to you so it's good that you finally received them. Also, things just go quicker on IRC (without email notification spam for every single message).
On Dienstag, 3. März 2020 07:24:10 CEST Juan Julián Merelo Guervós wrote:
I can think about several strategies, like for instance every odd month release is devoted exclusively to bugs and old issues (odd =~ old, get it?). Or one developer exclusively devoted to that, out of the group that forms the core.
Both strategies would dictate priorities to volunteers. Sorry, but if we have an issue with rakudo at work and I can solve it, I will do that rather than work on some PR or issue that has never been important enough for anyone to actually do something about it in years.
Why is an issue important just because it's old? Many free software projects come to the exact opposite conclusion: if an issue is old and hasn't been touched in a long while, chances are that it's either not an issue anymore or just not important enough for someone to bother fixing it.
Now PRs are a slightly different story. We're lagging there because we don't have enough (wo)man power to review them and guide the developers towards a mergable result. But to get more core developers who can do so, we need to give new contributors a good experience (including timely answers). It's a bit of a chicken/egg situation.
That said, I can't help but notice that for many of these PRs there was a reaction by core developers (surprisingly often even from me) and there were design and/or implementation issues that needed to be resolved, which the developer never did. I don't know what to do about those. Is someone motivated enough to whip up a patch but lacking the perseverance to push it though a real candidate for a core developer?
