Playing for Team Human: Celluloid 0.50.0

[digitalextremist]

Replaces #789 with overarching reboot, framed as GSoC 2020 challenge:

Top Priorities

• End Gempocalypse: Do analysis of all gems and repositories, and propose the minimal number they can be condensed down to. This is a judgement call, like the call made to originally split them. That decision was under pressure at the time, like you will be too. Ideally, we can delete several repositories, not even just archive them. People can be asked to change their dependencies and continue to use < 0.50.0 with breaking changes declared. Rails would eventually change their implementations, and a ticket addressing each downstream gem ought to be opened to anticipate the problems they will have, potentially calling out specific places where Celluloid is used.

• Crash-Test Dummy and Documentation by Example: A reference implementation ought to be written to demonstrate all supported functionality; this proves 0.50.0 is battle-ready, and avoids a ton of downstream grief. Plus it teaches people why Celluloid is a serious source of Power when we need systems much faster, and these systems need to be ridiculously industrial-strength.

• Test Suite We do not really trust the test suite. It's in the back of our minds that it's not really telling us whether releases are viable, due to race conditions, a patchwork of different styles, and missing units. Overall, this could be a project in and of itself, if we did 0.50.0 by TDD, and treated Celluloid like a re-write rather than a refactor. I would hear a proposal for either case. But I would also expect the TDD example to be "mostly there" in replacing the current gem.

• Roadmap and Standardized API and Behaviors: The problem is not that Celluloid isn't working, it's that it hasn't been maintained in a while, so long the world stopped crying out for help with Celluloid issues. What caused the problem ( leading to it going unmaintained ) was that changes in 0.17.* introduced a lot of breaking changes, differences in convention, and destabilized a lot else in the process. The community didn't switch gears, because there wasn't enough put into warning everyone, providing examples, and generally being a good master of ceremonies for the movement of Celluloid. My bad. We need a more deliberate roadmap. When I stopped maintaining Celluloid it was because more issues were coming in than justified even reacting to them any more, while also working to apply Celluloid in business and academic cases in the field.

• Visual models of all existing and future object changes; graphically represent the design.

• Challenges help the world understand why Celluloid matters right now more than ever:

Ruby has Celluloid because they are related concepts: the joy of Code and the joy of Power. Right now, people need empowerment and joy and need to be using tools which join those two into a lifestyle, otherwise... do we want to know what otherwise looks like here? This list doesn't need to be complicated, it just needs to prove the point that Celluloid is a serious tool in the story of Humanity, and we can do amazing things with it. Some of us have done truly awe inspiring things with Celluloid, and once it is revamped, veterans will come out with stories to support Challenges and encourage coders to look differently at what computers are capable of.

[digitalextremist]

@emesepadanyi and @harsh183 I reframed the project a bit differently than mentioned in Slack:

1. A key component of this project is taking over primary maintenance of 0.50.0 supported by myself and @tarcieri, past students like @dilumn, and others who will no doubt show up when this starts showing activity. There is a silent ocean of supports of Celluloid just waiting for proof of life.

2. You need to know Celluloid intimately to revamp it. In the remaining ~7 days you have to file proposals, the research into Celluloid and the proposals you make ( which I say ought to be Issues you post here, not just a proposal in the GSoC system ) ought to be work in and of themselves, which helps us understand "where it hurts" and what the next version ought to be.

Thank you to @emesepadanyi for the insightful question which prompted this, paraphrased:

Are the items closed for inactivity actually worth solving, or do I focus only issues still open?

---

So much of F/OSS is the art of figuring out what the hell is going on in a repository. And life is about going through galaxies of repositories, remembering that one object you created a year ago and bringing it back in the next project; in general, moving through entire universes of code easily.

Your challenge, is to do that in order to come through the front door into this year's program.

[digitalextremist]

By the way, as far as how the overall project could break down:

• Re/creating a test suite would make everything from there sane; and lead into the reference implementation well. I cannot overemphasize how weird the test suite became.
• Those would likely also answer everything about what gems truly ought to exist, and which ones would be terminated, as part of "catching up" the code to the test suite's demands.
• Then bringing together diagrams, challenges, documentation pieces, as well as finishing a reference implementation would come together smoothly... with most of that being last touches.
• Roadmap would be the last thing, and during everything done, a new process for indicating the state of the system and changes to it ought to be pretty well demonstrated.

[digitalextremist]

Also I setup a Project for this, with an Agile board to use as we go forward.

[digitalextremist]

Per @emesepadanyi question:

The Crash-Test Dummy reference implementation ought to be an asynchronous task, like a Future resolving in the background of the other waypoints, not started and ended at the beginning sessions. That would be incrementally produced, and changed it in waves, then completed it at the end.

Also her idea of writing documentation using the reference implementation as the example code is the best way here. I would add that a screencast of demonstrations would be phenomenal.

[digitalextremist]

If the Crash-Test Dummy could be a Coronadevice ( "chaos monkey" ) for at first just HTTP/S systems, I will send t-shirts after the pandemic. I would also sell shirts as an income stream for Celluloid and donate the domain blast.monster.

[digitalextremist]

Thanks @kares for the correction, yes; @harsh183 confirmed on #779, and I've added the 0 I omitted numerous times.