Monday, October 25, 2010

Parrot's Teams: Five Scenarios

Parrot's concept of teams was rushed into service without being entirely fully-formed.  That doesn't make it an automatic disaster, but it does mean that we're figuring out inter-team and intra-team dynamics as we go.  To help this process along, here are some hypothetical (or not) events and my best guess as to how the different teams would interact in addressing them.  After each example, I've tried to list the major advantages and disadvantages that the team structure creates but more are welcome.  Note that these cases are idealized somewhat and are still speculative.  Real life is always messier.

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.



4: Lorito

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.

Thursday, October 21, 2010

Parrot has a new architect. What now?

Close followers of Parrot have probably noticed that Allison Randal, our esteemed architect, hasn't been very active over the last few months.  After her recent announcement that she'd been hired as Technical Architect for an obscure Linux distribution called "Ubuntu", folks might be wondering what Parrot's future looks like.  This is doubly true because the architect position has had a bus number of one.  If Allison were hit by bus or otherwise incapacitated, there was no structure in place to ensure that someone could step up and keep Parrot moving in a consistent direction.

Burnout has also been a problem for Parrot's past architects, partly because the architect ended up being responsible for managing most of Parrot.  We've done a great job of making Release Manager a straightforward process that can be performed by any Parrot developer with a commit bit.  The Release Manager position, however, has been the exception.  Most of the interesting roles, e.g. managing Parrot as a product or working with the wider OSS community, haven't been formalized and have fallen to the architect in the absence of someone willing to take the lead.  Allison is a capable leader and an A-list hacker, but Parrot has passed the point where it can be formally managed by a single volunteer, even one of her caliber.

It was in this environment that Jim Keenan put together a meeting of Parrot developers in Portland, Oregon.  Many topics were discussed, among which was a restructuring of Parrot to split responsibilities into separate roles.  Andrew Whitworth has already covered the idea in its current state, which will undoubtedly change as we progress.  The end result is that we'll be splitting responsibilities into 5 teams, only one of which will cover architecture.  We'll be solidifying the structure and formally voting on leads in the coming weeks, but interim leads have already volunteered for most available positions to get the process bootstrapped.  Andrew is provisionally in charge of the Product Management and in addition to posting some thoughts on the team structure, has already started fleshing out his vision for the Product Management team.

Then at last Tuesday's #parrotsketch meeting, Allison announced that she would be stepping down immediately, and that she had chosen me to succeed her as head of the architecture team.

What this means for Parrot's immediate future is that while I'll be the closest analog to Allison, Parrot won't rest primarily on my shoulders in the same way that it did on previous architects'.  It will be the architecture team's job to look to the future and determine where Parrot needs to go, but other jobs will be delegated to different teams, allowing all of us to specialize without letting anything important falling by the wayside.

Allison mentioned that after the meeting, she felt like a huge weight had been lifted from her shoulders.  She plans on staying with Parrot as a developer, but will be focusing most of her energy on Pynie.  For those of us wondering what Parrot's future looks like, we now have part of the answer and a reason for optimism.  It will take some time until we figure out just how the different teams will interact and what it means to be on a team, but the new team structure promises to help us become a more focused community and to produce a high-quality production-ready platform for interoperable dynamic language implementations.