--- /dev/null
+Ecology of the Evergreen Developer
+==================================
+:author: Dan Scott
+:copyright: 2012 Laurentian University
+:backend: slidy
+:data-uri:
+:max-width: 45em
+:duration: 45
+
+One of the great assets of Evergreen is that its development community is
+readily accessible to anyone using it; accessible, that is, if you know how to
+find the Evergreen developers and speak their language! Feel comfortable
+participating in the world of Evergreen development by understanding what goes
+into making the product what it is, release by release, and take a tour of the
+processes, protocols, and standard tools employed by the Evergreen
+development community.
+
+The Release as the Central Artifact
+-----------------------------------
+(With apologies to MVLC, who proudly run the bleeding-edge version of
+Evergreen and apply updates on a weekly basis)
+
+ * Most of the Evergreen community focuses on official releases (2.0.10,
+ 2.1.1) for their testing and communication efforts
+ * Releases provide a common ground - local customizations aside - for
+ comparing workflows and expected outcomes in documenting best practices
+ and pinpointing bugs
+ * Releases represent the culmination of efforts on the part of all
+ contributors to develop the best possible result; a successful release is
+ (or should be) a matter of pride for the community
+ * All who contribute to a successful release are part of the development
+ team, and thus can be considered developers
+
+Who, then, are developers?
+--------------------------
+ * Anyone who writes code for OpenSRF or Evergreen is a developer:
+ ** _Committers_: those who have the ability to commit code to release
+ branches
+ ** _Code contributors_: those who write and commit code to working
+ branches or patches
+ * _Testers / Bug wranglers_: those who test releases or branches or
+ patches and report positive or negative results, as well as those
+ who keep bug status information up to date
+ * _Technical writers_: those who write documentation and submit it to
+ the http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig[Documentation
+ Interest Group]
+ * _Translators_: Those who translate U.S. English _strings_ into a
+ different locale (Armenian, Finnish, or Canadian English all count)
+ * _Release team_: those who create the release tarball and publicize it
+ on various channels
+
+Release processes
+-----------------
+ * Evergreen currently creates two
+ http://evergreen-ils.org/dokuwiki/doku.php?id=versioning[different kinds of
+ releases]:
+ ** Major/minor _feature_ releases (2.0.0, 2.1.0, 2.2.0) - in which new
+ features are added to Evergreen
+ ** _Patch_ releases (2.0.1, 2.0.2, 2.0.x, 2.1.1) - in which changes are
+ limited strictly to bug fixes and updated translations
+ * Evergreen 2.2.0 marks our first attempt to adopt a _time-based_ feature
+ release
+ ** Instead of defining a release by which features we plan to add, we
+ define a release as a cumulative sum of all new features which were
+ considered stable enough to commit to the release branch at a given
+ point in time
+ ** Rough agreement to target a 2.2.0 release in March 2012, with subsequent
+ feature releases six months apart
+
+Release processes - support
+---------------------------
+ * http://markmail.org/message/53umdzope7nobtqb["Time based releases occur
+ every 6 months with each release getting 15 months of support (12 for
+ general bugs and 3 more for security)."]
+ ** So, when 2.2.0 is released, the 2.1.x series will continue to be
+ supported with patch releases, but 2.0.x will only get a new release
+ if a security bug is found and fixed
+
+ * Problem: we have not created a patch release since 2.1.1 in November 2011
+ * Suggestion: adopt time-based patch release cycles (monthly, if a commit
+ has been merged?) for patch releases as well
+
+Road to a release
+-----------------
+With some definitions drawn from the Evergreen wiki
+http://evergreen-ils.org/dokuwiki/doku.php?id=versioning[page on versioning]:
+
+ . _master_ - Code that has been reviewed, tested, and committed to the core
+ code repository
+ . _alpha_ - Features are mostly complete, release is intended for testing,
+ feedback, and documentation
+ . _beta_ - Hard cutoff for new features, database schema changes, and string
+ changes
+ . _release candidate_
+ ** Contains no show-stopper bugs
+ ** New and updated translations can be integrated
+ ** All functionality and upgrades from previous releases have been tested
+ . _Golden Master_ or _Generally Available (GA)_
+ ** Contains no show-stopper or critical bugs
+ ** Release notes, installation notes, and upgrade instructions are ready
+
+Committing code to the core repository
+--------------------------------------
+ . Developers commit code to _working branches_ - publicly visible copies
+ of the code repository that contain only the changes pertinent to a
+ particular bug or feature
+ . When a developer is satisfied that their branch:
+ ** Fixes the bug or completes the feature
+ ** Does not introduce any regressions
+ ** Is adequately documented in the release notes
+ ** And is formatted as one or more clearly-commented commits
+ then they mark a corresponding http://bugs.launchpad.net/evergreen[bug]
+ with the tag *pullrequest*
+ . Another developer reviews the associated changes, tests to ensure that
+ no bugs were inadvertently introduced, and _signs off_ on the commits in
+ the branch - either pushing their own working banch, or pushing the signed
+ off commits directly into the core code repository
+
+Anatomy of a git commit message
+-------------------------------
+[source,txt]
+------------------------------------------------------------------------------
+<1> commit 218722deb2a57f8b1f94869e12602c1286c10aae
+<2> Author: Bill Erickson <berick@esilibrary.com>
+ Date: Wed Mar 21 14:34:19 2012 -0400
+
+<3> TPac: non-inherited org unit visibility : hide copy counts
+
+ Avoid showing copy counts for non-opac-visible org units in the search
+ results and record details page. This is important when the
+ 'opac.org_unit.non_inheritied_visibility' global flag is enabled, as org
+ units along the tree may be non-visible.
+
+<4> Signed-off-by: Bill Erickson <berick@esilibrary.com>
+<5> Signed-off-by: Mike Rylander <mrylander@gmail.com>
+------------------------------------------------------------------------------
+
+<1> Commit hash - uniquely identifies the associated changeset
+<2> Author - identifies the changeset creator
+<3> Commit summary - brief one-line summary of associated changes
+<4> Author's sign-off - asserts that the author acknowledges the
+ http://git.evergreen-ils.org/?p=Evergreen.git;a=blob_plain;f=DCO-1.1.txt;hb=refs/heads/master[Developer's
+ Certificate of Originality]
+<5> Committer sign-off - asserts that this person has reviewed and tested
+ the changeset and believes that it is ready to be part of the core
+ repository
+
+What do developers do?
+----------------------
+ * Create Evergreen releases
+ * Write code to enable new features
+ * Document
+ * Create, find, and fix bugs
+ * Communicate
+
+Communicate - Mailing lists
+---------------------------
+ * Oldest form of group communication: email
+ * Plain text, low bandwidth, efficient
+ * Can be hard to search - use
+ http://dir.gmane.org/gmane.education.libraries.open-ils.devel[Gmane] or
+ http://markmail.org/search/?q=list%3Aorg.georgialibraries.list.open-ils-dev[Markmail]
+ * Generally referred to as the _Developer's list_ but
+ http://evergreen-ils.org/listserv.php[Mailing lists] calls it the
+ _Technical discussion list_
+ * Now mostly used for people seeking help from developers; very few threads
+ initiated by committers
+
+Communicate - IRC
+-----------------
+ * Internet Relay Chat
+ * *_The_* most important developer communication channel
+ * Oldest form of instant messaging
+ * Plain text, low bandwidth, efficient
+ * *Very* hard to search
+ * Activity limited mostly to UTC -4/-5 developer hours
+
+Communicate - Google Hangout
+----------------------------
+ * Newest form of group communication
+ * Attempted during Hackfest 2012
+ * *Extremely* hard to search (impossible?)
+
projects / working / random.git / commitdiff