diff options
Diffstat (limited to 'spm-slides.tex')
| -rw-r--r-- | spm-slides.tex | 58 |
1 files changed, 53 insertions, 5 deletions
diff --git a/spm-slides.tex b/spm-slides.tex index 6296dec..18983f2 100644 --- a/spm-slides.tex +++ b/spm-slides.tex @@ -484,6 +484,10 @@ Reasons; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Use Branches to Avoid Bottlenecks} +Helpful for collaborative development. + +Release branch, bugfix branch, experimental branch, etc. + Branches are valuable because they turn a scarce resource — working room in the project's code — into an abundant one. Branches are cheap to make. @@ -498,9 +502,13 @@ Use branches liberally. Most branches should merge their changes back into the main line and disappear, as soon as possible. +When we do the merge, indicate that this is a merge in the log message. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Pull Requests} +Have you heard of {\em patches}. + A \underline{pull request} is a request from a contributor to the project that a certain change be "pulled" (merged) into the project. @@ -537,6 +545,8 @@ Use pull request to communicate ideas. Use pull request to learn the code base. +Once your change is merged, your change is part of the software. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Essential Git Commands} @@ -715,6 +725,8 @@ Git and Github. https://www.mercurial-scm.org +http://fossil-scm.org/ + https://subversion.apache.org @@ -2003,6 +2015,11 @@ that went into the code repository, and never complained about being the single reviewer. +Case study. Millions of lines of code and hundreds or thousands of +developers. Each commit (relatively small in size) should reviewed by +sub-domain experts before it is merged to the master branch. Code +review makes such large-scale collaboration possible. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Technical debt} @@ -2223,7 +2240,7 @@ A small, focused project - the email gateway features of the bug tracker. Issue A large, complex project - a dedicated discussion forum. Your project should have a \underline{prominently-placed} description of all the available public forums. See page 43 in the text book for an example. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Choosing the right forum management software} +\foilhead{Choosing the Right Forum Management Software} Both email- and web-based access. @@ -2254,8 +2271,25 @@ Archiving. https://mail.python.org/pipermail/python-dev/ -SPAM prevention. Purpose: (1) Avoid your list/forum to be occupied by spam posts. (2) Avoid your list/forum to be a source of email addresses for spam harvesters. Measures: (1) Only auto-allow postings from list subscribers. Non-subscribers' posts go to a moderation queue. (2) Filter posts through spam-detection software. SPMX. (3) Moderation. Mailing list moderation -is strictly about keeping the list free of spam, and of wildly off-topic or otherwise inappropriate emails, nothing more. (4) Address-hiding in archives. jrandom@somedomain.com \\to jrandom\_AT\_somedomain.com \\or to jrandomNOSPAM@somedomain.com. +SPAM prevention. Use a spam filter. + +Purpose: + +(1) Avoid your list/forum to be occupied by spam posts. + +(2) Avoid your list/forum to be a source of email addresses for spam harvesters. + +Measures: + +(1) Only auto-allow postings from list subscribers. Non-subscribers' posts go to a {\bf moderation queue}. + +(2) Filter posts through spam-detection software, e.g., SPMX, Apache SpamAssassin, SpamProbe. + +(3) Moderation. Mailing list moderation +is strictly about keeping the list free of spam, and of wildly off-topic or otherwise inappropriate emails, nothing more. Consider moderation burden. + +(4) Email address-hiding in archives. At least obscure the real email address. + jrandom@somedomain.com \\to jrandom\_AT\_somedomain.com \\or to jrandomNOSPAM@somedomain.com. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{The great Reply-to debate} @@ -2288,12 +2322,20 @@ The project's repository should be browsable on the Web. Browsability is important because it is a lightweight portal to project data. -Browsability also implies canonical URLs for viewing a particular change. +Browsability also implies canonical URLs for viewing a particular change -- no ambiguity +during discussion. % Skipped: Singularity of Information + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Singularity of Information} + +TBD. + + % Skipped: Authorization %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Commit notifications / commit emails} +\foilhead{Commit Notifications, Commit Emails} Every commit to the repository should generate a notification in a subscribable forum/mailing list. @@ -2303,6 +2345,12 @@ Who made the change, when they made it, what files and directories changed, and Include the diff, set ``Reply-to'' to the regular development list. +Let subscribers know what is going on at the code level. + +A sense of community. + +Commit email list versus Development mailing list. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Bug Tracker} |