From Fedora Project Wiki
m (Fixed New Trac link) |
(Redirect Package Maintainer wiki links to docs.fp.o) |
||
| Line 4: | Line 4: | ||
* We do not alter code directly on our staging server, or the production server. You can use a [[How to install Drupal|local sandbox]] to do experiments. Public tests are done on the development server. | * We do not alter code directly on our staging server, or the production server. You can use a [[How to install Drupal|local sandbox]] to do experiments. Public tests are done on the development server. | ||
* 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. | * 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 modules must be [ | * All modules must be [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ packaged] before they goes on the development, staging, or production servers. | ||
** Packaging ensures the site structure can be recreated in the event of a catastrophic failure. | ** 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. | ** Packaging ensures other community members can benefit from our work. | ||
Latest revision as of 11:21, 9 October 2021
What you need to know
- We do not do any work on the staging or production servers that has not been tested and documented.
- We do not alter code directly on our staging server, or the production server. You can use a local sandbox to do experiments. Public tests are done on the development server.
- 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 modules must be packaged before they goes on the development, staging, or production servers.
- 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.
- To the maximum possible extent, our customizations need to be deployed as Features so they we can recreate them easily as well.
- 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
Here is our change 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.
- Add the keyword insight in the Trac ticket's Keywords field, so the change will be discussed at the next meeting.
- Use the process outlined on our page for Insight development using Features module to develop your feature. Make sure to 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.
- Write your progress in the ticket you filed, so an update comes to the team's mailing list automatically. Communicating your work is important!
- Once the team approves the change, it will be made on the staging and then production servers.
In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.
Updating the Fedora Insight theme
There's a separate page to show you how to update the Fedora Insight theme.