Establish proper development environment and workflow

I really don't know much about the platform, but Pantheon (https://getpantheon.com/) might also be great option? Especially as this is what Farsheed is already using http://test.pushtape.gotpantheon.com/

What problem are we trying to solve? Development environments seem to be pretty unique to developers - some people like to work locally, others on a shared dev site, etc...might be hard to come to a consensus.

Or is this more about how to create new instances of Pushtape on the fly? Since it aims to be a Feature/install profile, possibly a drush make style packaging script is the answer.

Assuming this is going to be something where multiple people are contributing code, there needs to be a system to facilitate that...right? Version control of some sort?

I know I'm getting really technical...haha.

Going to use drupal.org infrastructure for now.

Something like:

• project/pushtape_theme
• project/pushtape_features (Feature modules, the heart of it all)
• project/pushtape (drupal-org.make file, distribution packaging script)

If we're divvying up some of the coding/theming tasks, it would help if we had access to the current development environment. Is there a way to set up Banghouse, myself, and others who are contributing on Pantheon?

First off, I know I've been AWOL: I've been recovering from a nasty bug, traveling a bit, and trying to catch up with some lingering work.

As discussed before I'm not sure how helpful shared access to the Pantheon dev environment is at this stage. The site up on Pantheon is just a demo site to test out workflow for album/track creation. Developers/contributors will most likely have unique preferences and environments for development and contributions will come in the form of patches, modules, themes, or features.

The crucial next step I see to open up this process is for me to publish what I have to drupal.org. The factors that have prevented me from doing it thus far: 1) outside work/time commitments, 2) media module updates/dependencies, and 3) grokking the best way to use drupal.org infrastructure to host and manage all the code.

Thanks for the support/patience as we figure this out together.

Closing this as we have code in drupal git repository under /pushtape and /pushtape_features.

I think we should leave this open until we have a bit more clarity on the process. This discussion in #drupal-apps (IRC), might help provide some insight.

We already have a drupal makefile called drupal-org.make that I am using to automatically package together the Features, Themes, etc. automatically on drupal.org. This is what makes Pushtape a downloadable product. If you are curious what it looks like:

; drupal-org.make file
; This is a comment. Anything starting with a semicolon is a comment
; and will be ignored by the parser. Blanks lines are also ignored.
;
; The file uses standard info file format:
; attribute = value

; REQUIRED ATTRIBUTES

; The version of Drupal the profile is built for. You must include both a
; major and a minor release - just specifying 6.x won't work
core = 7.10
api = 2

; OPTIONAL ATTRIBUTES

; Here you see the format of an array in a .make file. Text enclosed
; in brackets are array keys, and each set to the right of the last is
; a layer deeper in the array. Note that the root array element is
; not enclosed in brackets:
; root_element[first_key][next_key] = value

; The projects attribute is where you define the modules/themes that
; are to be packaged with the profile. The first key is the short name
; of the project (as seen in the drupal.org/project/{projectshortname}
; URI). Note that you *must* specify an exact version of a module or
; theme (one that points to an 'official' release node) -- you cannot
; use development releases!

; These projects are defined using the short form definition. You can
; use this form if you only want to declare the version of the project.
; The version is the value to the right of the core Drupal version in a full
; version string. For example, if you wanted to specify Views 6.x-2.7,
; you would use:

projects[features] = 1.0-beta4
projects[pathauto] = 1.0
projects[references] = 2.0-beta3
projects[ctools] = 1.0-rc1
projects[token] = 1.0-beta7
projects[views] = 3.0-rc3
projects[media] = 1.0-rc2
projects[pushtape_features] = 1.2

; For pre-releases, like Image 6.x-1.0-beta3, use this format:
;projects[image] = 1.0-beta3

; projects[pathauto] = 1.2
; projects[token] = 1.12
; projects[logintoboggan] = 1.6

; To define more attributes for a specific project than just the version,
; create another layer of array keys. In the example below, both the
; projects will be placed in a subdirectory of the modules folder.
; Note that if the long form is used, the version key must be defined
; for the project!
; projects[cck][version] = 2.6
; projects[cck][subdir] = cck_related_modules
; projects[filefield][version] = 3.2
; projects[filefield][subdir] = cck_related_modules

; Defining a theme is no different.
;projects[spreadfirefox] = 1.0

Since we are using d.o. infrastructure, people can download the package from Drupal.org or build the distribution using Drush. I don't see a realistic way to support any other type of workflow than people just manually installing the distribution and trying to build sites with it.

Ways people can contribute to the project:

• Download and test the code! Try building an actual site or demo site. Although not technically challenging, it is incredibly helpful.
• Submit a configuration recipe for extending the base install
• Create a new Feature module based on a configuration recipe.
• Create or design a new theme
• Submit a bug report via the Drupal.org issue queue.
• Submit a patch for a bug via the Drupal.org issue queue.
• Help write documentation