[BUG BOUNTY] $500 Reward to improve the performance of Meteor on Windows

[wreiske]

[BUG BOUNTY] $500 Reward to improve the performance of Meteor on Windows

[wreiske]

what's the deadline to submit the solution??

I missed adding that to the original description. The bounty will be live for 6 months until Sunday, June 23, 2024 unless someone submits a completed solution before that. I am hoping for a solution to be included in the 3.0 release, but that could be a stretch.

[harryadel]

This needs to be promoted a hella lot more.

@Grubba27 @acamikuro
official channels: dev.to, X/twitter & blog

@wreiske
A forum post, and nobody should've the honors to do it but you.

I'd also ping @StorytellerCZ but I think they're already featured it on their podcast if I'm not wrong.

[rizzling]

@rizzling It doesn't seem to have even been attempted before @rizzling It'd be awesome if you can give it a go!

okay cool, I think I'm gonna give it a try. I will let y'all know if I do so with /attempt ;)

[wreiske]

@wreiske Just to be sure, this issue is focused on doing a RCA of the slowness and intermittent failure of the meteor update command {1. research}, fixing the performance issue(s) {2. performance fix}, show that performance is improved {3. benchmarks / regression tests} and explaining what was done {4. report}, correct?

Explicitly doing the same activities {1, 2, 3, 4} for the other CLI commands used for illustrating the performance issue above i.e.

• npm i -g meteor,
• meteor create …,
• meteor and
• meteor add … is not in scope, correct?

I imagine the performance fix for meteor update… will likely resolve most of the performance issues observed in the other commands mentioned and if not, the report’s findings will generally point you in the direction you should be looking to fix them. Is my understanding correct?

Yes to everything except it should also include the performance fix of package installs. I wouldn't consider each command needing the full RCA process.

The success criteria mention two things specifically: Implement solutions that 1. significantly improve the performance and stability of meteor update and 2. package installations on Windows.

My biggest frustration always comes when doing a meteor update and a meteor update --all-packages. Running a meteor add package-name may share a lot of the same underlying code as the meteor update when it runs package updates, so yes, it would be safe to imagine RCA of meteor update performance will likely also help understand other commands. Running meteor for the first time on a project that you don't have packages for will also be much slower on Windows because it has to go and fetch all of the dependencies. It's my assumption that would also share some of the underlying code for packages that should be covered in the RCA of the performance issues and whatever fixes are required to improve the performance.

[wreiske]

@harryadel , thanks for the suggestion. I've posted to the forums here: https://forums.meteor.com/t/bug-bounty-500-reward-to-improve-the-performance-of-meteor-on-windows/61236

[algora-pbc]

💎 $500 bounty created by wreiske
🙋 If you start working on this, comment /attempt #12935 along with your implementation plan
👉 To claim this bounty, submit a pull request that includes the text /claim #12935 somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to meteor/meteor!

👉 Add a bounty • Share on socials

[mrkirthi-24]

what's the deadline to submit the solution??

[mrkirthi-24]

I missed adding that to the original description. The bounty will be live for 6 months until Sunday, June 23, 2024. Thank you.

Thank you @wreiske.

[ayewo]

@wreiske
Just to be sure, this issue is focused on doing a RCA of the slowness and intermittent failure of the meteor update command {1. research}, fixing the performance issue(s) {2. performance fix}, show that performance is improved {3. benchmarks / regression tests} and explaining what was done {4. report}, correct?

Explicitly doing the same activities {1, 2, 3, 4} for the other CLI commands used for illustrating the performance issue above i.e.

• npm i -g meteor,
• meteor create …,
• meteor and
• meteor add … is not in scope, correct?

I imagine the performance fix for meteor update…
will likely resolve most of the performance issues observed in the other commands mentioned and if not, the report’s findings will generally point you in the direction you should be looking to fix them. Is my understanding correct?

[ayewo]

Yes to everything except it should also include the performance fix of package installs. I wouldn't consider each command needing the full RCA process.

Thanks for the confirmation.

(In a lot of cases, merely switching from npm to a performance oriented alternative like yarn or pnpm, which are known to aggressively de-duplicate dependencies during installation, can shave considerable time off package installs. It’s fine if switching package managers is not an option.)

[harryadel]

Glad to see folks giving back to the Meteor community. Kudos to you @wreiske and your employer.

[rizzling]

still open? or has @wreiske or someone else took the bounty already ?

[harryadel]

@rizzling It doesn't seem to have even been attempted before @rizzling It'd be awesome if you can give it a go!