Per-subject/tool branches for easy lesson mixing and maintenance

[wking]

I've been thinking about the isolated-feature-branches approach that I used #89, and I've started toying with what that would look like for lesson content (#89 only uses it for pre-boot-camp setup). Ordinarily, I'd post this message to discuss@, but following @gvwilson's request, I'll open this one as an issue. I'm happy to move this discussion back into a mailing list if someone knows where this sort of workflow discussion belongs.

The isolated-feature branch workflow looks something like this:

1. New instructor getting ready for a boot camp

   a. Create a branch for the new boot camp, possibly in its own repository, cloning

   $ git checkout -b 2013-10-my-camp origin/master
   

   b. List possible subjects:

   $ less instructor.md
   

   c. For each subject you want to cover, merge the subject branch

   $ git merge git://github.com/wking/swc-boot-camps.git version-control
   …
   

   d. For each subject, pick and merge a tool

   $ less version-control instructors.md
   $ git merge git://github.com/wking/swc-boot-camps.git version-control-git
   …
   

   e. Publish your student-facing setup notes as you see fit for your tool/branch choices, possibly just by pointing students at the GitHub browser for your new branch.

2. Old instructor getting ready for another boot camp

   a. Create a branch for the new camp, based on something you've used in the past:

   $ git checkout -b 2013-10-my-camp 2013-04-my-last-camp-or-other-favorite
   

   b. You've been hearing good things on discuss@ about @wking's version-control-git branch, so you try switching over to it, dropping your old notes:

   $ git rm -rf version-control/git
   $ git commit -am "version-control/git: I don't want to maintain this anymore" 
   $ git merge git://github.com/wking/swc-boot-camps.git version-control-git
   

   c. Publish…

The drawback of this multi-branch approach is that you don't have an out-of-the-box experience (unless folks want to maintain "distribution" branches collecting a useful set of topic branches). The upside is that we don't have to agree on everything across tools and subjects before we can collaborate on a single subject/tool note set. It also makes maintainer-ship obvious; version-control-git is in my repository, so I'm going to maintain it, and that's where you should sent pull requests. If I'm doing a bad job, and jdoe starts an alternative branch with long-form notes and sexy graphics, it's an easy merge for interested parties to switch over. It also makes it easy for experienced instructors to grab some new testing stuff that they like, while keeping their personal shell lesson which they adore.

Thoughts?

[wking]

Example instructor notes:

• https://github.com/wking/swc-boot-camps/blob/master/instructor.md
• https://github.com/wking/swc-boot-camps/blob/version-control/version-control/instructor.md
• https://github.com/wking/swc-boot-camps/blob/version-control-git/version-control/git/instructor.md

[ahmadia]

I think it's a good idea to encourage experienced developers to maintain their own SWC feature branches that can be merged into SWC as a more advanced workflow.

I also think it's important to have a central list of "blessed" content that coexists in one repository, similar to the Python standard library and the wide range of packages that augment it. I understand there are weaknesses to this approach, but I think they are outweighed by the advantages.

I'm happy to work with you (and others) on this as a Skunk Works project, possibly in another properly rooted repository. My primary concerns with adopting those over our current workflow are that our instructors are not experienced enough with Git to perform these sort of maneuvers. I have a couple of years of experience with Git and merging in wildly different branches is still a bit terrifying to me sometimes :)

[rgaiacs]

About the central list of "blessed" content we can use git submodule for this. Any reason, except more advanced git knowledge, for not using it?

[gvwilson]

On 2013-10-23 9:19 AM, r-gaia-cs wrote:

About the central list of "blessed" content we can use git submodule
for this. Any reason, except more advanced git knowledge, for not
using it?

Experience shows that's a very big "except" :-)

[ahmadia]

@r-gaia-cs - Do you trust me when I say that git submodule would cause many more problems than it would solve in this scenario? It confuses even advanced users when developing.

I'm speaking from experience on two software projects I manage with professional scientists.

[ethanwhite]

One more -1 on git submodules. Very tricky to use for most folks (we use them in my lab it causes lots of confusion).

[wking]

On Wed, Oct 23, 2013 at 05:39:07AM -0700, Aron Ahmadia wrote:

I also think it's important to have a central list of "blessed"
content that coexists in one repository, similar to the Python
standard library and the wide range of packages that augment it. I
understand there are weaknesses to this approach, but I think they
are outweighed by the advantages.

There's no reason you can't have a blessed collection of feature
branches, all merged together in a pre-assembled distribution branch
ready to clone.

I'm happy to work with you (and others) on this as a Skunk Works
project, possibly in another properly rooted repository.

Sounds good, since this is currently a fair distance from useful ;).
While falling asleep last night, I decided to just go all out with
submodules, since this is basically what they're for. I've setup
git://tremily.us/swc-boot-camp.git with per-subject submodules, and
each subject (currently just version control) has per-tool submodules.
Enable what you want:

$ git clone git://tremily.us/swc-boot-camp.git
$ cd swc-boot-camp/
$ git submodule update --init version-control
$ cd version-control
$ git submodule update --init git
$ cd ..
$ git submodule status --recursive
afae66408a7e27889ee502113b9faee17259ecab version-control (heads/master)
03ceaf942632835aeb84f7525f178bd9cc002b07 version-control/git (heads/master)
-f8eecd41e0546d578c54f274373609795ebd5b05 version-control/svn

Alternatively, you can just enable everything:

$ git clone git://tremily.us/swc-boot-camp.git
$ cd swc-boot-camp/
$ git submodule update --init --recursive

The submodule repositories are culled from the old boot-camps and
guide stuff, keeping only what I needed, so they're only a few dozen
KB a piece at the moment.

My primary concerns with adopting those over our current workflow
are that our instructors are not experienced enough with Git to
perform these sort of maneuvers. I have a couple of years of
experience with Git and merging in wildly different branches is
still a bit terrifying to me sometimes :)

Heh. A few thoughts:

• See my earlier comment about providing pre-assembled branches for
  Git-averse instructors. The workflow should be designed around
  making life easy for the maintainers; distributable packages (in
  this case, pre-assembled branches) that are optimized for downstream
  consumption are built from the easy-to-maintain source, and we can
  add build tooling to bridge any gap that exists there.

• Git's submodule support has been improving recently (e.g. 1.8.3
  added submodule deinit), and:

  $ git submodule update --remote --recursive

  beats searching for updates across a range of per-subject/tool
  branches.

• Implicitly with my earlier directory structure, and now explicitly
  with submodules, there is no actual conflict resolution required.
  We're just collecting suitably namespaced pieces.

• It's really hard to make irrecoverable mistakes in Git. The reflog
  and reset --hard … are your friends ;).
  https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#reflogs

  So long as you commit frequently, any havoc you wreack on your
  working directory or branch reference is easy to undo.

Incidentally, this approach makes "where do I store compiled
Markdown/HTML/PNGs?" (#92, #98) really easy. Just drop them in a new
branch/repository (as Git does with git-htmldocs 1), and adjust the
submodule to point to the pre-compiled stuff. No compiled files for
folks using the source branch, and no need to compile for folks using
the compiled branch.

[wking]

On Wed, Oct 23, 2013 at 06:40:39AM -0700, Ethan White wrote:

One more -1 on git submodules. Very tricky to use for most folks (we
use them in my lab it causes lots of confusion).

An option for the submodule averse would be:

$ git clone --branch namespaced git://tremily.us/swc-boot-camp.git
$ cd swc-boot-camp
$ git pull git://tremily.us/swc-version-control.git namespaced
…

And the maintainer of each submodule could periodically run:

$ git checkout namespaced
$ git merge master
$ git push namespaced

to keep the namespaced branch up to date with file edits. They'd have
to adjust the merge to remove submodule additions, but I don't see that
happening all that often.

One benefit of this decoupled namespacing is that I can use the same
lessons as version-control/git that bc-folks are using for
lessons/thw-git/. If we need multiple namespaced branches with
different namespacing, that would work too. Personally, I think
submodules are easier ;).

[ahmadia]

I agree that keeping multiple repositories to help deal with repository bloat/optional content is one path forward. What are your thoughts on a binary hash-tracker such as the git annex/fat?

[wking]

On Wed, Oct 23, 2013 at 07:39:20AM -0700, Aron Ahmadia wrote:

I agree that keeping multiple repositories to help deal with
repository bloat/optional content is one path forward. What are
your thoughts on a binary hash-tracker such as the git annex/fat?

I think binary data isn't source ;). Those tools are useful for
versioning experimental datasets, etc., but I don't think we need any
of that in the SWC repositories. If you do want to version an
instructive graphic, you should keep the source for that graphic in
one branch, and periodically release compiled versions. There's no
need to keep a historical record of the compiled versions, but if you
want to use a branch or tag to mark particular compiled output, I have
no problem with that. Submodules don't require that the updated SHA
be a descendant of the previous SHA, they can still check out your
reference into a subdirectory of your assembled branch.

If your source is binary (e.g. a GIMP .xcf), then you can manage
that however you like in your source repository. I stick with
text-based source formats, so I don't have to deal with that issue,
but I'd be happy to add submodules/namespaced references for folks who
do use binary source formats.

[rgaiacs]

@ahmadia Yes, git submodules can cause many problems when learning it but is the safest way to go with isolate per-subject rules.

Using branches can cause lots of troubles (conflicts when merging) and be time consuming for new instructor when setup a bootcamp.

[wking]

On Wed, Oct 23, 2013 at 07:28:05AM -0700, W. Trevor King wrote:

On Wed, Oct 23, 2013 at 06:40:39AM -0700, Ethan White wrote:

One more -1 on git submodules. Very tricky to use for most folks (we
use them in my lab it causes lots of confusion).

An option for the submodule averse would be:

$ git clone --branch namespaced git://tremily.us/swc-boot-camp.git
$ cd swc-boot-camp
$ git pull git://tremily.us/swc-version-control.git namespaced
…

Talk is cheap, so I've stubbed that out in the following branch:

git://tremily.us/swc-boot-camp.git assembled

With the submodule-based analog in:

git://tremily.us/swc-boot-camp.git master

I'd recommend the latter, because:

• You can easily update with:

  $ git submodule update --remote --recursive

• You can easily drop into a submodule, make a fix, and push the fix
  upstream.

However, the submodule-averse are welcome to use an assembly of
namespaced branches. It just means it will take cherry-picks to get
their changes upstream, and cross-module commits will have to be
decoupled before being applied to the upstream branches. From an
upstream maintainer's point of view, keeping the 'namespaced' branch
up to date is trivial.

[ahmadia]

@wking - This is going to take more time than I normally have during the week. I'm going to play with this over the weekend and report back.

[wking]

On Wed, Oct 23, 2013 at 07:03:14AM -0700, W. Trevor King wrote:

$ git submodule status --recursive
afae66408a7e27889ee502113b9faee17259ecab version-control (heads/master)
03ceaf942632835aeb84f7525f178bd9cc002b07 version-control/git (heads/master)
-f8eecd41e0546d578c54f274373609795ebd5b05 version-control/svn

Today I finished the last of my restructured-modular-shell branch 1.

$ git submodule status --recursive
 9ff2e80e4df2586aec94461115764da7d37c3967 modular (heads/master)
 0280d05f8b0b7d67cf07f7946d89e93e66e4b50a modular/shell (heads/master)
 d8c9a25a5c3f1ba2d7a202a938a1482c72d6ed64 modular/shell/exercises/dictionary (heads/master)
 4f63575228e8c46a7774969462edf0a7e0180995 modular/shell/exercises/genotype (heads/master)
 d620754f577d700ef81cdb16e3c3885f79e629f7 modular/shell/exercises/hearing (heads/master)
 437a542e163774d0dbeeec4884a44f436a36d3d4 modular/shell/exercises/hello (heads/master)
 99591c7fa6f4b466c2175ec0dcf46d9b2ef78a20 setup (heads/master)
 949f2a8cc33af82e28f01111e13aea442b11a75b setup/get-my-ip (heads/master)
 e064ce8bfb25163eb60eed762d492d5f7eb7ac93 setup/installation-test (heads/master)
 946680ff7d97e09ad54abbc9191e0701ca6dd20c setup/windows-installer (heads/master)
 afae66408a7e27889ee502113b9faee17259ecab version-control (heads/master)
 03ceaf942632835aeb84f7525f178bd9cc002b07 version-control/git (heads/master)
 f8eecd41e0546d578c54f274373609795ebd5b05 version-control/svn (heads/master)

including some of Orion Buske's genotype history pulled from the jaws
of the old Subversion repository. Still to go from my restructured
series is the restructured-testing-nose 2. The submodule-less
'assembled' branch is also up to date.

[ahmadia]

@wking - Thanks, I took a look at it.

mkdir wking
cd wking
git clone git://tremily.us/swc-boot-camp.git  
# ack!  This thing is huge! Abort! Abort!

# Now how the heck do I just grab a single commit out?
git clone --help
rm -rf swc-boot-camp

# --depth=1 (just grab the objects for the last commit)
# -b master (hopefully this one is obvious)
# --single-branch (turns out this is redundant with --depth specified)
git clone --depth 1 -b master --single-branch git://tremily.us/swc-boot-camp.git
cd swc-boot-camp
# load those submodules up baby!
git submodule init
git submodule update
# okay, instructor instructions are instructable
cat instructor.md
ls
# and the directories are populated
ls modular
ls setup
ls version-control

My reaction is positive so far. This isn't that complicated of a setup, and I think it's a good way for instructors to maintain and pull in material from each other.

I can't believe we're still having this discussion, but I don't think we've agreed on a standard for presenting materials yet. I think it's time to open that meta-issue and keep trying to hash that out here.

[wking]

On Wed, Oct 30, 2013 at 05:42:51AM -0700, Aron Ahmadia wrote:

@wking - Thanks, I took a look at it.

Thanks for the feedback :).

mkdir wking
cd wking
git clone git://tremily.us/swc-boot-camp.git

ack! This thing is huge! Abort! Abort!

Really?

$ git clone git://tremily.us/swc-boot-camp.git
Cloning into 'swc-boot-camp'...
remote: Counting objects: 1358, done.
remote: Compressing objects: 100% (829/829), done.
remote: Total 1358 (delta 339), reused 1291 (delta 319)
Receiving objects: 100% (1358/1358), 1.32 MiB | 707.00 KiB/s, done.
Resolving deltas: 100% (339/339), done.
Checking connectivity... done

1.32 MiB is not that huge… Most of the weight is in the 'assembled'
branch though, because the master branch offloads a bunch of history
to the submodules.

git clone --depth 1 -b master --single-branch git://tremily.us/swc-boot-camp.git
cd swc-boot-camp

load those submodules up baby!

git submodule init
git submodule update

You can also:

$ git clone --recursive git://tremily.us/swc-boot-camp.git

I can't believe we're still having this discussion, but I don't
think we've agreed on a standard for presenting materials yet. I
think it's time to open that meta-issue and keep trying to hash that
out here.

The reason we're still having the "presentation format" discussion is
because there's no one-size-fits all format. The core SWC
repositories have over the years tried to push people towards HTML,
YouTube videos, PDF, ReST, Markdown, IPython, …, but none of them has
stuck. However, most of these formats still have proponents who use
them to teach new boot camps. Meanwhile, central lesson material rots
in a range of abandoned states ;). I think it's better to suggest
something simple (e.g. Markdown), but let individual lesson-level
maintainers choose whatever they like (in the hopes of attracting
dedicated maintainers). The more we tighten the feedback loop between
folks working on the central repositories and folks teaching actual
boot camps, the more vibrant and targeted the central repositories
will be.

[ahmadia]

@wking - my connection hiccuped, and I gave up early :) Glad it's only 1.32 MiB. I don't suppose you know of a way to query that without actually doing the fetch, do you?

[wking]

On Wed, Oct 30, 2013 at 10:06:36AM -0700, Aron Ahmadia wrote:

@wking - my connection hiccuped, and I gave up early :) Glad it's
only 1.32 MiB. I don't suppose you know of a way to query that
without actually doing the fetch, do you?

Apparently you can with GitHub's API 1, but not with the standard
Git or smart-HTTP protocols 2. Personally I use Jefromi's approach
during a clone/fetch 2:

It doesn't actually show the total size, but you can certainly watch
it for a second, and if you see "1% ... 23.75 GiB" you know you're
in trouble, and you can cancel it.

:p

[ethanwhite]

I can't believe we're still having this discussion, but I don't think
we've agreed on a standard for presenting materials yet. I think
it's time to open that meta-issue and keep trying to hash that out
here.

My impression of things is that they are a bit less up in the air than
this issue implies. I thought that the gits group settled on the
workflow that is codified in the bc README and that we have settled
on IPython notebooks for Python material and Markdown for everything
else. I think it would be good to get @gvwilson's perspective on this
before going too much further. Once we have some clarity from Greg
it would be good to have the current state of things codified in the
README.

[ahmadia]

@ethanwhite - Agreed.

At first we were trying IPython Notebooks for everything, although I agree we've back off from that. I'm referring a bit more to the structure of the lessons themselves. @wking had an excellent earlier point where he summarized the various layouts we were considering (longform web notes, short instructor notes, short form learner's notes, exercises, etc...) You can see examples of all of them across the SWC and THW materials.

The request for an issue doesn't mean I want to discuss this more, it just means I (and others) looking for clarity. I'd love to see this added to the docs so we have something to refer to when considering pull requests and reorganizing material.

[wking]

On Wed, Oct 30, 2013 at 11:58:32AM -0700, Ethan White wrote:

I can't believe we're still having this discussion, but I don't think
we've agreed on a standard for presenting materials yet. I think
it's time to open that meta-issue and keep trying to hash that out
here.

My impression of things is that they are a bit less up in the air than
this issue implies.

There's just been a PR with RMarkdown source (#91, #92), and another
PR dropping in a completely stand-alone R-only bootcamp (#112). We
also have three separate tracks (swc-, thw-, and misc-) for current
lessons content already in bc/gh-pages. I get the impression that
we're moving away from consolidation, and the submodule approach here
handles that cleanly without creating a kitchen-sink branch. If I'm
wrong, and bc is headed towards polished simplicity, then this PR is
probably not worth its moderate Git gymnastics. Feedback from
instructors in the field would be useful…

I thought that the gits group settled on the workflow that is
codified in the bc README and that we have settled on IPython
notebooks for Python material and Markdown for everything else. I
think it would be good to get @gvwilson's perspective on this before
going too much further. Once we have some clarity from Greg it
would be good to have the current state of things codified in the
README.

Hmm, the README has some typos in it (e.g. git remote add <url>
missing a <name>, likely swcarpentry). I confess that I'm not
sold on the new bc/Jekyll framework. Even if it is the best we can do
now, I doubt it will be what we use in five years. Separating the
content in it's own branches allows us to adapt to new rendering
frameworks as the mood strikes, without losing history during the
transitions or cluttering history with the bones of the earlier
frameworks.

[rgaiacs]

And RMarkdown (issue #92)? Can you got a resolution for it before close this issue? (@wking was faster than I.)

I'm +1 on IPython notebooks for Python material (beside it need some improvements), RMarkdown for R and Markdown for everything else (just to remember the issue #93 where we have a IPython Notebook for Software Carpentry's shell lesson).

[ethanwhite]

On Wed, Oct 30, 2013 at 3:24 PM, W. Trevor King notifications@github.com wrote:
There's just been a PR with RMarkdown source (#91, #92), and another
PR dropping in a completely stand-alone R-only bootcamp (#112). We
also have three separate tracks (swc-, thw-, and misc-) for current
lessons content already in bc/gh-pages. I get the impression that
we're moving away from consolidation, and the submodule approach hear
handles that cleanly without creating a kitchen-sink branch. If I'm
wrong, and bc is headed towards polished simplicity, then this PR is
probably not worth its moderate Git gymnastics. Feedback from
instructors in the field would be useful…

My impression is that the goal is to move towards a single set of
relatively polished core material. This is absolutely a difficult thing
for the reasons you've mentioned above, and there are important
conversations to be had about how to provide domain specific
context (#111), but I think it's worth trying so that we can really
leverage the kinds of awesome collaboration we've been seeing in
the repo recently. Greg asked me to help explore some of this
and I'll be opening a meta issue as soon as I've had time to finish
studying the full state of things and have some meaningful
suggestions as a starting point for discussion.

Hmm, the README has some typos in it (e.g. git remote add <url>
missing a <name>, likely swcarpentry). I confess that I'm not
sold on the new bc/Jekyll framework. Even if it is the best we can do
now, I doubt it will be what we use in five years. Separating the
content in it's own branches allows us to adapt to new rendering
frameworks as the mood strikes, without losing history during the
transitions or cluttering history with the bones of the earlier
frameworks.

I completely agree that this is a difficult problem and that the current
solution is not perfect. In fact after all of the discussion over the
past year and a half I suspect there isn't a perfect solution. That said,
my understanding is that the git subgroup proposed this as a
functional compromise and Greg announced that this is what we were
going with, so my perspective is that we should use the consensus
approach for a while and focus on improving the material before
reconsidering the process. Hopefully we'll learn what works and what
doesn't and can then reconsider details of the process in the future.

[ethanwhite]

And RMarkdown (issue #92)? Can you got a resolution for it before
close this issue? (@wking was faster than I.)

I totally agree that we need a serious conversation about what to do with
R material. Apologies for not being clear about that earlier. I think that's
best handled in it's own issue.

[wking]

On Wed, Oct 30, 2013 at 01:59:09PM -0700, Ethan White wrote:

My impression is that the goal is to move towards a single set of
relatively polished core material.

Hooray :). And good luck ;).

so my perspective is that we should use the consensus approach for a
while and focus on improving the material before reconsidering the
process.

Sounds good. I'll reiterate that the submodule-based approach to
lesson content is orthogonal to a particular single-branch aggregation
or subsequent workflow, so I'll continue with it from a
history-restoration perspective (#79, #89) for the content whose
history I care about.

[gvwilson]

Apologies for being absent from the discussion - travel :-( We're not going to adopt per-subject/per-tool branches, but I agree that we need to figure out what to do about managing media (IPython Notebooks, R Markdown files, etc.) and more generally where Software Carpentry ends and other things begin. I have a long-ish message about this in my drafts folder, and I'll try to get it out by noon tomorrow.
As a meta-point, I'm finding the use of reply-to's on issues a helpful way to manage discussion without flooding the 'discuss' list, but most of the people on that list aren't (yet) aware that this discussion is going on. I propose posting three or four lines to 'discuss' with pointers to issues here for specific topics, so that everyone wants to join can, but the 'discuss' list won't go bonkers. If you think this is a bad idea, please let me know.

[ethanwhite]

On Wed, Oct 30, 2013 at 6:00 PM, Greg Wilson notifications@github.com wrote:
As a meta-point, I'm finding the use of reply-to's on issues a helpful way
to manage discussion without flooding the 'discuss' list, but most of the
people on that list aren't (yet) aware that this discussion is going on. I
propose posting three or four lines to 'discuss' with pointers to issues
here for specific topics, so that everyone wants to join can, but the
'discuss' list won't go bonkers. If you think this is a bad idea, please let
me know.

I like it this way too. Maybe part of @ahmadia's awesome weekly update
email to provide links to any more significant issues/discussions for
folks who aren't watching the repo closely. (Apologies for volunteering you
Aron, but thanks for making it a lot easier to keep up)

[ahmadia]

@ethanwhite @gvwilson - As I mentioned earlier in the thread, I think it's time to start a new issue about this :) @gvwilson - you seem to have the best sense for the temperament of the discuss mailing list, so perhaps it's best if you start the new issue and advertise it there.

[ethanwhite]

+1.

If I'm reading everything correctly we're all on board with closing this
and continuing side discussions that have started in separate issues,
but I'll let @wking or @ahmadia push the button in case I'm misreading
things.

[wking]

On Wed, Oct 30, 2013 at 03:00:16PM -0700, Greg Wilson wrote:

We're not going to adopt per-subject/per-tool branches, …

That's pretty concise ;). If we end up nominating per-subject/tool
maintainers, I think that they may want to adopt this workflow for
their own sanity. In the unlikely event that I'm elected global bc
aggregator, I'll resurect this. Until then, the acting bc
aggregator(s) can maintain bc with whatever workflow makes sense to
them ;).

[wking]

On Wed, Oct 30, 2013 at 04:27:44PM -0700, W. Trevor King wrote:

Until then, the acting bc aggregator(s) can maintain bc with
whatever workflow makes sense to them ;).

I think I should point out that there's no reason to require a
consensus here. For example, I'm using the separate-branch method to
maintain setup/, with separate branches (and repositories) behind the
installation test script
(git://tremily.us/swc-setup-installation-test.git) and the Window's
installer (swc-setup-windows-installer.git). As long as I can catch
incoming patches before they land in bc, I can apply them to my
repository (upstream) and then merge them into bc (or other places).
This is what happened for Neal's recent PATH-quoting patch. The
initial submission against master was #268:

• f55d31f (bc/pr/268) Quote $PATH export to account for spaces.
• 0d8f4dd (bc/master) Merge pull request Discuss shebang #! in novice Bash lesson? #255 from wking/no-shebangs
  …

But I submitted an alternate #269 that got the content through my
swc-setup-windows-installer repository:

• 4ed6167 (bc/pr/269) Merge branch 'bc-namespaced-python' of git://tremily.us/swc-setup-windows-installer into windows-installer-quote-path
  |\
  | * abfecf6 (windows-installer/bc-namespaced-python) Merge branch 'python' into bc-namespaced-python
  | |\
  | | * ed160e5 (windows-installer/python) swc-windows-installer.py: Quote $PATH export to account for spaces.
• | | (bc/master) 0d8f4dd Merge pull request Discuss shebang #! in novice Bash lesson? #255 from wking/no-shebangs
  | | * 70c97fc swc-windows-installer.py: Use regular expressions to POSIX-ify paths
  … … …

Anyone else interested in the installer script (but not the rest of
bc) can pull from windows-installer/python (or the shell version in
windows-installer/master, which is currently queued for bc in #228).

So folks who think “bc is too heavy, I want a lighter weight version”
(#285) don't need to convince all of the bc developers. They only
need to convince the folks who are maintaining the pieces they want in
their lightweight repository. Similarly, folks who prefer submodules
to subtree merges can easily use this approach as well, they just need
to convince their upstream maintainers to maintain a non-namespaced
version of the content (e.g. windows-installer/python, which has
swc-windows-installer.py in the root directory).

[gvwilson]

My number one priority is to make it easy for newcomers to contribute.
My second priority is to avoid fragmentation in our community. I'm
against multiple workflows (particularly ones requiring sophisticated
Gitology) for both reasons.

[wking]

On Tue, Feb 04, 2014 at 05:22:23PM -0800, Greg Wilson wrote:

My number one priority is to make it easy for newcomers to contribute.

They can still submit PRs against bc.

My second priority is to avoid fragmentation in our community.

I'm still in favor of assembling a canonical collection in
swcarpentry/bc (or /workshop #240). I think “it's technically
difficult to fragment; don't leave” is less compelling than “our core
material is awesome and easy to reuse; join in”. If folks can grab
$LESSON and riff on it, I think they'll be more likely to do that (and
contribute back) than if it had a whole bunch of other baggage
associated with it. Maybe non-SWC users of SWC lessons are too small
a slice to matter, but I can definitely see folks wanting to grab the
Git intro for the opening lecture of their numerical methods class.

I'm against multiple workflows (particularly ones requiring
sophisticated Gitology) for both reasons.

I agree with both of your priorities, but not your conclusion ;). I
think #269 required neither a difficult submission (#267 was
sufficient), nor much gymnastics on my part:

windows-installer$ git fetch bc
windows-installer$ git cherry-pick f55d31f
windows-installer$ git checkout bc-namespaced
windows-installer$ git merge --log master
windows-installer$ git push origin master bc-namespaced

bc$ git checkout windows-installer
bc$ git pull --log windows-installer bc-namespaced
bc$ git push wking windows-installer
(make swcarpentry/bc pull request)

There's nothing (except a single cherry-pick) that we don't teach
newbies in the first two hours. I don't think that's too high a bar
to set for bc maintainers.

[wking]

On Tue, Feb 04, 2014 at 06:02:27PM -0800, W. Trevor King wrote:

On Tue, Feb 04, 2014 at 05:22:23PM -0800, Greg Wilson wrote:

I'm against multiple workflows (particularly ones requiring
sophisticated Gitology) for both reasons.

… I don't think that's too high a bar to set for bc maintainers.

Particularly for maintainers who opt-in to this approach ;). Anyone
who feels it is not appropriate can certainly carry on developing
directly in bc, rather than developing outside and then pulling into
bc.

[wking]

In the lab meeting today, @gvwilson mentioned mixing lessons using
package-managers (e.g. PyLadies 1). Personally, I'd rather mix and
match with Git branches, because that gives me full control to tweak
packages I consume without pushing a my-PyLadies package to PyPI. Git
is also more language-agnostic than a language-specific packaging
framework, although the same namespace/ownership issues would apply to
a language-agnostic package manager.

[wking]

On Thu, May 22, 2014 at 04:35:40PM -0700, W. Trevor King wrote:

In the lab meeting today, @gvwilson mentioned mixing lessons using
package-managers (e.g. PyLadies 1).

In the July sprint, @twitwi, @r-gaia-cs, and I stubbed out a procedure
for using Bower instead of pip to manage lessons 1. This is more
language-agnostic (e.g. you don't need Pythonic packaging), but
otherwise similar. My personal preference for assembly is still for
submodules, followed by ‘git pull’, followed by a package manager, but
I'll happily support anything that gets folks developing lessons in
independent branches ;). Aggregating separate branches/packages is a
lot easier than splitting the fraction you need out of a central,
catch-all repository.