From Fedora Project Wiki

Revision as of 19:28, 18 April 2011 by Pfrields (talk | contribs) (Fix link)

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

What you need to know

  • We do not do any work on the production server that has not been tested and documented.
  • We do not alter code directly on our test server, or the production server. You can use a local sandbox to do experiments.
  • Our goal is to write as little custom code as possible for Insight. Wherever possible, we prefer to use community provided modules that are well tested and actively maintained.
  • All code must be packaged before it goes on the test or production server.
    • Packaging ensures the site structure can be recreated in the event of a catastrophic failure.
    • Packaging ensures other community members can benefit from our work.
  • If you are helping develop the Insight platform, it is your responsibility to keep other team members updated on your work. You can do this through the mailing list and through tickets assigned to you.

How to make a change

Unfortunately, we don't have the ability to simply capture changes in a source code management system like git. So we must have some process to provide change in an orderly fashion. It's not orderly for everyone to simply make whatever changes they want without attention to our goals. At the same time, the process needs to be easy to follow and conducive to change.

Proposed process:

  • Make sure a ticket is filed in the fedora-infrastructure Trac to record the issue you're fixing or the desired enhancement. Whether you file the ticket, or take up an existing ticket, make sure you have assigned the ticket to yourself, and accepted it using the Trac interface.
  • Test your proposed fix on your own sandbox, to make sure you know what you're changing, and that it works. The team can provide a copy of the production data if needed. (NOTE: This depends on the backup_migrate module, currently in package review.)
  • Write down the steps needed for the change as a comment in the ticket you filed, so the team mailing list receives a notice.
  • Try the steps in the test server, being careful to exactly follow the steps you wrote. If you find a discrepancy, update the ticket so it is accurate. No one will mind if you need to alter your steps! But it's important that we be able to track the correct series of changes you made.
  • Add the keyword insight in the Trac ticket's Keywords field, so the change will be discussed at the next meeting.
  • Once the team approves the change, it will be made on the production server.

In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.