GNU MediaGoblin Wiki - User contributions [en]

Campaign Sightings/2012

2012-10-17T14:09:19Z

Willkg: Created page with "This page lists sightings of things that link to the campaign page at http://mediagoblin.org/pages/campaign.html . If you dented, tweeted, blogged about, or otherwise got a l..."

This page lists sightings of things that link to the campaign page at http://mediagoblin.org/pages/campaign.html .

If you dented, tweeted, blogged about, or otherwise got a link to the campaign page, add a link to it on this page!

If you see something that's not listed on this page, add a link to it on this page!

* "On the MediaGoblin fundraising campaign part 1: FSF vs Kickstarter" http://dustycloud.org/blog/mediagoblin-campaign (Chris Webber blog)
* "Donate to GNU MediaGoblin! Help us cross the chasm!" http://bluesock.org/~willg/blog/gmg/fundraising_2012.html (Will Kahn-Greene blog)

Meeting

2012-09-10T19:53:56Z

Willkg: /* Past Meetings */

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

''Nothing here yet''

== Past Meetings ==

=== September 1st, 2012, 9:00 am Pacific Time (2012-09-01 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-09-01.txt IRC log]

* FIXME - can someone type in summary here?

=== August 4th, 2012, 9:00 am Pacific Time (2012-08-04 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-08-04.txt IRC log]

* Release schedule
* Plugins and themes! Who's working on one? What problems are you having? -- Please write up issues for problems so they can get fixed!
* Should we namespace plugins? If so, how should we namespace plugins?
** Python 3.3 will have support for namespace plugins. [http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** In Python >=2.3, <3.3 it's a hack [http://www.python.org/dev/peps/pep-0402/#the-problem][http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** Flask has a workaround[https://github.com/mitsuhiko/flask/blob/master/flask/ext/__init__.py]

=== July 7th, 2012, 9:00 am Pacific Time (2012-07-07 16:00 UTC) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-07-07.txt IRC log]

Announcements:

* Anyone who wants to edit the wiki needs to be in the goblin army group. Ask Will or Chris to get added.
* Plugin infrastructure landed. If you're interested in writing plugins, talk to Will. Some documentation at http://docs.mediagoblin.org/#part-2-plugin-writer-s-guide

Agenda:

* Keyboard shortcuts ([http://issues.mediagoblin.org/ticket/346 #346])
* Ticket triaging?
* Base plugin stuff!
* Theming
* Conference: OSCON
* Chris Webber's new "office hours"

=== June 2nd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-06-02.txt IRC log]

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git and tickets
* Plugins
** What's the state of things?
** Documentation
** What plugins might we want to build for this upcoming release?
** What things do we currently have that we might want to pluginify?
* State of kuneco/federation mini-update (Chris)

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 pm UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Main Page

2012-08-27T14:30:16Z

Willkg:

= Want to Join the MediaGoblin Community? =

We’re really glad that you want to join the MediaGoblin community!

There are a variety of ways to help and support MediaGoblin and to join the team. If you want to code, great, if not, even better! MediaGoblin interested contributors in many different roles: users, system administrators, technical writers, testers, evangelists, UI/UX and graphics designers, cheerleaders, and dreamers.

This wiki covers a variety of ways that you can get involved with MediaGoblin as well as instructions on how to get started.

== Hang out with the MediaGoblin folk ==

MediaGoblin has a mailing list and an IRC channel where we hang out. See [http://mediagoblin.org/pages/join.html our join page] for links.

Please drop by and say “Hi!” And, if you’re looking for something to do, just ask---there’s always work to be done.

== Take Part in the Monthly Meetings ==

Each month is a [[Meeting]]. You can take part and help decide on the future of MediaGoblin. Or just be around and see what's happening live!

== File Bugs / Triage Bugs ==

Issue reports are critical for all projects. Identified bugs give developers a basis for beginning work, and providing an idea of what features and issues are most important to users and the overall usability of the software. If you identify errors, flaws, unexpected behaviors, or deficits that impede use, file a bug.

* [[File Bugs]] -- notes on filing new bugs/issues/feature requests
* [[Feature Ideas]] -- notes on possible features
* [[Triage Bugs]] -- notes on triaging
* [[BugTriageDay]] -- every other Thursday is bug triage day where anyone can help out triaging bugs

== Write Code / Fix Code ==

If you are a coder and you would like to write code, the repository is hosted on gitorious. Clone or fork the repository and start poking around. Become familiar with this manual for an overview of how the software works and is used. Consider the contributor wiki for more information about the project, our preferred methods, and guides for developing MediaGoblin. We even have tips on becoming a coder and we’re willing to help!

* [[HackingHowto|Hacking]] - notes on making and sending in code contributions
** [[BeginnersCorner|Beginner's Corner]] - resources for those who are new to Python or Git.
** ''Started from an older version of the Hacking Howto? We switched from buildout->virtualenv, so look at [[Moving from buildout to virtualenv]] for information on how to move over.''
* [[Git workflow]] - How to go about submitting patches via git.
* [[Templating]] - How our templating structure is set up
* [[Code overview]] - Overview of the structure of the codebase

== Send Encouragement / Spread the Word ==

Sometimes, a nice word, simple encouragement, and interest in the work we’re doing is enough to inspire a tizzy of productive work. Just a bit more interest and encouragement can even make the difference between a complete feature and limited functionality; between a completed milestone and lost momentum.

Similarly, MediaGoblin, and the movement for free network services, is always in need of encouragement. Use free network services, understand the principals behind the movement, be able to articulate the benefits of free network services and the problems with psudo-free applications that don’t respect the users’ freedom.

Write a blog post, post a status update, drop by the listserv or join #mediagoblin on freenode.net and let us know. See [http://mediagoblin.org/join/ our join page] for links.

== Write Documentation / Edit Documentation ==

* [[Documentation quick start]] - How to contribute to the documentation effort.
* [[ManualStandards]] - covers the standards for writing the user manual (forthcoming.)

== Test MediaGoblin ==

Do you have access to the web? Do you like sharing your opinions? If so, we need your help to test MediaGoblin! Testers play around with the current test instance, note what operating system and browser they use (notes on multiple set-ups are also helpful) and take some notes. That's it! It's a very important task that doesn't require any special knowledge and you're done in under an hour. Ready to help?

* [[User Experience]] - user experience testing. Includes link to an instance you can try!
* [[UnitTests|Unit Tests]] - all about the unit tests

== Translate MediaGoblin ==

If you know English and another language and feel comfortable translating elements of the interface or even the documentation, we’d love to have help translating the software and resources.

* [[Translations]] - How to translate stuff or update the translations

== Become a User ==

Coming soon!

We’re building MediaGoblin for us and for you but really you’re one of us and I am you and we are we and MediaGoblin is the walrus.

We're planning to launch our own public instance of MediaGoblin in the near future--probably in the September/October 2011 time frame. When we do, sign up for an account, use the service and relish in the thought that this service comes with a heaping side of Freedom and you can salt and pepper it to your liking.

== Help Others ==

Have you spent time with MediaGoblin? If so, your experience and wisdom are invaluable and you’re the best person we can think of to help other users with their questions.

Hang out on the IRC channel and help answer new peoples' questions. See [http://mediagoblin.org/join/ our join page] for links.

== Run your own MediaGoblin Instance ==

Are there things about our instance you want to change? Are there things about other instances you wish were different? Want to test upcoming changes? Want to create patches to implement things you need? That’s great—you can run your own instance!

* [[Configure_MediaGoblin|Configuration]] - Learn about MediaGoblin configuration files and file options.
* [[Deployment]] - General deployment advice
* [[Scaling Down]] - Minimizing MediaGoblin's resource requirements
* [[Virtual Machine Hosting]] - Deploy your own publicly available MediaGoblin server using [http://aws.amazon.com/free/?utm_source=adwords&utm_medium=cpc&utm_campaign=CPC_Google_AWS_ec2&utm_content=TextV01_PP_V01_EC2&trk=CPC_Google_AWS_ec2 Amazon's free EC2 tier].

== Create a Theme ==

Coming soon!

MedaGoblin development is premised on the idea that the entire interface for the platform be completely theme-able. If you have a design or theming background, consider developing themes for MediaGoblin. New themes help test the theming system, provide attractive and appealing interfaces for prospective users. If you want to start a new theme but don’t know where to start, touch base with the development community on the list or in the IRC channel for more information.

= Technical project documentation =

* [[DesignDecisions]] - covers design decisions (FIXME - this needs to be split up)
* [[Storage]] - How MediaGoblin's internal storage system works.
* [[Processing]] - What happens after you submit your image/video/etc? Processing! More about that.
* [https://gitorious.org/mediagoblin/mediagoblin/blobs/master/extlib/README External Library Policy] - covers use of external libraries
* [[User:Cwebber/braindumps]] - Chris Webber's braindumps (you can help refactoring these into real sections of the site!)
* [[Multiple media support]] - Design plan for multiple media support

= Inner workings of the secret sanctum =

* [[IRCBot]] - covers our irc bot
* [[ReleaseProcess|Release Process]] - covers the release process
* [[Update the website]] - Learn how to update mediagoblin.org!

Main Page

2012-08-27T14:11:29Z

Willkg: /* File Bugs / Triage Bugs */

Main Page

2012-08-27T13:52:29Z

Willkg: /* File Bugs / Triage Bugs */

= Want to Join the MediaGoblin Community? =

We’re really glad that you want to join the MediaGoblin community!

There are a variety of ways to help and support MediaGoblin and to join the team. If you want to code, great, if not, even better! MediaGoblin interested contributors in many different roles: users, system administrators, technical writers, testers, evangelists, UI/UX and graphics designers, cheerleaders, and dreamers.

This wiki covers a variety of ways that you can get involved with MediaGoblin as well as instructions on how to get started.

== Hang out with the MediaGoblin folk ==

MediaGoblin has a mailing list and an IRC channel where we hang out. See [http://mediagoblin.org/pages/join.html our join page] for links.

Please drop by and say “Hi!” And, if you’re looking for something to do, just ask---there’s always work to be done.

== Take Part in the Monthly Meetings ==

Each month is a [[Meeting]]. You can take part and help decide on the future of MediaGoblin. Or just be around and see what's happening live!

== File Bugs / Triage Bugs ==

Issue reports are critical for all projects. Identified bugs give developers a basis for beginning work, and providing an idea of what features and issues are most important to users and the overall usability of the software. If you identify errors, flaws, unexpected behaviors, or deficits that impede use, file a bug.

* [[File Bugs]] -- notes on filing new bugs/issues/feature requests
* [[Feature Ideas]] -- notes on possible features
* [[Triage Bugs]] -- notes on triaging

We triage bugs every other Thursday all day long. Next handful of triage days:

* Thu August 30, 2012
* Thu September 13, 2012
* Thu September 27, 2012
* Thu October 11, 2012
* Thu October 25, 2012
* Thu November 8, 2012

== Write Code / Fix Code ==

If you are a coder and you would like to write code, the repository is hosted on gitorious. Clone or fork the repository and start poking around. Become familiar with this manual for an overview of how the software works and is used. Consider the contributor wiki for more information about the project, our preferred methods, and guides for developing MediaGoblin. We even have tips on becoming a coder and we’re willing to help!

* [[HackingHowto|Hacking]] - notes on making and sending in code contributions
** [[BeginnersCorner|Beginner's Corner]] - resources for those who are new to Python or Git.
** ''Started from an older version of the Hacking Howto? We switched from buildout->virtualenv, so look at [[Moving from buildout to virtualenv]] for information on how to move over.''
* [[Git workflow]] - How to go about submitting patches via git.
* [[Templating]] - How our templating structure is set up
* [[Code overview]] - Overview of the structure of the codebase

== Send Encouragement / Spread the Word ==

Sometimes, a nice word, simple encouragement, and interest in the work we’re doing is enough to inspire a tizzy of productive work. Just a bit more interest and encouragement can even make the difference between a complete feature and limited functionality; between a completed milestone and lost momentum.

Similarly, MediaGoblin, and the movement for free network services, is always in need of encouragement. Use free network services, understand the principals behind the movement, be able to articulate the benefits of free network services and the problems with psudo-free applications that don’t respect the users’ freedom.

Write a blog post, post a status update, drop by the listserv or join #mediagoblin on freenode.net and let us know. See [http://mediagoblin.org/join/ our join page] for links.

== Write Documentation / Edit Documentation ==

* [[Documentation quick start]] - How to contribute to the documentation effort.
* [[ManualStandards]] - covers the standards for writing the user manual (forthcoming.)

== Test MediaGoblin ==

Do you have access to the web? Do you like sharing your opinions? If so, we need your help to test MediaGoblin! Testers play around with the current test instance, note what operating system and browser they use (notes on multiple set-ups are also helpful) and take some notes. That's it! It's a very important task that doesn't require any special knowledge and you're done in under an hour. Ready to help?

* [[User Experience]] - user experience testing. Includes link to an instance you can try!
* [[UnitTests|Unit Tests]] - all about the unit tests

== Translate MediaGoblin ==

If you know English and another language and feel comfortable translating elements of the interface or even the documentation, we’d love to have help translating the software and resources.

* [[Translations]] - How to translate stuff or update the translations

== Become a User ==

Coming soon!

We’re building MediaGoblin for us and for you but really you’re one of us and I am you and we are we and MediaGoblin is the walrus.

We're planning to launch our own public instance of MediaGoblin in the near future--probably in the September/October 2011 time frame. When we do, sign up for an account, use the service and relish in the thought that this service comes with a heaping side of Freedom and you can salt and pepper it to your liking.

== Help Others ==

Have you spent time with MediaGoblin? If so, your experience and wisdom are invaluable and you’re the best person we can think of to help other users with their questions.

Hang out on the IRC channel and help answer new peoples' questions. See [http://mediagoblin.org/join/ our join page] for links.

== Run your own MediaGoblin Instance ==

Are there things about our instance you want to change? Are there things about other instances you wish were different? Want to test upcoming changes? Want to create patches to implement things you need? That’s great—you can run your own instance!

* [[Configure_MediaGoblin|Configuration]] - Learn about MediaGoblin configuration files and file options.
* [[Deployment]] - General deployment advice
* [[Scaling Down]] - Minimizing MediaGoblin's resource requirements
* [[Virtual Machine Hosting]] - Deploy your own publicly available MediaGoblin server using [http://aws.amazon.com/free/?utm_source=adwords&utm_medium=cpc&utm_campaign=CPC_Google_AWS_ec2&utm_content=TextV01_PP_V01_EC2&trk=CPC_Google_AWS_ec2 Amazon's free EC2 tier].

== Create a Theme ==

Coming soon!

MedaGoblin development is premised on the idea that the entire interface for the platform be completely theme-able. If you have a design or theming background, consider developing themes for MediaGoblin. New themes help test the theming system, provide attractive and appealing interfaces for prospective users. If you want to start a new theme but don’t know where to start, touch base with the development community on the list or in the IRC channel for more information.

= Technical project documentation =

* [[DesignDecisions]] - covers design decisions (FIXME - this needs to be split up)
* [[Storage]] - How MediaGoblin's internal storage system works.
* [[Processing]] - What happens after you submit your image/video/etc? Processing! More about that.
* [https://gitorious.org/mediagoblin/mediagoblin/blobs/master/extlib/README External Library Policy] - covers use of external libraries
* [[User:Cwebber/braindumps]] - Chris Webber's braindumps (you can help refactoring these into real sections of the site!)
* [[Multiple media support]] - Design plan for multiple media support

= Inner workings of the secret sanctum =

* [[IRCBot]] - covers our irc bot
* [[ReleaseProcess|Release Process]] - covers the release process
* [[Update the website]] - Learn how to update mediagoblin.org!

BeginnersCorner

2012-08-20T15:17:27Z

Willkg: /* Learning Libraries GNU MediaGoblin uses */ nix pmc references

The MediaGoblin project is welcoming of new contributors, even those who are new to programming. The following resources can help you learn enough to start hacking on MediaGoblin.

== Tips for people new to coding ==

=== Learning Python ===

GNU MediaGoblin is written using a programming language called [http://python.org/ Python].

There are two different incompatible iterations of Python which I'll
refer to as Python 2 and Python 3. GNU MediaGoblin is written in
Python 2 and requires Python 2.6 or 2.7. At some point, we might
switch to Python 3, but that's a future thing.

You can learn how to code in Python 2 from several excellent books
that are freely available on the Internet:

* [http://learnpythonthehardway.org/ Learn Python the Hard Way]
* [http://diveintopython.org/ Dive Into Python]
* [http://www.greenteapress.com/thinkpython/ Python for Software Design]
* [http://www.swaroopch.com/notes/Python A Byte of Python]

These are all excellent texts.

'''You Can Help'''

If you know of other good quality Python tutorials and Python
tutorial videos, let us know!

=== Learning Libraries GNU MediaGoblin uses ===

GNU MediaGoblin uses a variety of libraries in order to do what it
does. These libraries are listed in the :ref:`codebase-chapter`
along with links to the project Web sites and documentation for the
libraries.

There are a variety of Python-related conferences every year that have
sessions covering many aspects of these libraries. You can find them
at [http://pyvideo.org/ pyvideo.org] -- This is a shameless plug; Will Kahn-Greene runs pyvideo.org

If you have questions or need help, [http://mediagoblin.org/join/ let us know]!

=== Learning git ===

git is an interesting and very powerful tool. Like all powerful
tools, it has a learning curve.

If you're new to git, we highly recommend the following resources for
getting the hang of it:

* [http://learn.github.com/p/intro.html Learn Git] --- the GitHub intro to git
* [http://progit.org/book/ Pro Git] --- fantastic book
* [http://gitcasts.com/ Git casts] --- screencast covering git usage
* [http://gitref.org/ Git Reference] --- Git reference that makes it easier to get the hang of git if you're coming from other version control systems

There's also a git mission at [http://openhatch.org/ OpenHatch].

=== Learning other utilities ===

The [http://openhatch.org/ OpenHatch] site has a series of
[http://openhatch.org/missions/ training missions] which are
designed to help you learn how to use these tools.

If you're new to tar, diff, patch and git, we highly recommend you sign
up with OpenHatch and do the missions.

Main Page

2012-08-20T15:16:35Z

Willkg: nix mongodb reference

= Want to Join the MediaGoblin Community? =

We’re really glad that you want to join the MediaGoblin community!

There are a variety of ways to help and support MediaGoblin and to join the team. If you want to code, great, if not, even better! MediaGoblin interested contributors in many different roles: users, system administrators, technical writers, testers, evangelists, UI/UX and graphics designers, cheerleaders, and dreamers.

This wiki covers a variety of ways that you can get involved with MediaGoblin as well as instructions on how to get started.

== Hang out with the MediaGoblin folk ==

MediaGoblin has a mailing list and an IRC channel where we hang out. See [http://mediagoblin.org/pages/join.html our join page] for links.

Please drop by and say “Hi!” And, if you’re looking for something to do, just ask---there’s always work to be done.

== Take Part in the Monthly Meetings ==

Each month is a [[Meeting]]. You can take part and help decide on the future of MediaGoblin. Or just be around and see what's happening live!

== File Bugs / Triage Bugs ==

Issue reports are critical for all projects. Identified bugs give developers a basis for beginning work, and providing an idea of what features and issues are most important to users and the overall usability of the software. If you identify errors, flaws, unexpected behaviors, or deficits that impede use, file a bug.

* [[File Bugs]] -- notes on filing new bugs/issues/feature requests
* [[Feature Ideas]] -- notes on possible features
* [[Triage Bugs]] -- notes on triaging

== Write Code / Fix Code ==

If you are a coder and you would like to write code, the repository is hosted on gitorious. Clone or fork the repository and start poking around. Become familiar with this manual for an overview of how the software works and is used. Consider the contributor wiki for more information about the project, our preferred methods, and guides for developing MediaGoblin. We even have tips on becoming a coder and we’re willing to help!

* [[HackingHowto|Hacking]] - notes on making and sending in code contributions
** [[BeginnersCorner|Beginner's Corner]] - resources for those who are new to Python or Git.
** ''Started from an older version of the Hacking Howto? We switched from buildout->virtualenv, so look at [[Moving from buildout to virtualenv]] for information on how to move over.''
* [[Git workflow]] - How to go about submitting patches via git.
* [[Templating]] - How our templating structure is set up
* [[Code overview]] - Overview of the structure of the codebase

== Send Encouragement / Spread the Word ==

Sometimes, a nice word, simple encouragement, and interest in the work we’re doing is enough to inspire a tizzy of productive work. Just a bit more interest and encouragement can even make the difference between a complete feature and limited functionality; between a completed milestone and lost momentum.

Similarly, MediaGoblin, and the movement for free network services, is always in need of encouragement. Use free network services, understand the principals behind the movement, be able to articulate the benefits of free network services and the problems with psudo-free applications that don’t respect the users’ freedom.

Write a blog post, post a status update, drop by the listserv or join #mediagoblin on freenode.net and let us know. See [http://mediagoblin.org/join/ our join page] for links.

== Write Documentation / Edit Documentation ==

* [[Documentation quick start]] - How to contribute to the documentation effort.
* [[ManualStandards]] - covers the standards for writing the user manual (forthcoming.)

== Test MediaGoblin ==

Do you have access to the web? Do you like sharing your opinions? If so, we need your help to test MediaGoblin! Testers play around with the current test instance, note what operating system and browser they use (notes on multiple set-ups are also helpful) and take some notes. That's it! It's a very important task that doesn't require any special knowledge and you're done in under an hour. Ready to help?

* [[User Experience]] - user experience testing. Includes link to an instance you can try!
* [[UnitTests|Unit Tests]] - all about the unit tests

== Translate MediaGoblin ==

If you know English and another language and feel comfortable translating elements of the interface or even the documentation, we’d love to have help translating the software and resources.

* [[Translations]] - How to translate stuff or update the translations

== Become a User ==

Coming soon!

We’re building MediaGoblin for us and for you but really you’re one of us and I am you and we are we and MediaGoblin is the walrus.

We're planning to launch our own public instance of MediaGoblin in the near future--probably in the September/October 2011 time frame. When we do, sign up for an account, use the service and relish in the thought that this service comes with a heaping side of Freedom and you can salt and pepper it to your liking.

== Help Others ==

Have you spent time with MediaGoblin? If so, your experience and wisdom are invaluable and you’re the best person we can think of to help other users with their questions.

Hang out on the IRC channel and help answer new peoples' questions. See [http://mediagoblin.org/join/ our join page] for links.

== Run your own MediaGoblin Instance ==

Are there things about our instance you want to change? Are there things about other instances you wish were different? Want to test upcoming changes? Want to create patches to implement things you need? That’s great—you can run your own instance!

* [[Configure_MediaGoblin|Configuration]] - Learn about MediaGoblin configuration files and file options.
* [[Deployment]] - General deployment advice
* [[Scaling Down]] - Minimizing MediaGoblin's resource requirements
* [[Virtual Machine Hosting]] - Deploy your own publicly available MediaGoblin server using [http://aws.amazon.com/free/?utm_source=adwords&utm_medium=cpc&utm_campaign=CPC_Google_AWS_ec2&utm_content=TextV01_PP_V01_EC2&trk=CPC_Google_AWS_ec2 Amazon's free EC2 tier].

== Create a Theme ==

Coming soon!

MedaGoblin development is premised on the idea that the entire interface for the platform be completely theme-able. If you have a design or theming background, consider developing themes for MediaGoblin. New themes help test the theming system, provide attractive and appealing interfaces for prospective users. If you want to start a new theme but don’t know where to start, touch base with the development community on the list or in the IRC channel for more information.

= Technical project documentation =

* [[DesignDecisions]] - covers design decisions (FIXME - this needs to be split up)
* [[Storage]] - How MediaGoblin's internal storage system works.
* [[Processing]] - What happens after you submit your image/video/etc? Processing! More about that.
* [https://gitorious.org/mediagoblin/mediagoblin/blobs/master/extlib/README External Library Policy] - covers use of external libraries
* [[User:Cwebber/braindumps]] - Chris Webber's braindumps (you can help refactoring these into real sections of the site!)
* [[Multiple media support]] - Design plan for multiple media support

= Inner workings of the secret sanctum =

* [[IRCBot]] - covers our irc bot
* [[ReleaseProcess|Release Process]] - covers the release process
* [[Update the website]] - Learn how to update mediagoblin.org!

Meeting

2012-08-04T13:11:32Z

Willkg:

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

August 4th, 2012, 9:00 am Pacific Time (2012-08-04 16:00 UTC)

* Release schedule
* Plugins and themes! Who's working on one? What problems are you having? -- Please write up issues for problems so they can get fixed!
* Should we namespace plugins? If so, how should we namespace plugins?
** Python 3.3 will have support for namespace plugins. [http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** In Python >=2.3, <3.3 it's a hack [http://www.python.org/dev/peps/pep-0402/#the-problem][http://www.python.org/dev/peps/pep-0420/#namespace-packages-today]
** Flask has a workaround[https://github.com/mitsuhiko/flask/blob/master/flask/ext/__init__.py]

== Past Meetings ==

== July 7th, 2012, 9:00 am Pacific Time (2012-07-07 16:00 UTC) ==

[http://mediagoblin.org/irclogs/irc_meeting_2012-07-07.txt IRC log]

Announcements:

* Anyone who wants to edit the wiki needs to be in the goblin army group. Ask Will or Chris to get added.
* Plugin infrastructure landed. If you're interested in writing plugins, talk to Will. Some documentation at http://docs.mediagoblin.org/#part-2-plugin-writer-s-guide

Agenda:

* Keyboard shortcuts ([http://issues.mediagoblin.org/ticket/346 #346])
* Ticket triaging?
* Base plugin stuff!
* Theming
* Conference: OSCON
* Chris Webber's new "office hours"

=== June 2nd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-06-02.txt IRC log]

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git and tickets
* Plugins
** What's the state of things?
** Documentation
** What plugins might we want to build for this upcoming release?
** What things do we currently have that we might want to pluginify?
* State of kuneco/federation mini-update (Chris)

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 am UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Virtual Machine Hosting

2012-08-01T13:55:33Z

Willkg: fixing the tag

{{Needswork}}

= Motivation =

If you want to give MediaGoblin a try, but would prefer to run it on someone else's machine for a while, then you may be interested in spinning up an [http://aws.amazon.com/ec2/ EC2] instance from an [http://aws.amazon.com/amis AMI] pre-loaded with MediaGoblin. The following [http://aws.amazon.com/articles/0155828273219400 recipe] should make a public MediaGoblin AMI. Make your own or skip ahead Martha Stewart style to [https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-3bf33252 ami-3bf33252]

== Get your favorite distribution to fit in less than 10 Gb volume size ==

Ubuntu makes this easy. Start with an official EC2 Ubuntu instance in us-east: [https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-61be7908 ami-61be7908]. Other [http://ubuntutym2.u-toyama.ac.jp/uec-images/lucid/20110719/ official Ubuntu AMIs] are also available

Login to this fresh instance using [http://aws.amazon.com/archives/Amazon-EC2/5673744618146887 EC2 tools]
<pre>me@myhomemachine:~$ ssh -i $(KEY_PATH) ubuntu@ec2-##-##-##-##.compute-1.amazonaws.com</pre>

Once logged in, update the links to package updating materials
<pre>sudo apt-get update</pre>

Then run the package manager to download and install the latest patches
<pre>sudo apt-get -u upgrade</pre>

Reboot from the EC2 instance manager. Then log in and install any remaining upgrades
<pre>sudo apt-get update
sudo apt-get -u upgrade</pre>

== Limit remote access to improve security ==

Disable password-based login by editing /etc/ssh/sshd_config to explicitly disallow it.
<pre>+# Disable password-based login
+PasswordAuthentication no</pre>

Also remove this moot parameter
<pre>-# To enable empty passwords, change to yes (NOT RECOMMENDED)
-PermitEmptyPasswords no</pre>

Reboot the ssh server
<pre>sudo restart ssh</pre>

Disable root login, and specify login by ubuntu only by editing /etc/ssh/sshd_config
<pre>-PermitRootLogin yes
+PermitRootLogin no
+AllowUsers ubuntu</pre>

Reboot the ssh server
<pre>sudo restart ssh</pre>

== Install MediaGoblin Prerequisites ==

Setup directory for mediagoblin source code
<pre>mkdir src
cd src</pre>

The following matches the [[HackingHowto]] except for how mongodb is installed. MongoDB is only at version 1.2.2 in Lucid 10.04, which the original AMI is based on, but MediaGoblin requires v1.3+
<pre>sudo apt-get install git-core python python-dev python-lxml</pre>

[http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages Get the latest mongodb]

First get the gpg key for the 10gen repository
<pre>sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10</pre>

Add the 10gen repository to the list of apt sources by editing /etc/apt/sources.list
<pre>+deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen</pre>

Install mongodb
<pre>sudo apt-get update
sudo apt-get install mongodb-10gen</pre>

Fetch the mediagoblin code from the git repository, buildout, and test
<pre>git clone git://gitorious.org/mediagoblin/mediagoblin.git
cd mediagoblin
python bootstrap.py && ./bin/buildout
./runtests.sh
###Ran 45 tests in 12.160s ... OK!</pre>

Install sendmail
<pre>sudo apt-get install sendmail</pre>

[[Configure MediaGoblin]]
<pre>cp paste.ini paste_local.ini
cp mediagoblin.ini mediagoblin_local.ini</pre>

Edit paste_local.ini to point to mediagoblin_local.ini and allow remote connections
<pre>-config = %(here)s/mediagoblin.ini
+config = %(here)s/mediagoblin_local.ini
-host = 127.0.0.1
+host = 0.0.0.0</pre>

== Prepare instance for bundling into a public AMI ==

The instance you've built so far is currently configured to accept your private key as a login. Lock yourself out now...or don't, and see if anyone notices. It's your call.

Find and remove your public key
<pre>sudo find / -name "authorized_keys" -print -exec rm {} \;</pre>

Verify you can not log in to the instance anymore
<pre>me@myhomemachine:~$ ssh -i $(KEY_PATH) ubuntu@ec2-##-##-##-##.compute-1.amazonaws.com
##Permission denied (publickey).</pre>

Take a snapshot, convert the snapshot to an AMI, then set the AMI permissions to public.

Virtual Machine Hosting

2012-08-01T13:55:10Z

Willkg: this page is sooooo old. tagging it with needs work because it needs serious updating.

{{{Needswork}}}

= Motivation =

If you want to give MediaGoblin a try, but would prefer to run it on someone else's machine for a while, then you may be interested in spinning up an [http://aws.amazon.com/ec2/ EC2] instance from an [http://aws.amazon.com/amis AMI] pre-loaded with MediaGoblin. The following [http://aws.amazon.com/articles/0155828273219400 recipe] should make a public MediaGoblin AMI. Make your own or skip ahead Martha Stewart style to [https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-3bf33252 ami-3bf33252]

== Get your favorite distribution to fit in less than 10 Gb volume size ==

Ubuntu makes this easy. Start with an official EC2 Ubuntu instance in us-east: [https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-61be7908 ami-61be7908]. Other [http://ubuntutym2.u-toyama.ac.jp/uec-images/lucid/20110719/ official Ubuntu AMIs] are also available

Login to this fresh instance using [http://aws.amazon.com/archives/Amazon-EC2/5673744618146887 EC2 tools]
<pre>me@myhomemachine:~$ ssh -i $(KEY_PATH) ubuntu@ec2-##-##-##-##.compute-1.amazonaws.com</pre>

Once logged in, update the links to package updating materials
<pre>sudo apt-get update</pre>

Then run the package manager to download and install the latest patches
<pre>sudo apt-get -u upgrade</pre>

Reboot from the EC2 instance manager. Then log in and install any remaining upgrades
<pre>sudo apt-get update
sudo apt-get -u upgrade</pre>

== Limit remote access to improve security ==

Disable password-based login by editing /etc/ssh/sshd_config to explicitly disallow it.
<pre>+# Disable password-based login
+PasswordAuthentication no</pre>

Also remove this moot parameter
<pre>-# To enable empty passwords, change to yes (NOT RECOMMENDED)
-PermitEmptyPasswords no</pre>

Reboot the ssh server
<pre>sudo restart ssh</pre>

Disable root login, and specify login by ubuntu only by editing /etc/ssh/sshd_config
<pre>-PermitRootLogin yes
+PermitRootLogin no
+AllowUsers ubuntu</pre>

Reboot the ssh server
<pre>sudo restart ssh</pre>

== Install MediaGoblin Prerequisites ==

Setup directory for mediagoblin source code
<pre>mkdir src
cd src</pre>

The following matches the [[HackingHowto]] except for how mongodb is installed. MongoDB is only at version 1.2.2 in Lucid 10.04, which the original AMI is based on, but MediaGoblin requires v1.3+
<pre>sudo apt-get install git-core python python-dev python-lxml</pre>

[http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages Get the latest mongodb]

First get the gpg key for the 10gen repository
<pre>sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10</pre>

Add the 10gen repository to the list of apt sources by editing /etc/apt/sources.list
<pre>+deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen</pre>

Install mongodb
<pre>sudo apt-get update
sudo apt-get install mongodb-10gen</pre>

Fetch the mediagoblin code from the git repository, buildout, and test
<pre>git clone git://gitorious.org/mediagoblin/mediagoblin.git
cd mediagoblin
python bootstrap.py && ./bin/buildout
./runtests.sh
###Ran 45 tests in 12.160s ... OK!</pre>

Install sendmail
<pre>sudo apt-get install sendmail</pre>

[[Configure MediaGoblin]]
<pre>cp paste.ini paste_local.ini
cp mediagoblin.ini mediagoblin_local.ini</pre>

Edit paste_local.ini to point to mediagoblin_local.ini and allow remote connections
<pre>-config = %(here)s/mediagoblin.ini
+config = %(here)s/mediagoblin_local.ini
-host = 127.0.0.1
+host = 0.0.0.0</pre>

== Prepare instance for bundling into a public AMI ==

The instance you've built so far is currently configured to accept your private key as a login. Lock yourself out now...or don't, and see if anyone notices. It's your call.

Find and remove your public key
<pre>sudo find / -name "authorized_keys" -print -exec rm {} \;</pre>

Verify you can not log in to the instance anymore
<pre>me@myhomemachine:~$ ssh -i $(KEY_PATH) ubuntu@ec2-##-##-##-##.compute-1.amazonaws.com
##Permission denied (publickey).</pre>

Take a snapshot, convert the snapshot to an AMI, then set the AMI permissions to public.

Meeting

2012-07-07T15:12:05Z

Willkg: /* Next Meeting */ adding announcements

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

July 7th, 2012, 9:00 am Pacific Time (2012-07-07 16:00 UTC)

Announcements:

* Anyone who wants to edit the wiki needs to be in the goblin army group. Ask Will or Chris to get added.
* Plugin infrastructure landed. If you're interested in writing plugins, talk to Will. Some documentation at http://docs.mediagoblin.org/#part-2-plugin-writer-s-guide

Agenda:

* Keyboard shortcuts ([http://issues.mediagoblin.org/ticket/346 #346])
* Ticket triaging?
* Theming
* Conference: OSCON
* Chris Webber's new "office hours"

== Past Meetings ==

=== June 2nd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-06-02.txt IRC log]

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git and tickets
* Plugins
** What's the state of things?
** Documentation
** What plugins might we want to build for this upcoming release?
** What things do we currently have that we might want to pluginify?
* State of kuneco/federation mini-update (Chris)

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 am UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Template:Trac

2012-07-06T15:26:59Z

Willkg: fix trac macro docs

[http://issues.mediagoblin.org/ticket/{{{1}}} {{{2|Issue {{{1}}}}}}]<noinclude>
== Usage ==
This allows creating easy-to-build links to Trac issues.

Copy and paste this in:

<pre>
{{Trac|issue-number[|optional-issue-text]}}
</pre>

E.g.:

<pre>
{{Trac|387}}
{{Trac|387|issue for writing a trac macro}}
</pre>
</noinclude>

PluginSystemDesignDocument

2012-07-06T15:26:23Z

Willkg:

== Status ==

February 25th, 2012: Initial writing. Needs work.

Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

Covered in {{Trac|401}}

== Use cases ==

This is a set of use cases we're thinking about. It is not exhaustive.

* site flat pages (about this site, donations page, how to contribute, how to get an account, terms of service, ...)
* add restrictions to uploaded content
** restrict by file size
** restrict by type
** restrict by dimensions (height x width)
* quotas (user can only have x images on site, user can only use total of 50mb, ...)
* comment spam detection
* authentication
* additional admin web pages
* extending existing media types (Add new formats for video encoding or flash display, etc?)
* things MediaGoblin already kind of does
** Storage system extensibility
** Media type extensibility

== What makes a good plugin system? ==

# plugin management system - The following should be optimized for ease-of-use:
#* installing plugins
#* configuring plugins
#* removing plugins
#* getting status on plugins
#* getting errors from plugins
# plugin API - In order to augment MediaGoblin's behavior, the plugin needs to be able to assert itself into MediaGoblin's various pipelines. This can be done with hook, signals, registration, ...
# documentation - how to build, test, install, uninstall, and share plugins
# a place where site admin can find and download plugins

== High-level plan ==

I think the plan should be something along these lines:

# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running {{Cmd|./bin/gmg updatedb}} for setting up db tables.
# Expose our testing framework. Plugins should be testable and it'd be nice to test everything in a GMG install with a single {{Cmd|./runtests.sh}}.
# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
# Database storage. Migrations, adding new tables.
# Templates. Adding new templates, template blocks, ...
# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like {{Cmd|./bin/gmg copy_static_assets}} or something less crappy that gets filled based on config file settings
# Need to be able to do three different things:
#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...
#* transform: plugin gets to modify some thing as it's getting processed. Examples: context processors, adding additional template tags, ...
#* handler: plugin handles some thing and if the plugin handles it, then processing ends. Examples: authentication, ...
# Implement a MediaGoblin plugin API. Expose things that need exposing, implement stuff in the core, ...
# We can do a PyPI-like thing for plugins. Needs to allow for comments, ratings, blah blah blah.
# Build a plugin writers documentation guide.
# GMG would/could come with a set of core plugins.

=== Install/uninstall ===

TBD.

=== Routing ===

TBD.

=== Database storage ===

TBD.

=== Templates ===

TBD.

=== Version checking ===

TBD.

=== Notification, transform and handler ===

TBD.

== Execution on the plan ==

# Flesh out the plan into a better design document and get a consensus on it.
# Flesh out the design details.
# Implement initial bits and write documentation.
# Write some plugins.
# Iterate going forward: Take stock of where we're at and what we're missing, implement a new piece, ...

PluginSystemDesignDocument

2012-07-06T15:24:56Z

Willkg:

== Status ==

February 25th, 2012: Initial writing. Needs work.

Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

Covered in {{{Trac|401}}}

== Use cases ==

This is a set of use cases we're thinking about. It is not exhaustive.

* site flat pages (about this site, donations page, how to contribute, how to get an account, terms of service, ...)
* add restrictions to uploaded content
** restrict by file size
** restrict by type
** restrict by dimensions (height x width)
* quotas (user can only have x images on site, user can only use total of 50mb, ...)
* comment spam detection
* authentication
* additional admin web pages
* extending existing media types (Add new formats for video encoding or flash display, etc?)
* things MediaGoblin already kind of does
** Storage system extensibility
** Media type extensibility

== What makes a good plugin system? ==

# plugin management system - The following should be optimized for ease-of-use:
#* installing plugins
#* configuring plugins
#* removing plugins
#* getting status on plugins
#* getting errors from plugins
# plugin API - In order to augment MediaGoblin's behavior, the plugin needs to be able to assert itself into MediaGoblin's various pipelines. This can be done with hook, signals, registration, ...
# documentation - how to build, test, install, uninstall, and share plugins
# a place where site admin can find and download plugins

== High-level plan ==

I think the plan should be something along these lines:

# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running {{Cmd|./bin/gmg updatedb}} for setting up db tables.
# Expose our testing framework. Plugins should be testable and it'd be nice to test everything in a GMG install with a single {{Cmd|./runtests.sh}}.
# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
# Database storage. Migrations, adding new tables.
# Templates. Adding new templates, template blocks, ...
# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like {{Cmd|./bin/gmg copy_static_assets}} or something less crappy that gets filled based on config file settings
# Need to be able to do three different things:
#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...
#* transform: plugin gets to modify some thing as it's getting processed. Examples: context processors, adding additional template tags, ...
#* handler: plugin handles some thing and if the plugin handles it, then processing ends. Examples: authentication, ...
# Implement a MediaGoblin plugin API. Expose things that need exposing, implement stuff in the core, ...
# We can do a PyPI-like thing for plugins. Needs to allow for comments, ratings, blah blah blah.
# Build a plugin writers documentation guide.
# GMG would/could come with a set of core plugins.

=== Install/uninstall ===

TBD.

=== Routing ===

TBD.

=== Database storage ===

TBD.

=== Templates ===

TBD.

=== Version checking ===

TBD.

=== Notification, transform and handler ===

TBD.

== Execution on the plan ==

# Flesh out the plan into a better design document and get a consensus on it.
# Flesh out the design details.
# Implement initial bits and write documentation.
# Write some plugins.
# Iterate going forward: Take stock of where we're at and what we're missing, implement a new piece, ...

Template:Trac

2012-07-06T15:22:30Z

Willkg: Created page with "[http://issues.mediagoblin.org/ticket/{{{1}}} {{{2|Issue {{{1}}}}}}]<noinclude> == Usage == This allows creating easy-to-build links to Trac issues. Copy and paste this in: <pr..."

[http://issues.mediagoblin.org/ticket/{{{1}}} {{{2|Issue {{{1}}}}}}]<noinclude>
== Usage ==
This allows creating easy-to-build links to Trac issues.

Copy and paste this in:

<pre>
{{{Trac|issue-number[|optional-issue-text]}}}
</pre>

E.g.:

<pre>
{{{Trac|387}}}
{{{Trac|387|issue for writing a trac macro}}}
</pre>
</noinclude>

Git workflow

2012-06-03T20:01:30Z

Willkg: /* Tie your changes to issues in the issue tracker */ update issue tracker

GNU MediaGoblin uses git for all our version control and we have the
repositories hosted on [http://gitorious.org/ Gitorious]. We have
two repositories:

* MediaGoblin software: http://gitorious.org/mediagoblin/mediagoblin
* MediaGoblin website: http://gitorious.org/mediagoblin/mediagoblin-website

It's most likely you want to look at the software repository -- not the
website one.

The rest of this chapter talks about using the software repository.

= How to clone the project =

Do::

git clone git://gitorious.org/mediagoblin/mediagoblin.git

= How to contribute changes =

== Tie your changes to issues in the issue tracker ==

All patches should be tied to issues in the
[http://issues.mediagoblin.org/ issue tracker].
That makes it a lot easier for everyone to track proposed changes and
make sure your hard work doesn't get dropped on the floor! If there
isn't an issue for what you're working on, please create one. The
better the description of what it is you're trying to fix/implement,
the better everyone else is able to understand why you're doing what
you're doing.

== Use bugfix branches to make changes ==

The best way to isolate your changes is to create a branch based off
of the MediaGoblin repository master branch, do the changes related to
that one issue there, and then let us know how to get it.

It's much easier on us if you isolate your changes to a branch focused
on the issue. Then we don't have to sift through things.

It's much easier on you if you isolate your changes to a branch
focused on the issue. Then when we merge your changes in, you just
have to do a {{Cmd|git fetch}} and that's it. This is especially true if
we reject some of your changes, but accept others or otherwise tweak
your changes.

Further, if you isolate your changes to a branch, then you can work on
multiple issues at the same time and they don't conflict with one
another.

Name your branches using the isue number and something that makes it clear
what it's about. For example, if you were working on tagging, you
might name your branch "360_tagging".

== Properly document your changes ==

Include comments in the code.

Write comprehensive commit messages. The better your commit message
is at describing what you did and why, the easier it is for us to
quickly accept your patch.

Write comprehensive comments in the issue tracker about what you're
doing and why.

== How to send us your changes ==

There are two ways to let us know how to get it:

=== push changes to publicly available git clone and let us know where to find it ===

''This is the preferred method of sending changes.''

Push your feature/bugfix/issue branch to your publicly available
git clone and add a comment to the issue with the url for your
clone and the branch to look at.

=== attaching the patch files to the issue ===

Run

{{Cmd|git format-patch --stdout <remote>/master > issue_<number>.patch}}

<tt>format-patch</tt> creates a patch of all the commits that are in
your branch that aren't in <tt><remote>/master</tt>. The <tt>--stdout</tt>
flag causes all this output to go to stdout where it's redirected
to a file named <tt>issue_<number>.patch</tt>. That file should be
based on the issue you're working with. For example,
<tt>issue_42.patch</tt> is a good filename and <tt>issue_42_rev2.patch</tt>
is good if you did a revision of it.

Having said all that, the filename isn't wildly important.

= Example workflow =

Here's an example workflow.

== Contributing changes ==

Slartibartfast from the planet Magrathea far off in the universe has
decided that he is bored with fjords and wants to fix issue 42 (the
meaning of life bug) and send us the changes.

Slartibartfast has cloned the MediaGoblin repository and his clone
lives on gitorious.

Slartibartfast works locally. The remote named ``origin`` points to
his clone on gitorious. The remote named ``gmg`` points to the
MediaGoblin repository.

Slartibartfast does the following:

1. Fetches the latest from the MediaGoblin repository::

git fetch --all -p

This tells <tt>git fetch</tt> to fetch all the recent data from all of
the remotes (<tt>--all</tt>) and prune any branches that have been
deleted in the remotes (<tt>-p</tt>).

2. Creates a branch from the tip of the MediaGoblin repository (the remote is named <tt>gmg</tt>) master branch called <tt>bug42_meaning_of_life</tt>:

git checkout -b bug42_meaning_of_life gmg/master

This creates a new branch (<tt>-b</tt>) named <tt>bug42_meaning_of_life</tt> based
on the tip of the <tt>master</tt> branch of the remote named <tt>gmg</tt> and checks
it out.

3. Slartibartfast works hard on his changes in the <tt>bug42_meaning_of_life</tt> branch. When done, he wants to notify us that he has made changes he wants us to see.

4. Slartibartfast pushes his changes to his clone::

git push origin bug42_meaning_of_life --set-upstream

This pushes the changes in the <tt>bug42_meaning_of_life</tt> branch to the remote named <tt>origin</tt>.

5. Slartibartfast adds a comment to issue 42 with the url for his repository and the name of the branch he put the code in. He also explains what he did and why it addresses the issue.

== Updating a contribution ==

Slartibartfast brushes his hands off with the sense of accomplishment
that comes with the knowledge of a job well done. He stands, wanders
over to get a cup of water, then realizes that he forgot to run the
unit tests!

He runs the unit tests and discovers there's a bug in the code!

Then he does this:

1. He checks out the <tt>bug42_meaning_of_life</tt> branch::

git checkout bug42_meaning_of_life

2. He fixes the bug and checks it into the <tt>bug42_meaning_of_life</tt> branch.

3. He pushes his changes to his clone (the remote is named <tt>origin</tt>):

git push origin bug42_meaning_of_life

4. He adds another comment to issue 42 explaining about the mistake and how he fixed it and that he's pushed the new change to the <tt>bug42_meaning_of_life</tt> branch of his publicly available clone.

== What happens next ==

Slartibartfast is once again happy with his work. He finds issue 42
in the issue tracker and adds a comment saying he submitted a merge
request with his changes and explains what they are.

Later, someone checks out his code and finds a problem with it. He
adds a comment to the issue tracker specifying the problem and asks
Slartibartfast to fix it. Slartibartfst goes through the above steps
again, fixes the issue, pushes it to his
<tt>bug42_meaning_of_life</tt> branch and adds another comment to the
issue tracker about how he fixed it.

Later, someone checks out his code and is happy with it. Someone
pulls it into the master branch of the MediaGoblin repository and adds
another comment to the issue and probably closes the issue out.

Slartibartfast is notified of this. Slartibartfast does a:

git fetch --all

The changes show up in the <tt>master</tt> branch of the <tt>gmg</tt> remote.
Slartibartfast now deletes his <tt>bug42_meaning_of_life</tt> branch
because he doesn't need it anymore.

= How to learn git =

[[BeginnersCorner#Learning_git]]

Meeting

2012-06-02T18:24:25Z

Willkg: updated after the june 2nd 2012 meeting

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

July 7th, 2012, 9:00 am Pacific Time (2012-07-07 16:00 UTC)

No agenda, yet.

== Past Meetings ==

=== June 2nd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-06-02 IRC log]

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git and tickets
* Plugins
** What's the state of things?
** Documentation
** What plugins might we want to build for this upcoming release?
** What things do we currently have that we might want to pluginify?
* State of kuneco/federation mini-update (Chris)

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 am UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Meeting

2012-06-02T15:11:47Z

Willkg: /* Next Meeting */

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

June 2nd, 2012, 9:00 am Pacific Time (2012-06-02 16:00 UTC)

* docs changes
** Will split the docs/ guide into a Site Administrator's Guide and a Plugin Writer's Guide
** Has anyone looked at the Plugin Writer's Guide, yet?
** Will wants to add a "Contributor's Guide" to docs/ which he'd update from the wiki before every release
* Is there a way to improve our unit tests and motivation to write them?
** Simulating a browser by the way of [http://phantomjs.org/ PhantomJS], [http://seleniumhq.org/ Selenium] instead of having code simulating other code against itself might be more natural to write and even more testing the actual application. I have a good feeling about this, please prove me wrong if I'd be. --[[User:Joar|Joar]] 08:53, 28 May 2012 (EDT)
* Administrative panel/tools and user uploads panel
* Git workflow discussion
* Plugins
* Kuneco update

== Past Meetings ==

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 am UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Meeting

2012-05-21T12:49:33Z

Willkg: add docs suggestions to next meeting agenda

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]. Print current UTC time: <code>date -u +"It's %F %T UTC"</code>

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

June 2nd, 2012, 9:00 am Pacific Time (2012-06-02 16:00 UTC)

* docs changes
** Will wants to add a "plugin writer's guide" to docs/
** Will wants to add a "contributor's guide" to docs/
** this is similar to how he structured richard's documentation: http://richard.readthedocs.org/en/latest/index.html

== Past Meetings ==

=== May 5th, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-05-05.txt IRC log]

* Post-release reflections
** Woohoo, release!
** How did this release process go?
*** We should talk about that conference.
** What's left to clean up?
*** Mongokit->SQL "style" query conversion?
*** Other cruft code?
* What are our next goals?
** Plugins
** Federation
** Favoriting
*** Take that, Pinterest! ;)
** Galleries
** Theming
*** Using sass would be neat
** Access restrictions
*** User management, or having a "secret url" that is not in the photo index that you can share with friends and generate as needed for any media type
** What about traffic? Some of us will host GMG on limited plans.
** Some kind of coding guidelines? Do we have a philosophy like "Keep it Simple, Stupid"
*** This concerns things like: Should plugins land in core eventually, do we want to support ALL THE MEDIA TYPES, ...
** Podcasting support?
** Things that have been hanging???
** Bugtrackers and milestone?
** More??? We should organize things!
* jancborchardt and his team of UX wizard-students
* Website redesign
* OpenShift?

=== April 7th, 2012, 4:00 am UTC ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-04-07.txt IRC log]

* Post-SQL stuff
* Pending 0.0.3 release!
* Are there stray patches/branches to be merged?
* Our glorious upcoming plugin future! (Update from Will)

=== March 3rd, 2012, 9:00 am Pacific Time ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-03-03.txt IRC log]

* [[GSOC 2012]]
* State of the SQL transition (preview: it's super close, but we need help!)
* Plugin discussion (Will can't make this, but we should talk about use cases)
* MediaGoblin at upcoming conferences
* PageKite accounts

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

ArticlesAboutDeadServices

2012-05-15T18:01:32Z

Willkg: Created page with "This is a list of articles found on the Internet about services ending. May 15th, 2012 http://blog.lightbox.com/post/23107101360/lightbox-is-joining-facebook : Covers Lightbo..."

This is a list of articles found on the Internet about services ending.

May 15th, 2012

http://blog.lightbox.com/post/23107101360/lightbox-is-joining-facebook

: Covers Lightbox (which was sort of like Instagram) ending their service because the developers are joining Facebook.

http://gizmodo.com/5910223/how-yahoo-killed-flickr-and-lost-the-internet

User:Willkg

2012-04-22T17:19:47Z

Willkg: Created page with "= Me = I'm Will Kahn-Greene. {| |- | '''irc''' || willg on freenode |- | '''blog''' || http://bluesock.org/~willg/ |- | '''mediagoblin account''' || http://mediagoblin.com/u/wi..."

= Me =

I'm Will Kahn-Greene.

{|
|-
| '''irc''' || willg on freenode
|-
| '''blog''' || http://bluesock.org/~willg/
|-
| '''mediagoblin account''' || http://mediagoblin.com/u/willkg/
|}

= My involvement =

I'm currently involved with the following in order of activity level:

* release manager
* infrastructure admin
** mediagoblin.org maintenance
** wiki.mediagoblin.org maintenance (MediaWiki)
** issues.mediagoblin.org maintenance (Trac)
** gmgbot irc bot maintenance (supybot)
* documentation writer/manager
* developer (I tend to do coding in spurts)

I share most of these activities with other people.

= Past activities =

* I migrated us from Redmine to Trac
* I set up most of the project infrastructure
* I set up the original documentation

= Caveat =

I'm involved in too many projects. Because of that, I work on MediaGoblin in spurts/sprints. I'm usually on irc, though.

HackingHowto

2012-04-21T01:34:26Z

Willkg: tweaking vertical white space

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at [http://docs.mediagoblin.org/codebase.html codebase chapter] where
we've started documenting how GNU MediaGoblin is built and how to add
new things. If you're planning on contributing in python, you should be aware
of [http://www.python.org/dev/peps/pep-0008/ PEP-8], the official Python style guide,
which we follow.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use an
in-package checkout of virtualenv. This isn't the convenional way to
install virtualenv (normally you don't install virtualenv inside the
package itself) but we've found that it's significantly easier for
newcomers who aren't already familiar with virtualenv. If you *are*
already familiar with virtualenv, feel free to just install
mediagoblin in your own virtualenv setup... the necessary adjustments
should be obvious.

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* SQLAlchemy - http://www.sqlalchemy.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/
* virtualenv - http://www.virtualenv.org/
* Python GStreamer Bindings - http://gstreamer.freedesktop.org/modules/gst-python.html

=== GNU/Linux ===

==== Debian and derivatives ====

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install git-core python python-dev python-lxml python-imaging python-virtualenv python-gst0.10 libjpeg8-dev}}

==== Fedora / RedHat(?) ====

On Fedora:

{{Cmd|yum install python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging python-virtualenv gstreamer-python}}

=== Mac OS X ===

On Mac OS X Lion:

Download the Newest Python.

Git is already installed.

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html Combo Installer

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions, Windows, or Mac OS X to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with virtualenv ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

* Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
* Change directories to your new checkout: {{Cmd|cd mediagoblin}}
* Set up the in-package virtualenv:
(virtualenv --system-site-packages . || virtualenv .) && ./bin/python setup.py develop
* Init the database:
{{Cmd|./bin/gmg dbupdate}}

That's it!

(If you have troubles in the remaining steps, consider try installing
virtualenv with one of the flags --setuptools, --distribute or possibly --no-site-packages. Additionally, if your system has python3.X as the default, you might need to do virtualenv --python=python2.7 or --python=python2.6)

If you have problems, please [http://mediagoblin.org/join/ let us know]!

== Updating an existing environment ==

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/python setup.py develop --upgrade && ./bin/gmg dbupdate}}

'''Updating for code changes'''

{{Cmd|git pull -u}}

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}

This will start up a python server where you can begin playing with
mediagoblin, listening on 127.0.0.1:6543. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

By default, the instance is not sending out confirmation mails. Instead they are redirected to the standard output (the console) of lazyserver.sh.

You can change this behavior setting <code>email_debug_mode</code> to <code>false</code> in mediagoblin.ini

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

=== Problems with PIL ===

Some users have claimed they've had trouble with PIL working nicely on their system. You could try installing Pillow:

{{Cmd|./bin/pip install pillow}}

... note that we don't "officially" support pillow at this time.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|gmg wipealldata}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has SQLAlchemy ORM definitions
* <tt>views.py</tt> is where the views go

We're using SQLAlchemy, which is semi-similar to the Django ORM, but
not really because you can get a lot more fine-grained. The
[http://docs.sqlalchemy.org/en/latest/orm/tutorial.html SQLAlchemy ORM tutorial] is a great place to start.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

Now you should visit our latest list of [http://issues.mediagoblin.org/query?status=!closed&keywords=~bitesized bite-sized issues] because squishing bugs is messy fun. If you're interested in other things to work on, or need help getting started on a bug, let us know on [http://mediagoblin.org/join/ the mailing list] or on the [http://mediagoblin.org/join/ IRC channel].

Main Page

2012-04-21T01:24:43Z

Willkg: normalizing vertical whitespace

= Want to Join the MediaGoblin Community? =

We’re really glad that you want to join the MediaGoblin community!

There are a variety of ways to help and support MediaGoblin and to join the team. If you want to code, great, if not, even better! MediaGoblin interested contributors in many different roles: users, system administrators, technical writers, testers, evangelists, UI/UX and graphics designers, cheerleaders, and dreamers.

This wiki covers a variety of ways that you can get involved with MediaGoblin as well as instructions on how to get started.

== Hang out with the MediaGoblin folk ==

MediaGoblin has a mailing list and an IRC channel where we hang out. See [http://mediagoblin.org/join/ our join page] for links.

Please drop by and say “Hi!” And, if you’re looking for something to do, just ask---there’s always work to be done.

== Take Part in the Monthly Meetings ==

Each month is a [[Meeting]]. You can take part and help decide on the future of MediaGoblin. Or just be around and see what's happening live!

== File Bugs / Triage Bugs ==

Issue reports are critical for all projects. Identified bugs give developers a basis for beginning work, and providing an idea of what features and issues are most important to users and the overall usability of the software. If you identify errors, flaws, unexpected behaviors, or deficits that impede use, file a bug.

* [[File Bugs]] -- notes on filing new bugs/issues/feature requests
* [[Feature Ideas]] -- notes on possible features
* [[Triage Bugs]] -- notes on triaging

== Write Code / Fix Code ==

If you are a coder and you would like to write code, the repository is hosted on gitorious. Clone or fork the repository and start poking around. Become familiar with this manual for an overview of how the software works and is used. Consider the contributor wiki for more information about the project, our preferred methods, and guides for developing MediaGoblin. We even have tips on becoming a coder and we’re willing to help!

* [[HackingHowto|Hacking]] - notes on making and sending in code contributions
** [[BeginnersCorner|Beginner's Corner]] - resources for those who are new to Python, MongoDB, or Git.
** ''Started from an older version of the Hacking Howto? We switched from buildout->virtualenv, so look at [[Moving from buildout to virtualenv]] for information on how to move over.''
* [[Git workflow]] - How to go about submitting patches via git.
* [[Templating]] - How our templating structure is set up
* [[Code overview]] - Overview of the structure of the codebase

== Send Encouragement / Spread the Word ==

Sometimes, a nice word, simple encouragement, and interest in the work we’re doing is enough to inspire a tizzy of productive work. Just a bit more interest and encouragement can even make the difference between a complete feature and limited functionality; between a completed milestone and lost momentum.

Similarly, MediaGoblin, and the movement for free network services, is always in need of encouragement. Use free network services, understand the principals behind the movement, be able to articulate the benefits of free network services and the problems with psudo-free applications that don’t respect the users’ freedom.

Write a blog post, post a status update, drop by the listserv or join #mediagoblin on freenode.net and let us know. See [http://mediagoblin.org/join/ our join page] for links.

== Write Documentation / Edit Documentation ==

* [[Documentation quick start]] - How to contribute to the documentation effort.
* [[ManualStandards]] - covers the standards for writing the user manual (forthcoming.)

== Test MediaGoblin ==

Do you have access to the web? Do you like sharing your opinions? If so, we need your help to test MediaGoblin! Testers play around with the current test instance, note what operating system and browser they use (notes on multiple set-ups are also helpful) and take some notes. That's it! It's a very important task that doesn't require any special knowledge and you're done in under an hour. Ready to help?

* [[User Experience]] - user experience testing. Includes link to an instance you can try!
* [[UnitTests|Unit Tests]] - all about the unit tests

== Translate MediaGoblin ==

If you know English and another language and feel comfortable translating elements of the interface or even the documentation, we’d love to have help translating the software and resources.

* [[Translations]] - How to translate stuff or update the translations

== Become a User ==

Coming soon!

We’re building MediaGoblin for us and for you but really you’re one of us and I am you and we are we and MediaGoblin is the walrus.

We're planning to launch our own public instance of MediaGoblin in the near future--probably in the September/October 2011 time frame. When we do, sign up for an account, use the service and relish in the thought that this service comes with a heaping side of Freedom and you can salt and pepper it to your liking.

== Help Others ==

Have you spent time with MediaGoblin? If so, your experience and wisdom are invaluable and you’re the best person we can think of to help other users with their questions.

Hang out on the IRC channel and help answer new peoples' questions. See [http://mediagoblin.org/join/ our join page] for links.

== Run your own MediaGoblin Instance ==

Are there things about our instance you want to change? Are there things about other instances you wish were different? Want to test upcoming changes? Want to create patches to implement things you need? That’s great—you can run your own instance!

* [[Configure_MediaGoblin|Configuration]] - Learn about MediaGoblin configuration files and file options.
* [[Deployment]] - General deployment advice
* [[Scaling Down]] - Minimizing MediaGoblin's resource requirements
* [[Virtual Machine Hosting]] - Deploy your own publicly available MediaGoblin server using [http://aws.amazon.com/free/?utm_source=adwords&utm_medium=cpc&utm_campaign=CPC_Google_AWS_ec2&utm_content=TextV01_PP_V01_EC2&trk=CPC_Google_AWS_ec2 Amazon's free EC2 tier].

== Create a Theme ==

Coming soon!

MedaGoblin development is premised on the idea that the entire interface for the platform be completely theme-able. If you have a design or theming background, consider developing themes for MediaGoblin. New themes help test the theming system, provide attractive and appealing interfaces for prospective users. If you want to start a new theme but don’t know where to start, touch base with the development community on the list or in the IRC channel for more information.

= Technical project documentation =

* [[DesignDecisions]] - covers design decisions (FIXME - this needs to be split up)
* [[Storage]] - How MediaGoblin's internal storage system works.
* [[Processing]] - What happens after you submit your image/video/etc? Processing! More about that.
* [https://gitorious.org/mediagoblin/mediagoblin/blobs/master/extlib/README External Library Policy] - covers use of external libraries
* [[User:Cwebber/braindumps]] - Chris Webber's braindumps (you can help refactoring these into real sections of the site!)
* [[Multiple media support]] - Design plan for multiple media support

= Inner workings of the secret sanctum =

* [[IRCBot]] - covers our irc bot
* [[ReleaseProcess|Release Process]] - covers the release process
* [[Update the website]] - Learn how to update mediagoblin.org!

PluginSystemDesignDocument

2012-02-26T13:53:11Z

Willkg: add tests section; fixed commands formatting

== Status ==

February 25th, 2012: Initial writing. Needs work.

Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

== Use cases ==

This is a set of use cases we're thinking about. It is not exhaustive.

* site flat pages (about this site, donations page, how to contribute, how to get an account, terms of service, ...)
* add restrictions to uploaded content
** restrict by file size
** restrict by type
** restrict by dimensions (height x width)
* quotas (user can only have x images on site, user can only use total of 50mb, ...)
* comment spam detection
* authentication
* additional admin web pages
* extending existing media types (Add new formats for video encoding or flash display, etc?)
* things MediaGoblin already kind of does
** Storage system extensibility
** Media type extensibility

== What makes a good plugin system? ==

# plugin management system - The following should be optimized for ease-of-use:
#* installing plugins
#* configuring plugins
#* removing plugins
#* getting status on plugins
#* getting errors from plugins
# plugin API - In order to augment MediaGoblin's behavior, the plugin needs to be able to assert itself into MediaGoblin's various pipelines. This can be done with hook, signals, registration, ...
# documentation - how to build, test, install, uninstall, and share plugins
# a place where site admin can find and download plugins

== High-level plan ==

I think the plan should be something along these lines:

# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running {{Cmd|./bin/gmg updatedb}} for setting up db tables.
# Expose our testing framework. Plugins should be testable and it'd be nice to test everything in a GMG install with a single {{Cmd|./runtests.sh}}.
# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
# Database storage. Migrations, adding new tables.
# Templates. Adding new templates, template blocks, ...
# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like {{Cmd|./bin/gmg copy_static_assets}} or something less crappy that gets filled based on config file settings
# Need to be able to do three different things:
#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...
#* transform: plugin gets to modify some thing as it's getting processed. Examples: context processors, adding additional template tags, ...
#* handler: plugin handles some thing and if the plugin handles it, then processing ends. Examples: authentication, ...
# Implement a MediaGoblin plugin API. Expose things that need exposing, implement stuff in the core, ...
# We can do a PyPI-like thing for plugins. Needs to allow for comments, ratings, blah blah blah.
# Build a plugin writers documentation guide.
# GMG would/could come with a set of core plugins.

=== Install/uninstall ===

TBD.

=== Routing ===

TBD.

=== Database storage ===

TBD.

=== Templates ===

TBD.

=== Version checking ===

TBD.

=== Notification, transform and handler ===

TBD.

== Execution on the plan ==

# Flesh out the plan into a better design document and get a consensus on it.
# Flesh out the design details.
# Implement initial bits and write documentation.
# Write some plugins.
# Iterate going forward: Take stock of where we're at and what we're missing, implement a new piece, ...

PluginSystemDesignDocument

2012-02-25T18:24:18Z

Willkg: the beginning of a plugins system design document

== Status ==

February 25th, 2012: Initial writing. Needs work.

Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

== Use cases ==

This is a set of use cases we're thinking about. It is not exhaustive.

* site flat pages (about this site, donations page, how to contribute, how to get an account, terms of service, ...)
* add restrictions to uploaded content
** restrict by file size
** restrict by type
** restrict by dimensions (height x width)
* quotas (user can only have x images on site, user can only use total of 50mb, ...)
* comment spam detection
* authentication
* additional admin web pages
* extending existing media types (Add new formats for video encoding or flash display, etc?)
* things MediaGoblin already kind of does
** Storage system extensibility
** Media type extensibility

== What makes a good plugin system? ==

# plugin management system - The following should be optimized for ease-of-use:
#* installing plugins
#* configuring plugins
#* removing plugins
#* getting status on plugins
#* getting errors from plugins
# plugin API - In order to augment MediaGoblin's behavior, the plugin needs to be able to assert itself into MediaGoblin's various pipelines. This can be done with hook, signals, registration, ...
# documentation - how to build, test, install, uninstall, and share plugins
# a place where site admin can find and download plugins

== High-level plan ==

I think the plan should be something along these lines:

# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running ``./bin/gmg updatedb`` for setting up db tables.
# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
# Database storage. Migrations, adding new tables.
# Templates. Adding new templates, template blocks, ...
# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like ./bin/gmg copy_static_assets or something less crappy that gets filled based on config file settings
# Need to be able to do three different things:
#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...
#* transform: plugin gets to modify some thing as it's getting processed. Examples: context processors, adding additional template tags, ...
#* handler: plugin handles some thing and if the plugin handles it, then processing ends. Examples: authentication, ...
# Implement a MediaGoblin plugin API. Expose things that need exposing, implement stuff in the core, ...
# We can do a PyPI-like thing for plugins. Needs to allow for comments, ratings, blah blah blah.
# Build a plugin writers documentation guide.
# GMG would/could come with a set of core plugins.

=== Install/uninstall ===

TBD.

=== Routing ===

TBD.

=== Database storage ===

TBD.

=== Templates ===

TBD.

=== Version checking ===

TBD.

=== Notification, transform and handler ===

TBD.

== Execution on the plan ==

# Flesh out the plan into a better design document and get a consensus on it.
# Flesh out the design details.
# Implement initial bits and write documentation.
# Write some plugins.
# Iterate going forward: Take stock of where we're at and what we're missing, implement a new piece, ...

Meeting

2012-02-05T23:57:17Z

Willkg: update meeting page, add notes, clean up summary

== MediaGoblin Monthly Meeting ==

'''When:''' 9:00 am Pacific Time first Saturday of the month. [http://www.timeanddate.com/worldclock/converter.html Convert time to your timezone]

'''Where:''' IRC #mediagoblin on irc.freenode.net

Always announced several days in advance on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list] as is date adjustments, agenda discussion and other meeting preparation.

'''Purpose:''' The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

Typical Agenda topics:

* What happened in the last month, what was good, what could be better next time?
* What should be done next month?

Meetings are logged. [http://mediagoblin.org/irclogs/ Logs for past meetings.]

== Next Meeting ==

=== March 3rd, 2012, 9:00 am Pacific Time ===

No agenda, yet.

== Past Meetings ==

=== 2012-02 (held on 2012-02-04) ===

[http://mediagoblin.org/irclogs/irc_meeting_2012-02-04.txt IRC log]

* Code style guide? See also: http://issues.mediagoblin.org/ticket/197
* Kuneco/federation
* API
* More testing discussion?
* Theming?
* Preliminary plugin discussion
* Status update from the "SQL Team".

Some of the decisions:

* file an issue about proper <audio> support.
* some TODOs recorded

=== 2011-12 (held on 2011-12-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt IRC log]

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))
* [[Feature Ideas]]: What should we do about the wiki page? Keep it and have it as a monthly topic for "what next"? Convert everything to long waiting bugs?
* Possibility of an [[SQL Database Backend]]?
*: 'executive summary' (well, you should read the long docs): "We could move to sql. It's probably replacing one type of pain by another type of pain, but those are somewhat comparable. Leaving the main question: Do we want to occupy our main devs for some long time with this task and loose momentum?"
* Schendje's [http://wiki.mediagoblin.org/Feature_Ideas/Activities activities proposal]
* "Coming up next" blogpost draft by Deb Nicholson
* Jef's requests:
** Ticket #466 "Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be". I'd really like to change this soon to something more suitable. How can we improve the wording here? Some alternatives have been mentioned in the bug report, but which one should we pick? Link: http://bugs.foocorp.net/issues/466
** The concept and naming of "favourites". We'll (hopefully) be able to "favourite" media soon, which I *think* means that 1) it'll work like a "I like this" comment, a quick token of appreciation, 2) it'll be added to your list of favourites so you can save and promote it, and 3) we could maybe use the number of favourites as a ranking. What I'd like to know is: is that the intended purpose? If so, should we name them favo(u)rites or something else? "Like", "love", "save", "appreciate", "heart", "high five" and many more could all be contenders. And the name should be consistent with the action and purpose, of course. So I'd like to clear up how and why we will use favourites and what we should call them.

=== 2011-11 (held on 2011-11-05) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

=== 2011-10 (held on 2011-10-01) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

=== 2011-09 (held on 2011-09-03) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

=== 2011-08 (held on 2011-08-06) ===

[http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

File Bugs

2012-01-31T02:51:04Z

Willkg: updating issue tracker url

MediaGoblin uses a bug tracker called Trac.

Our instance is located at http://issues.mediagoblin.org

The most useful bug reports have the following components:

* A short summary that’s 60 characters or less.
* A description that describes the issue (bug, feature request, ...) as well as the context. Consider:
** If you think you’ve found a bug, can you reproduce it in a controlled environment? Is the issue specific to a browser, computer, image, media type, or other dimension? All data helps.
** If you’re intending to submit a feature request, please take a look at [[Feature Ideas]] first. After that: Are there related links on the Internet for more information? Would you be willing to help implement or test the feature?

That’s it!

The better the issue report, the easier it is to address the bug, and the more likely that the developers will be able to resolve the issue. If someone has questions about the bug report, they may reach out to the reporter directly.

If you get a response after a couple of weeks, find someone on IRC.

Redmine migration

2012-01-31T02:50:00Z

Willkg: update redmine migration -- migration complete!

= Redmine Migration =

This page covers the impending migration of all our issue data from the Redmine instance at Foocorp to a Trac instance we manage.

This page is a work in progress. I started it so that it can be a one-stop-place for FAQ, schedule, and outstanding issues.

= Status =

January 30th, 2012: The migration is complete! Our new ticket tracker is at http://issues.mediagoblin.org/

= Outstanding issues =

None

= Solved issues =

== everything is comment 1 ==

Seems like all the comments are "comment 1".

* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Could be a problem with the code that's inserting into ticket_change.

'''Fix:''' Turns out in the ticket_change table, the oldvalue column for comments is the comment id number. Fixing the migration code fixed this issue, too.

== named links in comments are broken ==

Examples of broken named links:

* http://issues.mediagoblin.org/ticket/375#comment:1
* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Looks like there's an extra space in the link. If the data from redminelib is bad, then that'd cause the problem.

'''Fix:''' I had to shut off wordwrapping in html2text. Doing that prevents it from putting incorrect \n everywhere--sometimes in the middle of links.

== cc vs watching ==

Trac has cc section in tickets, but it takes email addresses. Redmine issues have user accounts. Thus in order to connect the two, I need people to create accounts and such.

However, this is a huge pain in the ass to populate after the fact. Is it ok if people re-cc: themselves to bugs they're interested in? If not, I'll spend the time to back-populate the data after the fact, but it'll probably take me a couple of weeks to get to.

'''Wontfix:''' People can re-cc themselves to tickets they need to be cc'd on. This is a one-time thing and there are only 100 or so tickets that are currently open. So while it's a pain in the ass, it's pretty limited.

== text formatting ==

Redmine data is in Markdown, but Trac uses its own wiki format. Currently, I'm just passing the text in which makes it look stupid.

'''Solution:''' Convert Redmine text data to reST and mark the text with the reST processor. http://trac.edgewall.org/wiki/WikiFormatting#Processors

'''Fix:''' That's what I implemented--works super.

== relations ==

Trac doesn't manage relationships between tickets: relates to, blocks, depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate, but doesn't let you specify the ticket that it duplicates. In Trac you do that in the comments when you mark the ticket as a duplicate. My migration script doesn't do anything with the relations information at the moment. I'm open to ideas on what to do here.

Nathan suggested just marking it in a comment on the Trac ticket. Is that good enough?

'''Fix:''' That's what I implemented. It links to the appropriate Trac tickets which is nice.

== accounts ==

I can't build accounts for people easily, so I think I'll need to create accounts in Trac and then associate the accounts with the data post-migration. I need to write a script to do the association, but this means there will be a period of time where things will be a little disrupted.

'''Fixed:''' I wrote a script that trivially allows me to connect new user accounts people create with all their existing bug data.

== issue numbers ==

Redmine issue numbers don't start with 1 because we're in a Redmine instance with other projects. However, when we move to Trac, tickets will start with 1. So there will be a mismatch between Redmine issue numbers and Trac tickets.

'''Fixed:''' I'm adding a comment to each Trac ticket that has a link to the original Redmine issue.

= Things to do after migration =

Here's the list of things we're thinking about doing after we finish the migration and we're using the new system:

* create backup scripts for data
* update the Trac front page to reflect MG stuff
* fix workflow to match MG workflow
* modify the reports
* change the style to match other sites we have

Anything else?

= FAQ =

== Why migrate? ==

Back in July 2011, we created http://bugs.foocorp.net/issues/418 we decided that we needed to manage our own issue tracker rather than use a hosted one. There are various reasons for this, but the biggest one is that we want to be in control of our infrastructure so that we can adapt it to our needs.

== Why Trac? ==

Redmine lacks a tagging system, though I think there are plugins that you can install that handle tagging.

Further, mediagoblin.org has infrastructure for Python web apps. I didn't feel like dealing with Python and Ruby web apps.

I'm more familiar with Trac and can augment it with Trac plugins going forward.

== Why 6 months to get this done? ==

I've spent the 6 months:

* trying to get Redmine installed and running
* giving up on that and looking at issue tracking systems
* fixing bugs in the TracAccountManager plugin
* figuring out how to set up Trac from source rather than the Debian Stable packages which are Trac 0.11
* figuring out how to map Redmine to Trac
* writing a bunch of software to do this:
** https://github.com/willkg/redminelib - redminelib is a scraping library for Redmine sites
** redminetodata - script that uses redminelib to download issue data and store it in JSON format
** datatotrac - script that loads data in JSON format, downloads attachments, converts it all to Trac tickets, and stores it in the db
** buildtrac.sh - script that sets up a Trac instance with TracAccountManager plugin on a Debian Stable system
** connectuser.py - script to connect new accounts with existing data because i couldn't do it initially

There were more obstacles than I expected and it just took a long time.

Redmine migration

2012-01-28T22:57:52Z

Willkg: updated outstanding issues

= Redmine Migration =

This page covers the impending migration of all our issue data from the Redmine instance at Foocorp to a Trac instance we manage.

This page is a work in progress. I started it so that it can be a one-stop-place for FAQ, schedule, and outstanding issues.

= Status =

January, 24th 2012: I've gotten the software working. I have Trac installed on http://issues.mediagoblin.org/ with a test migration.

'''Please test it out and let me know if you have any issues.'''

Currently working through outstanding issues on the devel mailing list. Once we're done with that, I'll:

# remove access to Redmine
# do a final migration
# update documentation and tell people about our new ticket system

= Outstanding issues =

None

= Solved issues =

== everything is comment 1 ==

Seems like all the comments are "comment 1".

* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Could be a problem with the code that's inserting into ticket_change.

'''Fix:''' Turns out in the ticket_change table, the oldvalue column for comments is the comment id number. Fixing the migration code fixed this issue, too.

== named links in comments are broken ==

Examples of broken named links:

* http://issues.mediagoblin.org/ticket/375#comment:1
* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Looks like there's an extra space in the link. If the data from redminelib is bad, then that'd cause the problem.

'''Fix:''' I had to shut off wordwrapping in html2text. Doing that prevents it from putting incorrect \n everywhere--sometimes in the middle of links.

== cc vs watching ==

Trac has cc section in tickets, but it takes email addresses. Redmine issues have user accounts. Thus in order to connect the two, I need people to create accounts and such.

However, this is a huge pain in the ass to populate after the fact. Is it ok if people re-cc: themselves to bugs they're interested in? If not, I'll spend the time to back-populate the data after the fact, but it'll probably take me a couple of weeks to get to.

'''Wontfix:''' People can re-cc themselves to tickets they need to be cc'd on. This is a one-time thing and there are only 100 or so tickets that are currently open. So while it's a pain in the ass, it's pretty limited.

== text formatting ==

Redmine data is in Markdown, but Trac uses its own wiki format. Currently, I'm just passing the text in which makes it look stupid.

'''Solution:''' Convert Redmine text data to reST and mark the text with the reST processor. http://trac.edgewall.org/wiki/WikiFormatting#Processors

'''Fix:''' That's what I implemented--works super.

== relations ==

Trac doesn't manage relationships between tickets: relates to, blocks, depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate, but doesn't let you specify the ticket that it duplicates. In Trac you do that in the comments when you mark the ticket as a duplicate. My migration script doesn't do anything with the relations information at the moment. I'm open to ideas on what to do here.

Nathan suggested just marking it in a comment on the Trac ticket. Is that good enough?

'''Fix:''' That's what I implemented. It links to the appropriate Trac tickets which is nice.

== accounts ==

I can't build accounts for people easily, so I think I'll need to create accounts in Trac and then associate the accounts with the data post-migration. I need to write a script to do the association, but this means there will be a period of time where things will be a little disrupted.

'''Fixed:''' I wrote a script that trivially allows me to connect new user accounts people create with all their existing bug data.

== issue numbers ==

Redmine issue numbers don't start with 1 because we're in a Redmine instance with other projects. However, when we move to Trac, tickets will start with 1. So there will be a mismatch between Redmine issue numbers and Trac tickets.

'''Fixed:''' I'm adding a comment to each Trac ticket that has a link to the original Redmine issue.

= Things to do after migration =

Here's the list of things we're thinking about doing after we finish the migration and we're using the new system:

* create backup scripts for data
* update the Trac front page to reflect MG stuff
* fix workflow to match MG workflow
* modify the reports
* change the style to match other sites we have

Anything else?

= FAQ =

== Why migrate? ==

Back in July 2011, we created http://bugs.foocorp.net/issues/418 we decided that we needed to manage our own issue tracker rather than use a hosted one. There are various reasons for this, but the biggest one is that we want to be in control of our infrastructure so that we can adapt it to our needs.

== Why Trac? ==

Redmine lacks a tagging system, though I think there are plugins that you can install that handle tagging.

Further, mediagoblin.org has infrastructure for Python web apps. I didn't feel like dealing with Python and Ruby web apps.

I'm more familiar with Trac and can augment it with Trac plugins going forward.

== Why 6 months to get this done? ==

I've spent the 6 months:

* trying to get Redmine installed and running
* giving up on that and looking at issue tracking systems
* fixing bugs in the TracAccountManager plugin
* figuring out how to set up Trac from source rather than the Debian Stable packages which are Trac 0.11
* figuring out how to map Redmine to Trac
* writing a bunch of software to do this:
** https://github.com/willkg/redminelib - redminelib is a scraping library for Redmine sites
** redminetodata - script that uses redminelib to download issue data and store it in JSON format
** datatotrac - script that loads data in JSON format, downloads attachments, converts it all to Trac tickets, and stores it in the db
** buildtrac.sh - script that sets up a Trac instance with TracAccountManager plugin on a Debian Stable system
** connectuser.py - script to connect new accounts with existing data because i couldn't do it initially

There were more obstacles than I expected and it just took a long time.

Redmine migration

2012-01-28T17:10:19Z

Willkg: adding problems chris found

= Redmine Migration =

This page covers the impending migration of all our issue data from the Redmine instance at Foocorp to a Trac instance we manage.

This page is a work in progress. I started it so that it can be a one-stop-place for FAQ, schedule, and outstanding issues.

= Status =

January, 24th 2012: I've gotten the software working. I have Trac installed on http://issues.mediagoblin.org/ with a test migration.

'''Please test it out and let me know if you have any issues.'''

Currently working through outstanding issues on the devel mailing list. Once we're done with that, I'll:

# remove access to Redmine
# do a final migration
# update documentation and tell people about our new ticket system

= Outstanding issues =

== named links in comments are broken ==

Examples of broken named links:

* http://issues.mediagoblin.org/ticket/375#comment:1
* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Looks like there's an extra space in the link. If the data from redminelib is bad, then that'd cause the problem.

== everything is comment 1 ==

Seems like all the comments are "comment 1".

* http://issues.mediagoblin.org/ticket/162
* http://issues.mediagoblin.org/ticket/138
* http://issues.mediagoblin.org/ticket/96

Could be a problem with the code that's inserting into ticket_change.

= Solved issues =

== cc vs watching ==

Trac has cc section in tickets, but it takes email addresses. Redmine issues have user accounts. Thus in order to connect the two, I need people to create accounts and such.

However, this is a huge pain in the ass to populate after the fact. Is it ok if people re-cc: themselves to bugs they're interested in? If not, I'll spend the time to back-populate the data after the fact, but it'll probably take me a couple of weeks to get to.

'''Wontfix:''' People can re-cc themselves to tickets they need to be cc'd on. This is a one-time thing and there are only 100 or so tickets that are currently open. So while it's a pain in the ass, it's pretty limited.

== text formatting ==

Redmine data is in Markdown, but Trac uses its own wiki format. Currently, I'm just passing the text in which makes it look stupid.

'''Solution:''' Convert Redmine text data to reST and mark the text with the reST processor. http://trac.edgewall.org/wiki/WikiFormatting#Processors

'''Fix:''' That's what I implemented--works super.

== relations ==

Trac doesn't manage relationships between tickets: relates to, blocks, depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate, but doesn't let you specify the ticket that it duplicates. In Trac you do that in the comments when you mark the ticket as a duplicate. My migration script doesn't do anything with the relations information at the moment. I'm open to ideas on what to do here.

Nathan suggested just marking it in a comment on the Trac ticket. Is that good enough?

'''Fix:''' That's what I implemented. It links to the appropriate Trac tickets which is nice.

== accounts ==

I can't build accounts for people easily, so I think I'll need to create accounts in Trac and then associate the accounts with the data post-migration. I need to write a script to do the association, but this means there will be a period of time where things will be a little disrupted.

'''Fixed:''' I wrote a script that trivially allows me to connect new user accounts people create with all their existing bug data.

== issue numbers ==

Redmine issue numbers don't start with 1 because we're in a Redmine instance with other projects. However, when we move to Trac, tickets will start with 1. So there will be a mismatch between Redmine issue numbers and Trac tickets.

'''Fixed:''' I'm adding a comment to each Trac ticket that has a link to the original Redmine issue.

= Things to do after migration =

Here's the list of things we're thinking about doing after we finish the migration and we're using the new system:

* create backup scripts for data
* update the Trac front page to reflect MG stuff
* fix workflow to match MG workflow
* modify the reports
* change the style to match other sites we have

Anything else?

= FAQ =

== Why migrate? ==

Back in July 2011, we created http://bugs.foocorp.net/issues/418 we decided that we needed to manage our own issue tracker rather than use a hosted one. There are various reasons for this, but the biggest one is that we want to be in control of our infrastructure so that we can adapt it to our needs.

== Why Trac? ==

Redmine lacks a tagging system, though I think there are plugins that you can install that handle tagging.

Further, mediagoblin.org has infrastructure for Python web apps. I didn't feel like dealing with Python and Ruby web apps.

I'm more familiar with Trac and can augment it with Trac plugins going forward.

== Why 6 months to get this done? ==

I've spent the 6 months:

* trying to get Redmine installed and running
* giving up on that and looking at issue tracking systems
* fixing bugs in the TracAccountManager plugin
* figuring out how to set up Trac from source rather than the Debian Stable packages which are Trac 0.11
* figuring out how to map Redmine to Trac
* writing a bunch of software to do this:
** https://github.com/willkg/redminelib - redminelib is a scraping library for Redmine sites
** redminetodata - script that uses redminelib to download issue data and store it in JSON format
** datatotrac - script that loads data in JSON format, downloads attachments, converts it all to Trac tickets, and stores it in the db
** buildtrac.sh - script that sets up a Trac instance with TracAccountManager plugin on a Debian Stable system
** connectuser.py - script to connect new accounts with existing data because i couldn't do it initially

There were more obstacles than I expected and it just took a long time.

Redmine migration

2012-01-28T01:17:26Z

Willkg: updated migration plan

= Redmine Migration =

This page covers the impending migration of all our issue data from the Redmine instance at Foocorp to a Trac instance we manage.

This page is a work in progress. I started it so that it can be a one-stop-place for FAQ, schedule, and outstanding issues.

= Status =

January, 24th 2012: I've gotten the software working. I have Trac installed on http://issues.mediagoblin.org/ with a test migration.

'''Please test it out and let me know if you have any issues.'''

Currently working through outstanding issues on the devel mailing list. Once we're done with that, I'll:

# remove access to Redmine
# do a final migration
# update documentation and tell people about our new ticket system

= Outstanding issues =

None

= Solved issues =

== cc vs watching ==

Trac has cc section in tickets, but it takes email addresses. Redmine issues have user accounts. Thus in order to connect the two, I need people to create accounts and such.

However, this is a huge pain in the ass to populate after the fact. Is it ok if people re-cc: themselves to bugs they're interested in? If not, I'll spend the time to back-populate the data after the fact, but it'll probably take me a couple of weeks to get to.

'''Wontfix:''' People can re-cc themselves to tickets they need to be cc'd on. This is a one-time thing and there are only 100 or so tickets that are currently open. So while it's a pain in the ass, it's pretty limited.

== text formatting ==

Redmine data is in Markdown, but Trac uses its own wiki format. Currently, I'm just passing the text in which makes it look stupid.

'''Solution:''' Convert Redmine text data to reST and mark the text with the reST processor. http://trac.edgewall.org/wiki/WikiFormatting#Processors

'''Fix:''' That's what I implemented--works super.

== relations ==

Trac doesn't manage relationships between tickets: relates to, blocks, depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate, but doesn't let you specify the ticket that it duplicates. In Trac you do that in the comments when you mark the ticket as a duplicate. My migration script doesn't do anything with the relations information at the moment. I'm open to ideas on what to do here.

Nathan suggested just marking it in a comment on the Trac ticket. Is that good enough?

'''Fix:''' That's what I implemented. It links to the appropriate Trac tickets which is nice.

== accounts ==

I can't build accounts for people easily, so I think I'll need to create accounts in Trac and then associate the accounts with the data post-migration. I need to write a script to do the association, but this means there will be a period of time where things will be a little disrupted.

'''Fixed:''' I wrote a script that trivially allows me to connect new user accounts people create with all their existing bug data.

== issue numbers ==

Redmine issue numbers don't start with 1 because we're in a Redmine instance with other projects. However, when we move to Trac, tickets will start with 1. So there will be a mismatch between Redmine issue numbers and Trac tickets.

'''Fixed:''' I'm adding a comment to each Trac ticket that has a link to the original Redmine issue.

= Things to do after migration =

Here's the list of things we're thinking about doing after we finish the migration and we're using the new system:

* create backup scripts for data
* update the Trac front page to reflect MG stuff
* fix workflow to match MG workflow
* modify the reports
* change the style to match other sites we have

Anything else?

= FAQ =

== Why migrate? ==

Back in July 2011, we created http://bugs.foocorp.net/issues/418 we decided that we needed to manage our own issue tracker rather than use a hosted one. There are various reasons for this, but the biggest one is that we want to be in control of our infrastructure so that we can adapt it to our needs.

== Why Trac? ==

Redmine lacks a tagging system, though I think there are plugins that you can install that handle tagging.

Further, mediagoblin.org has infrastructure for Python web apps. I didn't feel like dealing with Python and Ruby web apps.

I'm more familiar with Trac and can augment it with Trac plugins going forward.

== Why 6 months to get this done? ==

I've spent the 6 months:

* trying to get Redmine installed and running
* giving up on that and looking at issue tracking systems
* fixing bugs in the TracAccountManager plugin
* figuring out how to set up Trac from source rather than the Debian Stable packages which are Trac 0.11
* figuring out how to map Redmine to Trac
* writing a bunch of software to do this:
** https://github.com/willkg/redminelib - redminelib is a scraping library for Redmine sites
** redminetodata - script that uses redminelib to download issue data and store it in JSON format
** datatotrac - script that loads data in JSON format, downloads attachments, converts it all to Trac tickets, and stores it in the db
** buildtrac.sh - script that sets up a Trac instance with TracAccountManager plugin on a Debian Stable system
** connectuser.py - script to connect new accounts with existing data because i couldn't do it initially

There were more obstacles than I expected and it just took a long time.

Redmine migration

2012-01-27T01:50:51Z

Willkg: updated migration plan

= Redmine Migration =

This page covers the impending migration of all our issue data from the Redmine instance at Foocorp to a Trac instance we manage.

This page is a work in progress. I started it so that it can be a one-stop-place for FAQ, schedule, and outstanding issues.

= Status =

January, 24th 2012: I've gotten the software working. I have Trac installed on http://issues.mediagoblin.org/ with a test migration. Please look around and let me know if you have issues.

Currently working through outstanding issues on the devel mailing list. Once we're done with that, I'll:

# remove access to Redmine
# do a final migration
# update documentation and tell people about our new ticket system

= Outstanding issues =

== relations ==

Trac doesn't manage relationships between tickets: relates to, blocks, depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate, but doesn't let you specify the ticket that it duplicates. In Trac you do that in the comments when you mark the ticket as a duplicate. My migration script doesn't do anything with the relations information at the moment. I'm open to ideas on what to do here.

Nathan suggested just marking it in a comment on the Trac ticket. Is that good enough?

== cc vs watching ==

Trac has cc section in tickets, but it takes email addresses. Redmine issues have user accounts. Thus in order to connect the two, I need people to create accounts and such.

However, this is a huge pain in the ass to populate after the fact. Is it ok if people re-cc: themselves to bugs they're interested in? If not, I'll spend the time to back-populate the data after the fact, but it'll probably take me a couple of weeks to get to.

== text formatting ==

Redmine data is in Markdown, but Trac uses its own wiki format. Currently, I'm just passing the text in which makes it look stupid.

'''Solution:''' Convert Redmine text data to reST and mark the text with the reST processor. http://trac.edgewall.org/wiki/WikiFormatting#Processors

Code changes need to be made here.

= Solved issues =

== accounts ==

I can't build accounts for people easily, so I think I'll need to create accounts in Trac and then associate the accounts with the data post-migration. I need to write a script to do the association, but this means there will be a period of time where things will be a little disrupted.

'''Fixed:''' I wrote a script that trivially allows me to connect new user accounts people create with all their existing bug data.

== issue numbers ==

Redmine issue numbers don't start with 1 because we're in a Redmine instance with other projects. However, when we move to Trac, tickets will start with 1. So there will be a mismatch between Redmine issue numbers and Trac tickets.

'''Fixed:''' I'm adding a comment to each Trac ticket that has a link to the original Redmine issue.

= Things to do after migration =

Here's the list of things we're thinking about doing after we finish the migration and we're using the new system:

* create backup scripts for data
* update the Trac front page to reflect MG stuff
* fix workflow to match MG workflow
* modify the reports
* change the style to match other sites we have

Anything else?

= FAQ =

== Why migrate? ==

Back in July 2011, we created http://bugs.foocorp.net/issues/418 we decided that we needed to manage our own issue tracker rather than use a hosted one. There are various reasons for this, but the biggest one is that we want to be in control of our infrastructure so that we can adapt it to our needs.

== Why Trac? ==

Redmine lacks a tagging system, though I think there are plugins that you can install that handle tagging.

Further, mediagoblin.org has infrastructure for Python web apps. I didn't feel like dealing with Python and Ruby web apps.

I'm more familiar with Trac and can augment it with Trac plugins going forward.

== Why 6 months to get this done? ==

I've spent the 6 months:

* trying to get Redmine installed and running
* giving up on that and looking at issue tracking systems
* fixing bugs in the TracAccountManager plugin
* figuring out how to set up Trac from source rather than the Debian Stable packages which are Trac 0.11
* figuring out how to map Redmine to Trac
* writing a bunch of software to do this:
** https://github.com/willkg/redminelib - redminelib is a scraping library for Redmine sites
** redminetodata - script that uses redminelib to download issue data and store it in JSON format
** datatotrac - script that loads data in JSON format, downloads attachments, converts it all to Trac tickets, and stores it in the db
** buildtrac.sh - script that sets up a Trac instance with TracAccountManager plugin on a Debian Stable system
** connectuser.py - script to connect new accounts with existing data because i couldn't do it initially

There were more obstacles than I expected and it just took a long time.

Redmine migration

2012-01-24T16:46:24Z

Willkg: initial writeup

User:Aleksejrs/ideas/federation

2012-01-03T15:01:33Z

Willkg: Reverted edits by KaitlinDudley (talk) to last revision by Aleksejrs

It may be that things described here are described, and better described, at [[API]]. --[[User:Aleksejrs|Aleksejrs]] 15:44, 8 November 2011 (EST)

== Selective media copying ==

# UserA owns GMG ServerA.
# UserA goes to GMG ServerB and sees an image.
# UserA puts URL of the image into his ServerA.
# ServerA fetches the image from ServerB with all metadata, so it becomes available at ServerA.

* Access (both viewing and copying) to the image might require view/access rights.
* The result should (must at least if the source is non-public) be marked private by default.
* It should be possible for the result to have a visible reference to its source.
* ServerB may be notified of the copying, so that it can link to the result, if it chooses to (http://bugs.foocorp.net/issues/604).

=== Another use-case ===

# UserA has private ServerA at home (possibly not accessible from outside), and an account at remote ServerB.
# UserA stores media in ServerA (possibly uploading by copying to a directory), and has the option of uploading all or parts of it to his ServerB account.

== FidoNet-inspired group mirroring ==

Here is a StatusNet feature request that came to be after the discussion: http://status.net/open-source/issues/3407

# GMG has a concept of something like “groups” (as of this writing it probably does not yet). Imagine groups like in Identi.ca — see the link above.
# A group originates at ServerA, and is also at ServerB.
# When somebody at ServerA or ServerB posts a media into the group (or marks it as being in that group), it appears in the group at both ServerA and ServerB.

* A group may have a moderator.
* A server admin may refuse a media to be on his server (including: pre-moderation).
* ServerC may receive this group even from a server other than the one from where the group originates, or from where the file originates.
** Bad: that might create a moderatorless version of the group at a group of servers, or similar MITM attacks on the group, but that’s its decentralization, and it is optional.
** Bad: a complex network of servers can have broken links (or worse, recreate FidoNet politics!).
* To protect the group against broken links, servers may connect to each other as a ring, downloading only the files they don’t have (keeping information about where the file comes from, to be able to remove files/versions coming from a particular server?).

Processing

2011-12-19T15:30:09Z

Willkg: Reverted edits by LynnConrad (talk) to last revision by Cwebber

When you submit an image (or in the future, other media type), it might not be immediately processed, it might be passed somewhere else, get processed, then get moved up. Certainly though several things will happen after this point: a more thorough checking for whether the media submitted is of a valid type, thumbnail generation, possibly scaling down, conversion, or transcoding of your media, etc. The process in which all this happens is called "processing".

<pre>
,-------,
| |
| MEDIA |
| | ,--------,
'-------' _converted_\ | PUBLIC |
| / media / | STORE |
submit : '--------'
| : :
V : :
.------------. ,------------, :
| | | | V
| submission |------queues--------> | processing | ,-----------,
| view | for processing | | | |
'------------' '------------' | Gallery |
: ^ | |
: : '-----------'
' ,---------, '
\_save __\ | QUEUE | __ fetch _/
media / | STORE | media
'---------'
</pre>

= Celery =

Processing is set up so that it can possibly be handed over to another process and not happen immediately. Resizing an image might not seem like it would take too long, and perhaps it wouldn't, but keep in mind that MediaGoblin is being designed to in the future handle all sorts of media types, including video, audio, etc. If we waited for a video to finish transcoding before we submitted it, we might time out before the process finishes!

If you are using ./lazyserver.sh (which most developers are) this won't be the case; Celery is run in [http://ask.github.com/celery/configuration.html#celery-always-eager always eager mode], which means that the task will be run by the same task that started it.

However if you want to split off processing into a separate process, that option is available. See [[Celery]] and the [[HackingHowto]] for details.

= The general process =

'''Note: some of the description of what's happening here comes from the processing branch, which is not yet merged but should be merged in shortly.'''

First of all, your process will be passed off to the function in mediagoblin.process_media.process_media(). That function will receive the id of your MediaEntry for retreival, and will use that information to find out what media type this is and dispatch it further to the appropriate function (or rather, that's the future plan, for now it just passes it over to the image processor since we only support images ;)).

The file you submitted will be referenced in the MediaEntry['queued_media_file'] key in the usual filepath "list" type format. This file path is then passed to the queue_store system to retrieve the file. See [[Storage]] for more details on how the storage systems work.

While the file is being worked on... say converted to a smaller image files or transcoded to webm... we need a way to access that file locally. What if it's already on a local file store? There's no reason for us to create a new file for it then. But what if it's on a remote filestore? We should *conditionally* copy the file locally, but make it really easy for the processing code to not have to know what we did. The [[Storage#The_workbench|workbench]] helps here. It also gives a temporary place to save other files during conversion. A fresh workbench is made for every processing job by the Workbench Manager (see workbench.py), and when all is done here, the workbench is destroyed.

Anyway, at this point the media's processing code does whatever conversions it needs, saving temporary files to the workbench.

When files are converted over (including the thumbnail) they are saved into the public_store and recorded in the MediaEntry['media_files'] dictionary. The state of the MediaEntry is moved to 'processed' and everyone rejoices.

'''TL;DR:''' ''After you submit your media it gets stored in the queue_store, gets passed to processing (which may or may not run in a separate process via celery), gets passed to the appropriate processing function, and the processed media gets saved in the public_store.''

= Errors =

== Handled failures ==

Certain kinds of errors we want to expect and handle. For example, if a user managed to submit something they claimed was an image but it had a .txt extension, it would never hit processing, but if it was a text file named as .jpg, we wouldn't know until we tried opening it (and we don't bother until the processing stage.) This is an error, but a *handled* error. There might be other kinds of handled errors too... we might not support transcoding a certain kind of file, or we might not have the libraries installed to know how convert these.

These are handled errors, and it's good if we can raise and report them in a useful way. Because of this, we allow for raising errors during media processing methods that are derived from mediagoblin.process_media.errors.BaseProcessingFail. You shouldn't raise BaseProcessingFail directly, but instead a subclass of it. For example, if your user submitted a bad piece of media, you can:

<pre>
raise BadMediaFail()
</pre>

Then the processing will be aborted, the MediaEntry['state'] will be saved as 'failed'. In addition, since this is a special inherited-from-BaseProcessingFail type error, the python path to this error will be saved in MediaEntry['fail_error']. (We can then later recall the exception class that was raised previously via MediaEntry.get_fail_exception()). In addition, if you pass in any keyword arguments to the exception these will be stored in MediaEntry['fail_metadata'] so that later on we might be able to construct some extra information about what happened.

Lastly, failure exceptions inherited from BaseProcessingFail should provide a general_message class-level attribute. This should be a "lazy_pass_to_ugettext" wrapped string that explains the error in a way that users of a MediaGoblin site might understand.

There is actually some experimental and not-ideal-but-working support for this under the path /u/username/panel/ ... assuming you are the relevant user or are an admin, you'll be able to see what recent media entry submissions failed here and why.

== Unhandled failures ==

Exceptions that are raised that *don't* inherit from BaseProcessingFail are considered "unhandled". Your MediaEntry should still be correctly marked as 'failed', but the 'fail_error' field of the model won't be filled in, and neither can any fail_metadata be saved. Furthermore we can't provide a useful error to a user.

Nonetheless, unexpected errors do occur... some sort of IOError might happen that we don't anticipate or handle. Assuming you aren't running lazyserver (or otherwise with CELERY_ALWAYS_EAGER set to true and CELERY_PROPAGATE_ERRORS set to True) where unhandled failures will be propagated to your console, you may want to debug what went wrong at a later time. How to do this?

Fortunately here Celery helps us out. Your processing results will be recorded in "celery_taskmeta" and you can find the '_id' of your result by looking at MediaEntry['queued_task_id']. The exception that was raised should be stored here, so you should be able to use this for debugging purposes.

HackingHowto

2011-11-18T18:46:03Z

Willkg: fixed codebase-chapter ref

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at [http://docs.mediagoblin.org/codebase.html codebase chapter] where
we've started documenting how GNU MediaGoblin is built and how to add
new things.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use an
in-package checkout of virtualenv. This isn't the convenional way to
install virtualenv (normally you don't install virtualenv inside the
package itself) but we've found that it's significantly easier for
newcomers who aren't already familiar with virtualenv. If you *are*
already familiar with virtualenv, feel free to just install
mediagoblin in your own virtualenv setup... the necessary adjustments
should be obvious.

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* MongoDB - http://www.mongodb.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/
* virtualenv - http://www.virtualenv.org/

Note, MongoDB can get to be pretty huge. You might want to consider
looking at [[Scaling Down]] if you are installing this on a smallish
instance.

=== GNU/Linux ===

==== Debian and derivatives ====

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install mongodb git-core python python-dev python-lxml python-imaging python-virtualenv}}

==== Fedora / RedHat(?) ====

On Fedora:

{{Cmd|yum install mongodb-server python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging python-virtualenv}}

=== Mac OS X ===

On Mac OS X Lion:

Download the Newest Python.

Git is already installed.

Install MongoDB from these instructions: http://www.mongodb.org/display/DOCS/Quickstart+OS+X

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html Combo Installer

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions, Windows, or Mac OS X to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with virtualenv ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

# Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
# Set up the in-package virtualenv: {{Cmd|virtualenv . && ./bin/python setup.py develop}}

That's it!

(If you have troubles in the remaining steps, consider try installing
virtualenv with one of the flags --setuptools, --distribute or possibly --no-site-packages. Additionally, if your system has python3.X as the default, you might need to do virtualenv --python=python2.7 or --python=python2.6)

If you have problems, please [http://mediagoblin.org/join/ let us know]!

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/python setup.py develop --upgrade && ./bin/gmg migrate}}.

'''Updating for code changes'''

You don't need to do anything---code changes are automatically
available as long as you're doing a git pull or etc.

== Running Mongo Database ==

Startup the Database if you haven't already. On most systems, this
should be started automatically. If not, consult the documentation
for your distribution or the MongoDB docs themselves.

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}.

This will start up a python server where you can begin playing with
mediagoblin. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

By default, the instance is not sending out confirmation mails. Instead they are redirected to the standard output (the console) of lazyserver.sh.

You can change this behavior setting <code>email_debug_mode</code> to <code>false</code> in mediagoblin.ini

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

=== pymongo.errors.AutoReconnect: could not find master/primary ===

If you see this:

pymongo.errors.AutoReconnect: could not find master/primary

then make sure mongodb is installed and running.

If it's installed, check the mongodb log. On my machine, that's
<tt>/var/log/mongodb/mongodb.log</tt>. If you see something like:

old lock file: /var/lib/mongodb/mongod.lock. probably means...

in that case you might have had an unclean shutdown. Try:

{{Cmd|sudo mongod --repair}}

If that didn't work, just delete the lock file and relaunch mongodb.

Anyway, then start the mongodb server in whatever way is appropriate
for your distro / OS.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|gmg wipealldata}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has mongokit ORM definitions
* <tt>views.py</tt> is where the views go

We're using MongoDB. Basically, instead of a relational database with
tables, you have a big JSON structure which acts a lot like a Python
dict.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

Now you should visit our latest list of [http://bugs.foocorp.net/projects/mediagoblin/issues?query_id=3 bite-sized issues] because squishing bugs is messy fun. If you're interested in other things to work on, or need help getting started on a bug, let us know on [http://mediagoblin.org/join/ the mailing list] or on the [http://mediagoblin.org/join/ IRC channel].

Meeting

2011-11-10T13:54:04Z

Willkg: adding section for next meeting; adding plugin system topic

= MediaGoblin Monthly Meeting =

At 16:00 UTC the first saturday of each month, unless otherwise announced on the [http://lists.mediagoblin.org/pipermail/devel/ mailing list], there is an IRC meeting. The idea is to discuss the past month, what happened, what was good, what should be done better. And to create roadmap for the upcoming month and assign tasks to people willing to handle them.

* [http://mediagoblin.org/irclogs/ IRC meeting logs]

= Upcoming and Recent Meetings =

== 2011-12 (upcoming 2011-12-03) ==

Preliminary Agenda (in progress):

* We plan to create a plugin system. Do we want to create that soon or push it off until things settle a bit more? ([[User:Willkg|Willkg]] 08:54, 10 November 2011 (EST))

== 2011-11 (held on 2011-11-05) ==

Preliminary Agenda and preliminary results (in progress):
* What happened in the last month, what was good, what could be better next time?
** Release:
*** Good: 0.1.0 released!
*** Bad: postponing vs not postponing
** Sites and deployment documentation:
*** Good: new mediagoblin.org
*** Good: deployment documentation
*** Bad: py-bcrypt’s site was down just after the release, so the virtualenv deployment didn’t work, and it wasn’t clear how to fix it.
** Live instances:
*** Joar has a live instance!
*** But what does it mean? Should ordinary users start using it?
**** Details at [[User:Joar/mg.wandborg.se]] -- [[User:Joar|Joar]] 17:01, 6 November 2011 (EST)
*** nyergler added a note about "heartbeat"/status to API notes
* What should be done next month?
* Starting real work on federation (via OStatus)... and do we split any of this work out into its own library?
* An API
* Creative Commons licensing tools
* Merging in the multimedia/video branch
*: (this is *very close* already actually thanks to the hard work of Joar Wandborg! But we need some help on the gstreamer front to fix a few issues... if you or someone you know is an expert in this area we could really use their help to make the videos that come out smoother!)
* Rollover items from 0.1.0
* Possibility of an [[SQL Database Backend]]?
* Multiple file upload interface
* Drag and drop uploads interface (probably related!)

[http://mediagoblin.org/irclogs/irc_meeting_2011-11-05.txt IRC log]

== 2011-10 (held on 2011-10-01) ==
This month's meeting was a quickly announced short meeting. The project is getting back on track and next month's meeting will be scheduled more properly. A bunch of people were around.

The most important decisions:
* The project will keep monthly releases. They're the heartbeat of the project.
* Release 0.1.0 this sunday/monday.
* New website will hopefully be deployed in the next few days.
* And the following things are planned to happen during this month: Most importantly federation. The developers have decided to make up their minds on what federation aactually should mean for MediaGoblin. Concerning code, probably "activity streams" are the first goal. If there is no (good) python library for this, a new stand alone library may be created. If so, a name for it has to be found. It should have something about communication in it. And the other thing to happen during this month is an ongoing discussion about "bus factor".

* [http://mediagoblin.org/irclogs/irc_meeting_2011-10-01.txt IRC log]

== 2011-09 (held on 2011-09-03) ==

* [http://mediagoblin.org/irclogs/irc_meeting_2011-09-03.txt IRC log]

== 2011-08 (held on 2011-08-06) ==

* [http://mediagoblin.org/irclogs/irc_meeting_2011-08-06.txt IRC log]

Main Page

2011-09-04T13:31:31Z

Willkg: overhaul of the front page to be more contributor-oriented per previous conversations

= Want to Join the MediaGoblin Community? =

We’re really glad that you want to join the MediaGoblin community!

There are a variety of ways to help and support MediaGoblin and to join the team. If you want to code, great, if not, even better! MediaGoblin interested contributors in many different roles: users, system administrators, technical writers, testers, evangelists, UI/UX and graphics designers, cheerleaders, and dreamers.

This wiki covers a variety of ways that you can get involved with MediaGoblin as well as instructions on how to get started.

== Hang out with the MediaGoblin folk ==

MediaGoblin has a mailing list and an IRC channel where we hang out. See [http://mediagoblin.org/join/ our join page] for links.

Please drop by and say “Hi!” And, if you’re looking for something to do, just ask---there’s always work to be done.

== File Bugs / Triage Bugs ==

Issue reports are critical for all projects. Identified bugs give developers a basis for beginning work, and providing an idea of what features and issues are most important to users and the overall usability of the software. If you identify errors, flaws, unexpected behaviors, or deficits that impede use, file a bug.

* [[File Bugs]] -- notes on filing new bugs/issues/feature requests
* [[Triage Bugs]] -- notes on triaging

== Write Code / Fix Code ==

If you are a coder and you would like to write code, the repository is hosted on gitorious. Clone or fork the repository and start poking around. Become familiar with this manual for an overview of how the software works and is used. Consider the contributor wiki for more information about the project, our preferred methods, and guides for developing MediaGoblin. We even have tips on becoming a coder and we’re willing to help!

* [[Development quick start]] - get MediaGoblin running on your own machine so you can hack on it
* [[HackingHowto|Hacking]] - notes on making and sending in code contributions
** [[BeginnersCorner|Beginner's Corner]] - resources for those who are new to Python, MongoDB, or Git.
** We'll be adding some distribution/OS specific hacking guides as separate pages soon.
* [[Git workflow]] - How to go about submitting patches via git.
* [[Templating]] - How our templating structure is set up

== Send Encouragement / Spread the Word ==

Sometimes, a nice word, simple encouragement, and interest in the work we’re doing is enough to inspire a tizzy of productive work. Just a bit more interest and encouragement can even make the difference between a complete feature and limited functionality; between a completed milestone and lost momentum.

Similarly, MediaGoblin, and the movement for free network services, is always in need of encouragement. Use free network services, understand the principals behind the movement, be able to articulate the benefits of free network services and the problems with psudo-free applications that don’t respect the users’ freedom.

Write a blog post, post a status update, drop by the listserv or join #mediagoblin on freenode.net and let us know. See [http://mediagoblin.org/join/ our join page] for links.

== Write Documentation / Edit Documentation ==

* [[Documentation quick start]] - How to contribute to the documentation effort.
* [[ManualStandards]] - covers the standards for writing the user manual (forthcoming.)

== Test MediaGoblin ==

* [[UnitTests|Unit Tests]] - all about the unit tests
* [[User Experience]] - user experience testing. Includes link to an instance you can try!

== Translate MediaGoblin ==

If you know English and another language and feel comfortable translating elements of the interface or even the documentation, we’d love to have help translating the software and resources.

* [[Translations]] - How to translate stuff or update the translations

== Become a User ==

Coming soon!

We’re building MediaGoblin for us and for you but really you’re one of us and I am you and we are we and MediaGoblin is the walrus.

We're planning to launch our own public instance of MediaGoblin in the near future--probably in the September/October 2011 time frame. When we do, sign up for an account, use the service and relish in the thought that this service comes with a heaping side of Freedom and you can salt and pepper it to your liking.

== Help Others ==

Have you spent time with MediaGoblin? If so, your experience and wisdom are invaluable and you’re the best person we can think of to help other users with their questions.

Hang out on the IRC channel and help answer new peoples' questions. See [http://mediagoblin.org/join/ our join page] for links.

== Run your own MediaGoblin Instance ==

Are there things about our instance you want to change? Are there things about other instances you wish were different? Want to test upcoming changes? Want to create patches to implement things you need? That’s great—you can run your own instance!

* [[Configure_MediaGoblin|Configuration]] - Learn about MediaGoblin configuration files and file options.
* [[Deployment]] - General deployment advice
* [[Scaling Down]] - Minimizing MediaGoblin's resource requirements
* [[Virtual Machine Hosting]] - Deploy your own publicly available MediaGoblin server using [http://aws.amazon.com/free/?utm_source=adwords&utm_medium=cpc&utm_campaign=CPC_Google_AWS_ec2&utm_content=TextV01_PP_V01_EC2&trk=CPC_Google_AWS_ec2 Amazon's free EC2 tier].

== Create a Theme ==

Coming soon!

MedaGoblin development is premised on the idea that the entire interface for the platform be completely theme-able. If you have a design or theming background, consider developing themes for MediaGoblin. New themes help test the theming system, provide attractive and appealing interfaces for prospective users. If you want to start a new theme but don’t know where to start, touch base with the development community on the list or in the IRC channel for more information.

= Technical project documentation =

* [[DesignDecisions]] - covers design decisions (FIXME - this needs to be split up)
* [[Storage]] - How MediaGoblin's internal storage system works.
* [[Processing]] - What happens after you submit your image/video/etc? Processing! More about that.
* [https://gitorious.org/mediagoblin/mediagoblin/blobs/master/extlib/README External Library Policy] - covers use of external libraries
* [[User:Cwebber/braindumps]] - Chris Webber's braindumps (you can help refactoring these into real sections of the site!)

= Inner workings of the secret sanctum =

* [http://mediagoblin.org/irclogs/ IRC meeting logs]
* [[IRCBot]] - covers our irc bot
* [[ReleaseProcess|Release Process]] - covers the release process
* [[Update the website]] - Learn how to update mediagoblin.org!

Triage Bugs

2011-09-04T13:19:27Z

Willkg: initial triage bugs page

The triage process involves reviewing bugs, removing duplicates, validating that the issues described are reproducible, ensuring that the exact behavior is properly documented, diagnosing the cause of each issue, and working with developers to ensure that critical bugs get addressed. In many cases, developers do this kind of work as a matter of course, but one need not be able to code in order to help working with bugs.

To triage bugs, go to the bug tracker and begin reviewing the open issues. If you are able, attempt to:

* ensure that one or two people in addition to the initial reporter have been able to reproduce the issue.
* document the issue more clearly. If you had any trouble reproducing the issue, provide any elucidating information that you can to help others solve the problem more effectively.
* find a way to resolve the problem or provide a workaround.

For help, instructions, and suggestions be in touch with the development community on the list or in the IRC channel for more information. With many eyes, all bugs are shallow.

Filing Bugs

2011-09-04T13:18:28Z

Willkg: moved Filing Bugs to File Bugs

#REDIRECT [[File Bugs]]

File Bugs

2011-09-04T13:18:28Z

Willkg: moved Filing Bugs to File Bugs

MediaGoblin uses a bug tracker called Redmine.

Our instance is located at http://bugs.foocorp.net/projects/mediagoblin

The most useful bug reports have the following components:

* A short summary that’s 60 characters or less.
* A description that describes the issue (bug, feature request, ...) as well as the context. Consider:
** If you think you’ve found a bug, can you reproduce it in a controlled environment? Is the issue specific to a browser, computer, image, media type, or other dimension? All data helps.
** If you’re submitting a feature request, are there related links on the Internet for more information? Would you be willing to help implement or test the feature?

That’s it!

The better the issue report, the easier it is to address the bug, and the more likely that the developers will be able to resolve the issue. If someone has questions about the bug report, they may reach out to the reporter directly.

If you get a response after a couple of weeks, find someone on IRC.

File Bugs

2011-09-04T13:17:52Z

Willkg: moving bug filing material to a separate page

Template:Needswork

2011-08-19T19:30:18Z

Willkg: fixing a missing noinclude

<div style="border: thin solid black; background: yellow; margin: 2em; padding: 1em">
'''Note:''' This page is marked for rewriting. We know it could be better! If you get confused, please ask for help on [http://mediagoblin.org/join/ IRC].
</div>
<noinclude>
== Usage ==
Put this template at the top of the page for pages that need to be overhauled.

<pre>
{{{Needswork}}}
</pre>
</noinclude>

HackingHowto

2011-08-19T19:03:00Z

Willkg: marking this page as needing work

{{Needswork}}

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at :ref:`codebase-chapter` where
we've started documenting how GNU MediaGoblin is built and how to add
new things.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use buildout,
but if you want to use virtualenv, there's a set of mediocre not-very-supported
steps in the [https://gitorious.org/mediagoblin/pages/Home evil wiki].

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* MongoDB - http://www.mongodb.org/
* Python Imaging Library (PIL) - http://www.pythonware.com/products/pil/

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install mongodb git-core python python-dev python-lxml python-imaging}}

On Fedora:

{{Cmd|yum install mongodb-server python-paste-deploy python-paste-script git-core python python-devel python-lxml python-imaging}}

----

On Mac OS X Lion:

Download the Newest Python.

Git is already installed.

Install MongoDB from these instructions: http://www.mongodb.org/display/DOCS/Quickstart+OS+X

Python-lxml: http://muffinresearch.co.uk/archives/2009/03/05/install-lxml-on-osx/ with sudo

Python Imaging Library (PIL): http://code.google.com/appengine/docs/python/images/installingPIL.html#mac

Libjpeg & Libpng: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html Combo Installer

----

'''You can help:'''

If you have instructions for other GNU/Linux distributions or Mac OS X to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with buildout ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

# Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
# Bootstrap and run buildout: {{Cmd|cd mediagoblin}} and then one of the following:
#* {{Cmd|python bootstrap.py && ./bin/buildout}}, '''OR'''
#* {{Cmd|python bootstrap.py --distribute && ./bin/buildout}}

Why would you want one over the other? If the first doesn't work, then try the second.

That's it! Using this method, buildout should create a <tt>user_dev</tt>
directory, in which certain things will be stored (media, beaker
session stuff, etc). You can change this, but for development
purposes this default should be fine.

If you have problems, please [http://mediagoblin.org/join/ let us know]!

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/buildout && ./bin/gmg migrate}}.

'''Updating for code changes'''

You don't need to do anything---code changes are automatically available.

'''Deleting your buildout'''

At some point, you may want to delete your buildout. Perhaps it's to
start over. Perhaps it's to test building development environments
with buildout.

To do this, run:

{{Cmd|rm -rf bin develop-eggs eggs mediagoblin.egg-info parts user_dev}}.

== Running Mongo Database ==

Startup the Database: {{Cmd|./mongodb-xxxxxxx/bin/mongod}}.

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}.

This will start up a python server where you can begin playing with
mediagoblin. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}.

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

=== pymongo.errors.AutoReconnect: could not find master/primary ===

If you see this:

pymongo.errors.AutoReconnect: could not find master/primary

then make sure mongodb is installed and running.

If it's installed, check the mongodb log. On my machine, that's
<tt>/var/log/mongodb/mongodb.log</tt>. If you see something like:

old lock file: /var/lib/mongodb/mongod.lock. probably means...

in that case you might have had an unclean shutdown. Try:

{{Cmd|sudo mongod --repair}}

If that didn't work, just delete the lock file and relaunch mongodb.

Anyway, then start the mongodb server in whatever way is appropriate
for your distro / OS.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|gmg wipealldata}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has mongokit ORM definitions
* <tt>views.py</tt> is where the views go

We're using MongoDB. Basically, instead of a relational database with
tables, you have a big JSON structure which acts a lot like a Python
dict.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

'''May 3rd, 2011''': We don't have a list of bite-sized bugs, yet, but
this is important to us. If you're interested in things to work on,
let us know on [http://mediagoblin.org/join/ the mailing list] or
on the [http://mediagoblin.org/join/ IRC channel].

== Tips for people new to coding ==

=== Learning Python ===

GNU MediaGoblin is written using a programming language called [http://python.org/ Python].

There are two different incompatible iterations of Python which I'll
refer to as Python 2 and Python 3. GNU MediaGoblin is written in
Python 2 and requires Python 2.6 or 2.7. At some point, we might
switch to Python 3, but that's a future thing.

You can learn how to code in Python 2 from several excellent books
that are freely available on the Internet:

* [http://learnpythonthehardway.org/ Learn Python the Hard Way]
* [http://diveintopython.org/ Dive Into Python]
* [http://www.greenteapress.com/thinkpython/ Python for Software Design]
* [http://www.swaroopch.com/notes/Python A Byte of Python]

These are all excellent texts.

'''You Can Help'''

If you know of other good quality Python tutorials and Python
tutorial videos, let us know!

=== Learning Libraries GNU MediaGoblin uses ===

GNU MediaGoblin uses a variety of libraries in order to do what it
does. These libraries are listed in the :ref:`codebase-chapter`
along with links to the project Web sites and documentation for the
libraries.

There are a variety of Python-related conferences every year that have
sessions covering many aspects of these libraries. You can find them
at [http://python.mirocommunity.org Python Miro Community] -- This is a shameless plug; Will Kahn-Greene runs Python Miro Community.

If you have questions or need help, [http://mediagoblin.org/join/ let us know]!

=== Learning git ===

git is an interesting and very powerful tool. Like all powerful
tools, it has a learning curve.

If you're new to git, we highly recommend the following resources for
getting the hang of it:

* [http://learn.github.com/p/intro.html Learn Git] --- the GitHub intro to git
* [http://progit.org/book/ Pro Git] --- fantastic book
* [http://gitcasts.com/ Git casts] --- screencast covering git usage
* [http://gitref.org/ Git Reference] --- Git reference that makes it easier to get the hang of git if you're coming from other version control systems

There's also a git mission at [http://openhatch.org/ OpenHatch].

=== Learning other utilities ===

The [http://openhatch.org/ OpenHatch] site has a series of
[http://openhatch.org/missions/ training missions] which are
designed to help you learn how to use these tools.

If you're new to tar, diff, patch and git, we highly recommend you sign
up with OpenHatch and do the missions.

Template:Needswork

2011-08-19T19:01:50Z

Willkg: creating needswork template

<div style="border: thin solid black; background: yellow; margin: 2em; padding: 1em">
'''Note:''' This page is marked for rewriting. We know it could be better! If you get confused, please ask for help on [http://mediagoblin.org/join/ IRC].
</div>
== Usage ==
Put this template at the top of the page for pages that need to be overhauled.

<pre>
{{{Needswork}}}
</pre>
</noinclude>

HackingHowto

2011-08-14T00:21:13Z

Willkg: redid all commands to use cmd template

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at :ref:`codebase-chapter` where
we've started documenting how GNU MediaGoblin is built and how to add
new things.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use buildout,
but if you want to use virtualenv, there's a set of mediocre not-very-supported
steps in the [https://gitorious.org/mediagoblin/pages/Home evil wiki].

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* MongoDB - http://www.mongodb.org/

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

{{Cmd|sudo apt-get install mongodb git-core python python-dev python-lxml python-imaging}}

On Fedora:

{{Cmd|yum install mongodb-server python-paste-deploy python-paste-script git-core python python-devel python-lxml}}

'''You can help:'''

If you have instructions for other GNU/Linux distributions to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with buildout ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

# Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
# Bootstrap and run buildout: {{Cmd|cd mediagoblin}} and then one of the following:
#* {{Cmd|python bootstrap.py && ./bin/buildout}}, '''OR'''
#* {{Cmd|python bootstrap.py --distribute && ./bin/buildout}}

Why would you want one over the other? If the first doesn't work, then try the second.

That's it! Using this method, buildout should create a <tt>user_dev</tt>
directory, in which certain things will be stored (media, beaker
session stuff, etc). You can change this, but for development
purposes this default should be fine.

If you have problems, please [http://mediagoblin.org/join/ let us know]!

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed.

To do that, run:

{{Cmd|./bin/buildout && ./bin/gmg migrate}}.

'''Updating for code changes'''

You don't need to do anything---code changes are automatically available.

'''Deleting your buildout'''

At some point, you may want to delete your buildout. Perhaps it's to
start over. Perhaps it's to test building development environments
with buildout.

To do this, run:

{{Cmd|rm -rf bin develop-eggs eggs mediagoblin.egg-info parts user_dev}}.

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

{{Cmd|./lazyserver.sh}}.

This will start up a python server where you can begin playing with
mediagoblin. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

{{Cmd|./bin/paster serve paste.ini --reload}}

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

{{Cmd|<nowiki>CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd</nowiki>}}.

== Running the test suite ==

Run:

{{Cmd|./runtests.sh}}

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

{{Cmd|./bin/gmg shell}}

== Troubleshooting ==

=== pymongo.errors.AutoReconnect: could not find master/primary ===

If you see this:

pymongo.errors.AutoReconnect: could not find master/primary

then make sure mongodb is installed and running.

If it's installed, check the mongodb log. On my machine, that's
<tt>/var/log/mongodb/mongodb.log</tt>. If you see something like:

old lock file: /var/lib/mongodb/mongod.lock. probably means...

in that case you might have had an unclean shutdown. Try:

{{Cmd|sudo mongod --repair}}

If that didn't work, just delete the lock file and relaunch mongodb.

Anyway, then start the mongodb server in whatever way is appropriate
for your distro / OS.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

{{Cmd|gmg wipealldata}}

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has mongokit ORM definitions
* <tt>views.py</tt> is where the views go

We're using MongoDB. Basically, instead of a relational database with
tables, you have a big JSON structure which acts a lot like a Python
dict.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

'''May 3rd, 2011''': We don't have a list of bite-sized bugs, yet, but
this is important to us. If you're interested in things to work on,
let us know on [http://mediagoblin.org/join/ the mailing list] or
on the [http://mediagoblin.org/join/ IRC channel].

== Tips for people new to coding ==

=== Learning Python ===

GNU MediaGoblin is written using a programming language called [http://python.org/ Python].

There are two different incompatible iterations of Python which I'll
refer to as Python 2 and Python 3. GNU MediaGoblin is written in
Python 2 and requires Python 2.6 or 2.7. At some point, we might
switch to Python 3, but that's a future thing.

You can learn how to code in Python 2 from several excellent books
that are freely available on the Internet:

* [http://learnpythonthehardway.org/ Learn Python the Hard Way]
* [http://diveintopython.org/ Dive Into Python]
* [http://www.greenteapress.com/thinkpython/ Python for Software Design]
* [http://www.swaroopch.com/notes/Python A Byte of Python]

These are all excellent texts.

'''You Can Help'''

If you know of other good quality Python tutorials and Python
tutorial videos, let us know!

=== Learning Libraries GNU MediaGoblin uses ===

GNU MediaGoblin uses a variety of libraries in order to do what it
does. These libraries are listed in the :ref:`codebase-chapter`
along with links to the project Web sites and documentation for the
libraries.

There are a variety of Python-related conferences every year that have
sessions covering many aspects of these libraries. You can find them
at [http://python.mirocommunity.org Python Miro Community] -- This is a shameless plug; Will Kahn-Greene runs Python Miro Community.

If you have questions or need help, [http://mediagoblin.org/join/ let us know]!

=== Learning git ===

git is an interesting and very powerful tool. Like all powerful
tools, it has a learning curve.

If you're new to git, we highly recommend the following resources for
getting the hang of it:

* [http://learn.github.com/p/intro.html Learn Git] --- the GitHub intro to git
* [http://progit.org/book/ Pro Git] --- fantastic book
* [http://gitcasts.com/ Git casts] --- screencast covering git usage
* [http://gitref.org/ Git Reference] --- Git reference that makes it easier to get the hang of git if you're coming from other version control systems

There's also a git mission at [http://openhatch.org/ OpenHatch].

=== Learning other utilities ===

The [http://openhatch.org/ OpenHatch] site has a series of
[http://openhatch.org/missions/ training missions] which are
designed to help you learn how to use these tools.

If you're new to tar, diff, patch and git, we highly recommend you sign
up with OpenHatch and do the missions.

HackingHowto

2011-08-14T00:07:29Z

Willkg: fixing the git:// link so it's not a link

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at :ref:`codebase-chapter` where
we've started documenting how GNU MediaGoblin is built and how to add
new things.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use buildout,
but if you want to use virtualenv, there's a set of mediocre not-very-supported
steps in the [https://gitorious.org/mediagoblin/pages/Home evil wiki].

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* MongoDB - http://www.mongodb.org/

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

sudo apt-get install mongodb git-core python python-dev \
python-lxml python-imaging

On Fedora:

yum install mongodb-server python-paste-deploy python-paste-script \
git-core python python-devel python-lxml

'''You can help:'''

If you have instructions for other GNU/Linux distributions to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with buildout ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

# Clone the repository: {{Cmd|git clone <nowiki>git://gitorious.org/mediagoblin/mediagoblin.git</nowiki>}}
# Bootstrap and run buildout: <tt>cd mediagoblin</tt> and then one of the following:
#* <tt>python bootstrap.py && ./bin/buildout</tt>, '''OR'''
#* <tt>python bootstrap.py --distribute && ./bin/buildout</tt>

Why would you want one over the other? If the first doesn't work, then try the second.

That's it! Using this method, buildout should create a <tt>user_dev</tt>
directory, in which certain things will be stored (media, beaker
session stuff, etc). You can change this, but for development
purposes this default should be fine.

If you have problems, please [http://mediagoblin.org/join/ let us know]!

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed. To do that, run:

./bin/buildout && ./bin/gmg migrate

'''Updating for code changes'''

You don't need to do anything---code changes are automatically available.

'''Deleting your buildout'''

At some point, you may want to delete your buildout. Perhaps it's to
start over. Perhaps it's to test building development environments
with buildout.

To do this, do:

rm -rf bin develop-eggs eggs mediagoblin.egg-info parts user_dev

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

./lazyserver.sh

This will start up a python server where you can begin playing with
mediagoblin. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

./bin/paster serve paste.ini --reload

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd

== Running the test suite ==

Run:

./runtests.sh

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

./bin/gmg shell

== Troubleshooting ==

=== pymongo.errors.AutoReconnect: could not find master/primary ===

If you see this:

pymongo.errors.AutoReconnect: could not find master/primary

then make sure mongodb is installed and running.

If it's installed, check the mongodb log. On my machine, that's
<tt>/var/log/mongodb/mongodb.log</tt>. If you see something like:

old lock file: /var/lib/mongodb/mongod.lock. probably means...

in that case you might have had an unclean shutdown. Try:

sudo mongod --repair

If that didn't work, just delete the lock file and relaunch mongodb.

Anyway, then start the mongodb server in whatever way is appropriate
for your distro / OS.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

gmg wipealldata

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has mongokit ORM definitions
* <tt>views.py</tt> is where the views go

We're using MongoDB. Basically, instead of a relational database with
tables, you have a big JSON structure which acts a lot like a Python
dict.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

'''May 3rd, 2011''': We don't have a list of bite-sized bugs, yet, but
this is important to us. If you're interested in things to work on,
let us know on [http://mediagoblin.org/join/ the mailing list] or
on the [http://mediagoblin.org/join/ IRC channel].

== Tips for people new to coding ==

=== Learning Python ===

GNU MediaGoblin is written using a programming language called [http://python.org/ Python].

There are two different incompatible iterations of Python which I'll
refer to as Python 2 and Python 3. GNU MediaGoblin is written in
Python 2 and requires Python 2.6 or 2.7. At some point, we might
switch to Python 3, but that's a future thing.

You can learn how to code in Python 2 from several excellent books
that are freely available on the Internet:

* [http://learnpythonthehardway.org/ Learn Python the Hard Way]
* [http://diveintopython.org/ Dive Into Python]
* [http://www.greenteapress.com/thinkpython/ Python for Software Design]
* [http://www.swaroopch.com/notes/Python A Byte of Python]

These are all excellent texts.

'''You Can Help'''

If you know of other good quality Python tutorials and Python
tutorial videos, let us know!

=== Learning Libraries GNU MediaGoblin uses ===

GNU MediaGoblin uses a variety of libraries in order to do what it
does. These libraries are listed in the :ref:`codebase-chapter`
along with links to the project Web sites and documentation for the
libraries.

There are a variety of Python-related conferences every year that have
sessions covering many aspects of these libraries. You can find them
at [http://python.mirocommunity.org Python Miro Community] -- This is a shameless plug; Will Kahn-Greene runs Python Miro Community.

If you have questions or need help, [http://mediagoblin.org/join/ let us know]!

=== Learning git ===

git is an interesting and very powerful tool. Like all powerful
tools, it has a learning curve.

If you're new to git, we highly recommend the following resources for
getting the hang of it:

* [http://learn.github.com/p/intro.html Learn Git] --- the GitHub intro to git
* [http://progit.org/book/ Pro Git] --- fantastic book
* [http://gitcasts.com/ Git casts] --- screencast covering git usage
* [http://gitref.org/ Git Reference] --- Git reference that makes it easier to get the hang of git if you're coming from other version control systems

There's also a git mission at [http://openhatch.org/ OpenHatch].

=== Learning other utilities ===

The [http://openhatch.org/ OpenHatch] site has a series of
[http://openhatch.org/missions/ training missions] which are
designed to help you learn how to use these tools.

If you're new to tar, diff, patch and git, we highly recommend you sign
up with OpenHatch and do the missions.

Template:Cmd

2011-08-14T00:00:44Z

Willkg: switching span to tt

<tt style="border: thin solid #bbb; background: #ffffdd; padding-left: 5px; padding-right: 5px;">{{{1}}}</tt><noinclude>
== Usage ==
This allows you to more easily specify command line text that sticks out.

Copy and paste this in:

<pre>
{{{CMD|some command line here}}}
</pre>
</noinclude>

HackingHowto

2011-08-13T23:59:56Z

Willkg: switching a command to cmd

= Hacking HOWTO =

== So you want to hack on GNU MediaGoblin? ==

First thing to do is check out the [http://mediagoblin.org/join/ web site] where we list all the project
infrastructure including:

* the IRC channel
* the mailing list
* the issue tracker

Additionally, we have information on how to get involved, who to talk
to, what needs to be worked on, and other things besides!

Second thing to do is take a look at :ref:`codebase-chapter` where
we've started documenting how GNU MediaGoblin is built and how to add
new things.

Third you'll need to get the requirements.

Fourth, you'll need to build a development environment. We use buildout,
but if you want to use virtualenv, there's a set of mediocre not-very-supported
steps in the [https://gitorious.org/mediagoblin/pages/Home evil wiki].

== Getting requirements ==

First, you need to have the following installed before you can build
an environment for hacking on GNU MediaGoblin:

* Python 2.6 or 2.7 - http://www.python.org/ (You'll need Python as well as the dev files for building modules.)
* python-lxml - http://lxml.de/
* git - http://git-scm.com/
* MongoDB - http://www.mongodb.org/

If you're running Debian GNU/Linux or a Debian-derived distribution
such as Debian, Mint, or [http://bugs.foocorp.net/issues/478 Ubuntu 10.10+], running the following should install these
requirements:

sudo apt-get install mongodb git-core python python-dev \
python-lxml python-imaging

On Fedora:

yum install mongodb-server python-paste-deploy python-paste-script \
git-core python python-devel python-lxml

'''You can help:'''

If you have instructions for other GNU/Linux distributions to set
up requirements, let us know!

== How to set up and maintain an environment for hacking with buildout ==

'''Requirements'''

No additional requirements.

'''Create a development environment'''

After installing the requirements, follow these steps:

# Clone the repository: {{Cmd|git clone git://gitorious.org/mediagoblin/mediagoblin.git}}
# Bootstrap and run buildout: <tt>cd mediagoblin</tt> and then one of the following:
#* <tt>python bootstrap.py && ./bin/buildout</tt>, '''OR'''
#* <tt>python bootstrap.py --distribute && ./bin/buildout</tt>

Why would you want one over the other? If the first doesn't work, then try the second.

That's it! Using this method, buildout should create a <tt>user_dev</tt>
directory, in which certain things will be stored (media, beaker
session stuff, etc). You can change this, but for development
purposes this default should be fine.

If you have problems, please [http://mediagoblin.org/join/ let us know]!

'''Updating for dependency changes'''

While hacking on GNU MediaGoblin over time, you'll eventually have to
update your development environment because the dependencies have
changed. To do that, run:

./bin/buildout && ./bin/gmg migrate

'''Updating for code changes'''

You don't need to do anything---code changes are automatically available.

'''Deleting your buildout'''

At some point, you may want to delete your buildout. Perhaps it's to
start over. Perhaps it's to test building development environments
with buildout.

To do this, do:

rm -rf bin develop-eggs eggs mediagoblin.egg-info parts user_dev

== Running the server ==

If you want to get things running quickly and without hassle, just
run:

./lazyserver.sh

This will start up a python server where you can begin playing with
mediagoblin. It will also run celery in "always eager" mode so you
don't have to start a separate process for it.

This is fine in development, but if you want to actually run celery
separately for testing (or deployment purposes), you'll want to run
the server independently:

./bin/paster serve paste.ini --reload

== Running celeryd ==

If you aren't using <tt>./lazyserver.sh</tt> or otherwise aren't running celery
in always eager mode, you'll need to do this if you want your media to
process and actually show up. It's probably a good idea in
development to have the web server (above) running in one terminal and
celeryd in another window.

Run:

CELERY_CONFIG_MODULE=mediagoblin.init.celery.from_celery ./bin/celeryd

== Running the test suite ==

Run:

./runtests.sh

== Running a shell ==

If you want a shell with your database pre-setup and an instantiated
application ready and at your fingertips....

Run:

./bin/gmg shell

== Troubleshooting ==

=== pymongo.errors.AutoReconnect: could not find master/primary ===

If you see this:

pymongo.errors.AutoReconnect: could not find master/primary

then make sure mongodb is installed and running.

If it's installed, check the mongodb log. On my machine, that's
<tt>/var/log/mongodb/mongodb.log</tt>. If you see something like:

old lock file: /var/lib/mongodb/mongod.lock. probably means...

in that case you might have had an unclean shutdown. Try:

sudo mongod --repair

If that didn't work, just delete the lock file and relaunch mongodb.

Anyway, then start the mongodb server in whatever way is appropriate
for your distro / OS.

== Wiping your user data ==

You can completely wipe all data from the instance by doing:

gmg wipealldata

'''Note:'''

Unless you're doing development and working on and testing creating
a new instance, you will probably never have to do this. Will
plans to do this work and thus he documented it.

== Quickstart for Django programmers ==

We're not using Django, but the codebase is very Django-like in its
structure.

* <tt>routing.py</tt> is like <tt>urls.py</tt> in Django
* <tt>models.py</tt> has mongokit ORM definitions
* <tt>views.py</tt> is where the views go

We're using MongoDB. Basically, instead of a relational database with
tables, you have a big JSON structure which acts a lot like a Python
dict.

'''YouCanHelp'''

If there are other things that you think would help orient someone
new to GNU MediaGoblin but coming from Django, let us know!

== Bite-sized bugs to start with ==

'''May 3rd, 2011''': We don't have a list of bite-sized bugs, yet, but
this is important to us. If you're interested in things to work on,
let us know on [http://mediagoblin.org/join/ the mailing list] or
on the [http://mediagoblin.org/join/ IRC channel].

== Tips for people new to coding ==

=== Learning Python ===

GNU MediaGoblin is written using a programming language called [http://python.org/ Python].

There are two different incompatible iterations of Python which I'll
refer to as Python 2 and Python 3. GNU MediaGoblin is written in
Python 2 and requires Python 2.6 or 2.7. At some point, we might
switch to Python 3, but that's a future thing.

You can learn how to code in Python 2 from several excellent books
that are freely available on the Internet:

* [http://learnpythonthehardway.org/ Learn Python the Hard Way]
* [http://diveintopython.org/ Dive Into Python]
* [http://www.greenteapress.com/thinkpython/ Python for Software Design]
* [http://www.swaroopch.com/notes/Python A Byte of Python]

These are all excellent texts.

'''You Can Help'''

If you know of other good quality Python tutorials and Python
tutorial videos, let us know!

=== Learning Libraries GNU MediaGoblin uses ===

GNU MediaGoblin uses a variety of libraries in order to do what it
does. These libraries are listed in the :ref:`codebase-chapter`
along with links to the project Web sites and documentation for the
libraries.

There are a variety of Python-related conferences every year that have
sessions covering many aspects of these libraries. You can find them
at [http://python.mirocommunity.org Python Miro Community] -- This is a shameless plug; Will Kahn-Greene runs Python Miro Community.

If you have questions or need help, [http://mediagoblin.org/join/ let us know]!

=== Learning git ===

git is an interesting and very powerful tool. Like all powerful
tools, it has a learning curve.

If you're new to git, we highly recommend the following resources for
getting the hang of it:

* [http://learn.github.com/p/intro.html Learn Git] --- the GitHub intro to git
* [http://progit.org/book/ Pro Git] --- fantastic book
* [http://gitcasts.com/ Git casts] --- screencast covering git usage
* [http://gitref.org/ Git Reference] --- Git reference that makes it easier to get the hang of git if you're coming from other version control systems

There's also a git mission at [http://openhatch.org/ OpenHatch].

=== Learning other utilities ===

The [http://openhatch.org/ OpenHatch] site has a series of
[http://openhatch.org/missions/ training missions] which are
designed to help you learn how to use these tools.

If you're new to tar, diff, patch and git, we highly recommend you sign
up with OpenHatch and do the missions.

Template:Cmd

2011-08-13T23:59:15Z

Willkg: Created page with "<span style="border: thin solid #bbb; background: #ffffdd; padding-left: 5px; padding-right: 5px;">{{{1}}}</span><noinclude> == Usage == This allows you to more easily specify co..."

<span style="border: thin solid #bbb; background: #ffffdd; padding-left: 5px; padding-right: 5px;">{{{1}}}</span><noinclude>
== Usage ==
This allows you to more easily specify command line text that sticks out.

Copy and paste this in:

<pre>
{{{CMD|some command line here}}}
</pre>
</noinclude>