Difference between revisions of "Guideline: How to Contribute Code"

From GhostBSD Wiki
Jump to: navigation, search
(Introduction)
Line 5: Line 5:
 
==Introduction==
 
==Introduction==
  
On this page we would like to give you some rules for developers, how to contribute code and how things need should be done.
+
On this page we would like to give you some rules for developers, how to contribute code and how things need should be done. The following guidline is derived from a statement of Eric Turgeon at [13.06.20 16:39] on telegram al leader of this project.
 +
 
 +
The more people work on a project the more necessary is it, to follow some simple rules, to ensure a save workflow to build GhostBSD releases. For a project it is important to get a clear structure, open communication, and transparency.
  
 
==Guidline==
 
==Guidline==
  
Eric Turgeon, [13.06.20 16:39]
 
Hi, has the leader of the project, I recognize the frustrations, no official written guide on how to contribute code and how things need should be done. We did discuss multiple times of the possibility of enforcing PR only. The main reason is that all master needs to be release-ready at any time. Just a significant change I did myself broked the release of May. That manly why I skipped the May release. It was only two lines in ghostbsd-build to fix, but my time was directed more on the unwritten politics of the project.
 
 
I think there is a need for workflow/guideline, so I will stop my development work to get a written guide to GhostBSD ghostbsd inside and outside contribution to code to tools and ports. It will mainly be base on the many conversations we had in the past and on the FreeBSD guideline I learn since I have my FreeBSD commit bit. I think it will help newcomers and give us more time to focus on planing and code instead of politics that we don't have time for anyway. I not sure when I will complete it. But I will come back for feedback.
 
 
Eric Turgeon, [13.06.20 17:58]
 
 
In the meantime, for those that GhostBSD Github members.
 
In the meantime, for those that GhostBSD Github members.
  
To clarify, when I refer to GhostBSD, I only refer to Official GhostBSD, which is the MATE. The other DE's are community releases and not an official thing. That might change in the future, but for now, the main focus is MATE. For that reason, with the other DE, I am less strict about them because I do not consider those as official GhostBSD. All that said, the same rule applies to there ports and changes to ghostbsd-build and all the other tools.
+
# The only official supported desktop is MATE. The other DE's are community releases. That might change in the future, but for now, the main focus is MATE. Nevertheless the same rules apply to the ports and changes to ghostbsd-build and all the other tools.
 
+
# For ports, make sure new or update port does not change or override a file from other ports, including config files. All files that ports installed need to be tracked except config files.  
For ports, make sure new or update port does not change or override a file from other ports, including config files. All files that ports installed need to be tracked except config files. Follow the FreeBSD ports Handbook for test for the guideline to make ports. A useful tool is portlint to verify the port is done right.
+
# Follow the FreeBSD ports Handbook for test for the guideline to make ports. A useful tool is portlint to verify the port is done right.
 
+
# When it comes to the GhostBSD tools, including ghostbsd-build, work on sorted tickets. If there is no ticket, no code gets in unless it is new port or port updates.  
When it comes to the GhostBSD tools, including ghostbsd-build, work on sorted tickets. If there is no ticket, no code gets in unless it is new port ports or port updates. Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.  
+
# Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.  
 
+
# If you have an idea, share it with everyone on Telegram. If the idea is good, a ticket will be done.  
Have an idea, share it with everyone here, and if the idea is good, a ticket will be done. If you work on a no official GhostBSD like XFCE, let everyone know here what you are working on to make sure no one oversteps on other's works. Don't start something that will affect any GhostBSD tools and or itself GhostBSD without a sorted ticket. The main reason is unplanned changes can affect other's work and affect the main project. The main point is to communicate what people are working for transparency to avoid frustrations.
+
# If you work on a non-official GhostBSD, like XFCE, let everyone know on Telegram, what you are working on, to make sure no one oversteps on other's works.  
 +
# Don't start something that will affect any GhostBSD tools and or GhostBSD itself without a sorted ticket. The main reason is unplanned changes can affect other's work and affect the main project.  
 +
# The main point is to communicate whit all people who are working on GhostBSD.  Transparency is important to avoid frustrations.
  
Eric Turgeon, [13.06.20 17:59]
 
I am serious about this. I have been asked a couple of times to put my feet down in the ten last years of GhostBSD, I never really did. This project is not what it was 10, 5 or 2 years ago, and a lot changed since last year. We cannot execute this project in the free for all like it was in the past. I am the founder of the project and the leader, I try to not act like a dictator, but now it is time for reformation. I want structure, communication, and transparency.
 
  
This is my main statement, for now, Utile I come up with the official written guideline. Now for anyone that is not happy with this, you can start your own project. I started myself to work on that structure for the last few weeks, and I expect the GhostBSD GitHub member to do the same.
+
For anyone who is not happy with this can start his/her own project.

Revision as of 08:56, 19 June 2020

Welcome to Icon Disti GhostBSD.png Guideline: How to Contribute Code.
Development Contributor Page
Porters Guideline Guideline: How to Contribute Code GhostBSD Builds
Back to Icon Disti GhostBSD.pngContribution
This page is in maintenance!
Please do not change this page without to contact the author or use Discussion!

Introduction

On this page we would like to give you some rules for developers, how to contribute code and how things need should be done. The following guidline is derived from a statement of Eric Turgeon at [13.06.20 16:39] on telegram al leader of this project.

The more people work on a project the more necessary is it, to follow some simple rules, to ensure a save workflow to build GhostBSD releases. For a project it is important to get a clear structure, open communication, and transparency.

Guidline

In the meantime, for those that GhostBSD Github members.

  1. The only official supported desktop is MATE. The other DE's are community releases. That might change in the future, but for now, the main focus is MATE. Nevertheless the same rules apply to the ports and changes to ghostbsd-build and all the other tools.
  2. For ports, make sure new or update port does not change or override a file from other ports, including config files. All files that ports installed need to be tracked except config files.
  3. Follow the FreeBSD ports Handbook for test for the guideline to make ports. A useful tool is portlint to verify the port is done right.
  4. When it comes to the GhostBSD tools, including ghostbsd-build, work on sorted tickets. If there is no ticket, no code gets in unless it is new port or port updates.
  5. Please do not create a ticket with questions. It will close immediately with a reply message to join GHostBSD forums or Telegram for questions.
  6. If you have an idea, share it with everyone on Telegram. If the idea is good, a ticket will be done.
  7. If you work on a non-official GhostBSD, like XFCE, let everyone know on Telegram, what you are working on, to make sure no one oversteps on other's works.
  8. Don't start something that will affect any GhostBSD tools and or GhostBSD itself without a sorted ticket. The main reason is unplanned changes can affect other's work and affect the main project.
  9. The main point is to communicate whit all people who are working on GhostBSD. Transparency is important to avoid frustrations.


For anyone who is not happy with this can start his/her own project.