search

swcarpentry / DEPRECATED-bc

DEPRECATED: This repository is now frozen - please see individual lesson repositories.
Other
299 stars 381 forks source link

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

Closed wking closed 11 years ago

wking commented 11 years ago

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 commented 11 years ago

Example instructor notes:

ahmadia commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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:

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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:

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

On Wed, Oct 30, 2013 at 3:09 PM, Aron Ahmadia notifications@github.com wrote: 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.

I agree that there's useful stuff to discuss here and would be happy to chat about it in another issue. I think we should actively request @gvwilson's take early in the process. My impression from the overall state of things, the work that Greg had done, and various discussions over the last year was that we were primarily thinking about longform web notes.

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.

Totally agree. Hopefully the email Greg just mentioned (while I was typing this) will help start moving us in the direction and we can start getting things discussed and documented.

ethanwhite commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

+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 commented 11 years ago

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 commented 10 years ago

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:

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

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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.