1: Research Paper
We've got a couple developers who keep their eyes peeled for new research papers and we're always glad use relevant research papers to improve our code. If someone presents us with some research that they think is relevant to Parrot, here's how I'd envision our process working:
- Someone posts to parrot-dev or #parrot saying that they found a research paper we should consider.
- The architecture team takes the lead and looks over it, explicitly soliciting feedback from the community and from other teams.
- If the improvements look viable, the architecture team says so and writes up the algorithm as it's relevant to Parrot on the wiki, along with any relevant notes.
- The architecture team puts out the call for someone to implement the code.
- A Parrot hacker picks up the project.
- Someone from the architecture and product teams follow the progress of the branch and review commits.
- As the branch stabilizes, the product team benchmarks it (or ensures that it's benchmarked) to demonstrate a meaningful improvement.
- As the branch stabilizes, QA also makes sure that it has good test coverage and documentation.
- As the branch gets ready for merging, the product team checks that external projects won't be disrupted by the change.
- The code is merged, well-documented and tested and doesn't break anything for Parrot's users.
advantages: Teams will ensure that Parrot has a unified direction as new research comes to our attention. They'll also give us a clear path from paper to mergable code and will help enforce a higher bus number for new code, in addition to ensuring that code is documented and tested before it gets merged.
disadvantages: There will be a higher barrier to entry and increased dependence on the architecture team.
2: Significant Design Change
Say that a Parrot developer proposes a significant design change to address a bug or misfeature. An example of this is Peter Lobsinger's dynop_mapping merge, which made some small but significant changes to bytecode. The branch did a good job of solving the problem at hand, but one important test and a significant external project (examples/pir/make_hello_world_pbc.pir and PIRATE, respecitvely, which will be the subject of a later post) broke because of it and have yet to be fixed. Here's how the process might work with teams in full force:
- Someone files a ticket or posts to parrot-dev or #parrot about a design flaw in Parrot that requires some redesigning.
- A Parrot hacker steps forward to fix it.
- Said hacker figures out a fix and discusses it with the architecture team.
- The architecture team reviews it and either gives the ok or helps iterate the design.
- The hacker starts implementing his changes.
- While hacking, he describes the API consequences to the product QA teams, who update the relevant docs and/or add tests.
- When the code is ready to merge (and ideally while the branch is being developed):
- the architecture team reviews the code for bugs and to make sure design changes go as planned.
- the product team reviews the code for user-facing changes.
- QA makes sure that the changes are well-tested and documented.
- The code is merged, the relvant ticket is closed and everyone's happy.
advantages: Parrot maintains a unified direction across design decisions. The team structure ensures that code is well-reviewed for different aspects while it's being worked on and that when coding is done, the branch will be (mostly) ready to merge.
disadvantages: This process will take more effort from the originator of the fix to explain his thinking and to answer questions during code review. This will raise the bus number of the code, but will also raise the barrier to entry.
3: API Overhaul
Let's say that we decide that some part of our API needs a massive overhaul. An example of this may be coming soon: Andrew Whitworth has expressed some distaste at the state of Parrot's embedding API and may soon take a much-needed jackhammer to it. Here's how I envision the process working with teams:
- The product team decide that an API needs massive refactoring in order to be useful to users, either through review or due to user feedback.
- The product team figure out what the API should look like.
- The product team hacks everything together in a branch.
- QA looks at the branch to make sure that the new API functions are well-tested and that upcoming deprecations are documented
- The architecture team does a brief review for sanity.
- After the proper time for deprecations has passed, the changes are merged into trunk, causing much user jubilation.
advantages: API changes will have more dedicated code review with a specific aim. More people will be looking over code changes and will be familiar with what will be merged into trunk.
disadvantages: The refactor will be more sensitive to tuit shortages on the part of different teams.
Lorito is an upcoming major reenvisioning of Parrot at a low level. Currently most of Parrot is written in C and PIR, and the impedance mismatch between the two is a significant bottleneck. Lorito will be a very low-level and minimalist set of ops which will provide sufficient power to reimplement most of the C components of Parrot, eliminating the impedance mismatch, among other benefits. Here's one way Lorito could become a reality:
- We decide that Lorito is a good idea.
- The architecture team leads the effort to figure out a rough timeline and order of events.
- The architecture team leads the design and documentation effort to work out what a Lorito VM will look like. Everyone is actively encouraged to participate.
- Volunteers are solicited to implement prototypes to find holes in the design. These holes are filled in as they're discovered.
- As the design stabilizes, the product team looks at Lorito from a product perspective, helping further refine the design.
- Once the design is settled, hacking on the final implementation begins in earnest according to the timeline.
- The architecture, product and QA teams review major branches for design, test coverage and documentation as they progress.
- After much effort, we are able to use Lorito overlays* as a replacement for internal Parrot components currently implemented in C.
advantages: There's a consistent force ensuring that progress is made and a well-defined timeline. All relevant parties have opportunity to voice their concerns and influence the final product.
disadvantages: The process depends on having input from different teams and will be sensitive to tuit shortages.
* By "Lorito overlay", I mean anything that compiles down to Lorito ops.
5: Major Security Vulnerability
Let's say that a major security vulnerability is discovered and made known to Parrot's developers. For this example, say that the latest supported release was 3.9.0 and that the latest developer release was 3.11.0. Here's how we'd deal with this to ensure a minimal turnaround time:
- The issue is raised and both 3.9.0 and 3.11.0 are found to be vulnerable. Consistent with our support policy, the supported 3.9.0 release needs to be fixed.
- Someone writes a proposed fix, either as a patch or a branch, depending on the vulnerability.
- Representatives from QA team, product team and architecture teams briefly meet to make sure that the fix is sane (architecture), that the fix is valid, tested and documented as being fixed (QA), and that the fix doesn't negatively impact users (product).
- The fix is committed to trunk, along with a backported version for 3.9.0 . QA makes sure that new 3.9.1release is produced and distributed with appropriate notification.
advantages: We provide a known-good fix in a timely manner, along with a regression test to ensure that the bug doesn't resurface.
disadvantages: The structure requires some synchronization of schedules.
I hope that this provides a good idea of what I think the teams will look like as they work together to improve Parrot. Nothing's set in stone yet, but my hope here is to provide a starting point for further discussion.
Internal organization of the architecture is a subject for another day.