Patchwork: Maintainer needed (or deprecate)

[evbogue]

This came up on the ssb network, so I thought I'd bring it up here, as the Patchwork project has not been uploaded to git-ssb.

This is my formal request to either find a maintainer for Patchwork or deprecate the project (when Patchbay reaches feature parity with Patchwork's onboarding experience).

All of the development talent at this point is focused on Patchbay, and it doesn't appear that anyone has a huge interest in maintaining Patchwork. It's been mentioned on the network that it's a confusing/weird experience to be onboarded using Patchwork only to find all of the developers are using a different client, Patchbay.

While Patchbay isn't 'quite there' (see %9+iWrnfTJqUAWLwtJ88mpKR3ybJZj4DWcHlQz/K9/lw=.sha256), I think that all of the necessary features will be implemented soon and we should be encouraging people to switch to Patchbay.

While Patchwork's onboarding experience is still superior to Patchbay's, there are also features in Patchbay that are not available in Patchwork -- such as being able to see git-ssb messages in the client.

If you're reading this and want to take responsibility for maintaining Patchwork, let your voice be heard below!

[mmckegg]

Add me! I'll make sure it gets a proper funeral pyre! 😆

I have some ideas to milk a little more value out to keep it going in the mean time before patchbay catches up.

[evbogue]

ok, @mmckegg will be deemed the maintainer of Patchwork until the funeral pyre.

[mmckegg]

So I just spent the last 30 mins digging into the code and structure of patchwork, and my brain exploded a little. Was a combination of the precompile step, too many deps, react+jsx, import statements. A real shame, I just have no idea where to start solving the perf problems (my biggest issue).

I'm still happy to accept the "maintainer" status, but I've had a bit of a change of heart in regards to the graceful exit. Have decided instead to start using patchbay, and focus my energy on getting that up to my expectations. Gonna try and create patchbay "Patchwork" edition. It will be my personal opinionated version that hopefully will be able to replace patchwork for people who like that style.

[dominictarr]

@mmckegg yes please! btw, check out my opinionate branch, where different parts of the app are separated into layers and can easily be enabled and disabled. It should be very easy to run multiple different opinions without having to fork development

[fredhampton]

What is the pref issue ?

On October 26, 2016 at 4:58:48 PM, Matt McKegg ([email protected]) wrote:

So I just spent the last 30 mins digging into the code and structure of patchwork, and my brain exploded a little. Was a combination of the precompile step, too many deps, react+jsx, import statements. A real shame, I just have no idea where to start solving the perf problems (my biggest issue).

I'm still happy to accept the "maintainer" status, but I've had a bit of a change of heart in regards to the graceful exit. Have decided instead to start using patchbay, and focus my energy on getting that up to my expectations. Gonna try and create patchbay "Patchwork" edition. It will be my personal opinionated version that hopefully will be able to replace patchwork for people who like that style.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[dominictarr]

@fredhampton it can take a while to start up, and some threads take a while to load etc. btw, if you are gonna reply from email, can you clear the message you are replying to? your post also includes the message you responded to.

[pfrazee]

I'd suggest focusing on Patchbay instead of maintaining PW. Patchwork was the prototype, and it never got the push into production-quality that it needs.

A few thoughts about what's up with this codebase:

1. Factoring Patchwork out into Patchkit didn't work as well as I hoped. Part of the problem was, it was a huge amount of work, and it added a lot of indirection (each module import) which made things harder to follow. Modularizing can have the benefit of improving documentation (with each module having a readme and tests), and I did make an effort toward that, but it still needs more effort. (Everything currently in the Patchkit org was the result of 2 weeks of focused effort; it was hard, slow moving. After the 2 weeks, I had begun to move toward Beaker, so I think Patchwork suffered in the long run for the change.) If you do resume work on Patchwork, I'd strongly suggest you consider a revert back to before the Patchkit refactor.
2. The startup time is the result of computing indexes on bootup. This was a short-term choice that simplified development while the data model was changing frequently, but it started to create a performance issue about 3-4 months ago. If you want to fix patchwork's startup performance, update the data layer to store those indexes, and you'll get an instant speed boost.
3. Some threads are slow to load. I don't know if that got fixed yet in PW, but I did manage to fix it in this mail app that I wrote after PW. In summary: don't use ssb.relatedMessages because the outputted tree is unbounded, and reduce the payload sent over RPC as much as possible.
4. Just a note about the precompile: After working on Patchwork, I switched from React to yo-yo, which I like a lot. It ditches the precompile step (if you can target an es6 platform) and it's much lighter weight. I don't think React was necessarily the wrong choice for Patchwork, but if the precompile step bugs you, yo-yo is a winner.

[dominictarr]

@pfrazee we actually got a fix in a little while back that at least made relatedMessages better a while back. Some parts modularize better than others - for example, I was able to just use suggest-box in patchbay, no problems. I think image cropping could have been a candidate for that too, but even if you get to make a few nice widgets, you are still gonna end up with a lot of stuff that is just "opinions" coupled to you app, not generic enough to modularize out. I distinguish these as "hinges" and "MDF" in "ikea architecture" %5U+7Fblfzf1iO+bE+anI/wn/L9L0LkpM5A9+Mlf0Wcc=.sha256

[pfrazee]

@dominictarr yeah I agree. UI is hard to write generically. I'm curious to see what happens with Polymer/Web-Components, because one of their stated goals is to improve UI composition and modularity. I'm default-skeptical that they'll succeed, but it's getting merged into browsers, so I guess it's all-aboard for that experiment!

[dominictarr]

@pfrazee yup, the thing that I think has most succeeded at being both modular (ish) and UI is drupal, to a lesser extent wordpress. There is a large community and thousands of modules, you can build a lot with it just tweaking and configuring.

[mmckegg]

@pfrazee thanks for the info!

Yes, I'm onboard with the rollback to pre-patchkit days.

And great news: I've had some success fixing the major perf issue. I think with this patch, perf is back to what it was a few months back.

Startup time isn't actually too much of a big deal, it was just the lockups (that could last multiple minutes) that were frustrating. On my machine (with the patch), it now only takes about 12 seconds to load.

[ahdinosaur]

v3 has been released! :tada:

closing, since this is now actively maintained by @mmckegg, with support from others in the community like myself.