From: Dan Scott Date: Sun, 15 Apr 2012 19:10:14 +0000 (-0400) Subject: use the Release as the central artifact X-Git-Url: https://old-git.evergreen-ils.org/?a=commitdiff_plain;h=f2770d90a80cb84d29bed0309450120789f2a52d;p=working%2Frandom.git use the Release as the central artifact Once you realize that the release is a rallying point for the entire community, the development effort that goes into creating the release becomes more apparent and the contributors to that development effort make up the development team. Signed-off-by: Dan Scott --- diff --git a/eg2012_ddd.txt b/eg2012_ddd.txt new file mode 100644 index 000000000..374c71786 --- /dev/null +++ b/eg2012_ddd.txt @@ -0,0 +1,183 @@ +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 + 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 +<5> Signed-off-by: Mike Rylander +------------------------------------------------------------------------------ + +<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?) +