Commit 5f6683be authored by totten's avatar totten

Update merger-intro.md

parent c4af4267
...@@ -117,18 +117,20 @@ Secondly, there's the permutations of how CiviCRM users build on the software: ...@@ -117,18 +117,20 @@ Secondly, there's the permutations of how CiviCRM users build on the software:
* Specialize in data migration/ETL or mobile apps or Python or NodeJS -- and rely heavily on REST integration. * Specialize in data migration/ETL or mobile apps or Python or NodeJS -- and rely heavily on REST integration.
Our current practices are shaped by experiences in previous eras. Generally, there has been a lot of feedback that Our current practices are shaped by experiences in previous eras. Generally, there has been a lot of feedback that
upgrading can be difficult, and the processes have matured in response. I look at this a gradual transition between upgrading can be difficult, and the processes have matured in response. I look at this as a gradual transition among
three eras: three eras:
1. First Era: A large number of developers had direct commit access. Reviews were not done on a patch-by-patch basis, 1. *First Era (SVN)*: A large number of developers had direct commit access. Changes were committed continuously to the trunk.
and patches could accumulate over a period of 3-9 months. Instead, there'd be a subsequent 3 month period of Review/QA was asynchronous and post-commit. We had some very good QA'ers, but we also had a structural problem: once
alpha/beta testing -- followed by another 3-6 month period of post-release stabilization. something was committed, we lost a lot of leverage for getting QA done -- which led to a long stabilization
period (several months of alpha/beta plus several months of post-release fixup).
2. Second Era: A smaller number of developers had merge rights. There were reviews, but they varied widely depending 2. *Second Era (Early Github)*: A small number of developers had merge rights. There were reviews, but they varied widely depending
on the reviewer. Reviews were always performed by the merger. Some mergers would give a light skim and approve on the reviewer. Reviews were always performed by the merger. Some mergers would give a light skim
(because they'd expect a subsequent period of alpha/beta testing) while other mergers were meticulous about testing (because they'd expect a subsequent period of alpha/beta testing) while other mergers were meticulous about testing
related use-cases. related use-cases.
3. Third Era: A smaller number of developers had merge rights. Reviews become more distributed among a broader 3. *Third Era (Later Github)*: A small number of developers had merge rights. Reviews become more distributed among a broader
set of contributors -- mergers act as facilitators and seek to enforce more particular norms. set of contributors -- mergers act as facilitators and seek to enforce more particular norms.
We're currently in the third era -- where mergers are facilitators who provide a final check.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment