KolibriOS/kolibrios
13
14
Fork 12
Code Issues 113 Pull Requests 16 Actions Projects 1 Releases Wiki Activity

Docs: Added README and contributing guide #124

Merged
mxlgv merged 9 commits from add-readme-contributing-code-of-conduct into main 2025-03-21 21:08:49 +01:00
Conversation 21 Commits 9 Files Changed 3 +1 -23
1 changed files with 1 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 78dfe36976 - Show all commits

24
CONTRIBUTING.md
View File

@@ -37,7 +37,7 @@ When a pull request is submitted, at least two project participants must conduct
The commit message should look like this:
```test
[Category] Commit message header
Commit message header
mxlgv marked this conversation as resolved Outdated
Sweetbread commented 2025-03-13 19:19:31 +01:00
Outdated
Review
Copy Link

-> commit type(category): commit message
To Conventional Commit Messages

-> `commit type`(`category`): `commit message` To [Conventional Commit Messages](https://gist.github.com/rishavpandey43/84665ffe3cea76400d8e5a1ad7133a79)
dunkaist commented 2025-03-15 15:43:42 +01:00
Outdated
Review
Copy Link

I have checked Linux, Qemu and GCC. They all do mention categories but in a plain format like 'category: Commit message'. I believe it would be easier for us to explain to people why they should follow a policy if it is the policy of Linux, Qemu and GCC rather than the one of Rishav Pandey.

I have checked [Linux](https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90fd9ad5b0c981693c8512d9da01f14fb6596e9d), [Qemu](https://gitlab.com/qemu-project/qemu/-/commit/2f3b6e61f692bade441230dd25c1c0f101bd2eef) and [GCC](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=254549d2bb9bb3c2719dec597427919c59514fc3). They all do mention categories but in a plain format like 'category: Commit message'. I believe it would be easier for us to explain to people why they should follow a policy if it is the policy of Linux, Qemu and GCC rather than the one of Rishav Pandey.
Sweetbread commented 2025-03-15 15:47:33 +01:00
Outdated
Review
Copy Link

https://www.conventionalcommits.org/en/v1.0.0/

Why Use Conventional Commits

  • Automatically generating CHANGELOGs.
  • Automatically determining a semantic version bump (based on the types of commits landed).
  • Communicating the nature of changes to teammates, the public, and other stakeholders.
  • Triggering build and publish processes.
  • Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
https://www.conventionalcommits.org/en/v1.0.0/ > **Why Use Conventional Commits** > - Automatically generating CHANGELOGs. > - Automatically determining a semantic version bump (based on the types of commits landed). > - Communicating the nature of changes to teammates, the public, and other stakeholders. > - Triggering build and publish processes. > - Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
dunkaist commented 2025-03-15 16:11:54 +01:00
Outdated
Review
Copy Link

I might be wrong but this looks like whishful thinking to me.

Automatically generating CHANGELOGs.

All the automatically generated changelogs I have seen are unreadable because you have to know the context first to understand them. They can be used if you want to have them as a formality only. But they won't be useful for users/developers as a dump of commit messages.

Automatically determining a semantic version bump (based on the types of commits landed).

To what version in KolibriOS does this apply?

Communicating the nature of changes to teammates, the public, and other stakeholders.

The nature of changes is described in any normal commit message.

Triggering build and publish processes.

Currently we build and publish on each push. What will this change?

Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.

I have never seen anybody using it.

I might be wrong but this looks like whishful thinking to me. > Automatically generating CHANGELOGs. All the automatically generated changelogs I have seen are unreadable because you have to know the context first to understand them. They can be used if you want to have them as a formality only. But they won't be useful for users/developers as a dump of commit messages. > Automatically determining a semantic version bump (based on the types of commits landed). To what version in KolibriOS does this apply? > Communicating the nature of changes to teammates, the public, and other stakeholders. The nature of changes is described in any normal commit message. > Triggering build and publish processes. Currently we build and publish on each push. What will this change? > Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history. I have never seen anybody using it.
Sweetbread commented 2025-03-15 16:38:34 +01:00
Outdated
Review
Copy Link

All the automatically generated changelogs I have seen are unreadable because you have to know the context first to understand them

If commit messages are descriptive, follow a consistent format, and include meaningful context, the generated changelog can be more useful.

To what version in KolibriOS does this apply?

Not neccessary the OS, but apps, libs and other software in it

The nature of changes is described in any normal commit message.

The standart enforse to use types, which is better both for describing and searching in commit list

Currently we build and publish on each push. What will this change?

For example, not to build if the type is docs

I have never seen anybody using it.

Namida, antimicrox, AGS, yazi, bubbletea, pokete, Bagels, kaizen, fd

> All the automatically generated changelogs I have seen are unreadable because you have to know the context first to understand them If commit messages are descriptive, follow a consistent format, and include meaningful context, the generated changelog can be more useful. > To what version in KolibriOS does this apply? Not neccessary the OS, but apps, libs and other software in it > The nature of changes is described in any normal commit message. The standart enforse to use types, which is better both for describing and searching in commit list > Currently we build and publish on each push. What will this change? For example, not to build if the type is `docs` > I have never seen anybody using it. [Namida](https://github.com/namidaco/namida), [antimicrox](https://github.com/AntiMicroX/antimicrox), [AGS](https://github.com/Aylur/ags), [yazi](https://github.com/sxyazi/yazi), [bubbletea](https://github.com/charmbracelet/bubbletea), [pokete](https://github.com/lxgr-linux/pokete), [Bagels](https://github.com/EnhancedJax/Bagels), [kaizen](https://github.com/TheRiceCold/kaizen), [fd](https://github.com/sharkdp/fd)
dunkaist commented 2025-03-15 17:14:34 +01:00
Outdated
Review
Copy Link

If commit messages are descriptive, follow a consistent format, and include meaningful context, the generated changelog can be more useful.

I wish we could eventually motivate people to write meaningful commit messages. Let be honest, forcing them to choose from 20 commit types it just too much, it won't work. What is surprisingly strange, the spec allows to shorten feature as feat but not performance as perf, no logic behind this.

For example, not to build if the type is docs

The rebuild is needed is the docs are in the distro. Tup handles this automatically already. You don't need to manually control this via commit messages.

Namida, antimicrox, AGS, yazi, bubbletea, pokete, Bagels, kaizen, fd

I have never heard of them. Linux, Qemu and GCC are more familiar to our potential developers, I believe.

> If commit messages are descriptive, follow a consistent format, and include meaningful context, the generated changelog can be more useful. I wish we could eventually motivate people to write meaningful commit messages. Let be honest, forcing them to choose from 20 commit types it just too much, it won't work. What is surprisingly strange, the spec allows to shorten feature as feat but not performance as perf, no logic behind this. > For example, not to build if the type is docs The rebuild is needed is the docs are in the distro. Tup handles this automatically already. You don't need to manually control this via commit messages. > Namida, antimicrox, AGS, yazi, bubbletea, pokete, Bagels, kaizen, fd I have never heard of them. Linux, Qemu and GCC are more familiar to our potential developers, I believe.
mxlgv commented 2025-03-15 23:19:41 +01:00
Outdated
Review
Copy Link

What GCC uses, Linux seems to me really more attractive

What GCC uses, Linux seems to me really more attractive
mxlgv commented 2025-03-20 01:44:31 +01:00
Outdated
Review
Copy Link

@Sweetbread @dunkaist The adoption of a style for commits can take a long time (while we are discussing we don't have any documentation at all). This minimal documentation with very light rules should be enough for the community while it adapts to GIT. We can probably raise this issue in the future. But for now, let's not get hung up on it. This PR contains other changes as well.

@Sweetbread @dunkaist The adoption of a style for commits can take a long time (while we are discussing we don't have any documentation at all). This minimal documentation with very light rules should be enough for the community while it adapts to GIT. We can probably raise this issue in the future. But for now, let's not get hung up on it. This PR contains other changes as well.
Commit message body, if needed
```
@@ -50,28 +50,6 @@ Commit message body, if needed
Maximum number of characters in a commit header is **72** (standard for **Git**). Also, **72** is the maximum length of a line in a commit body.
### Categories
List of existing categories accepted in the project:
- `Krn` - kernel
- `Drv` - drivers
- `Libs` - libraries
- `Apps` - user-space applications
- `Skins` - skins
- `Build` - build system
- `CI/CD` - CI/CD
- `Docs` - documentation
- `Data` - images, configs, resources, etc.
- `All` - global changes
If changes are made to a specific component, the name of the component separated by `/` character needs to be specified. For example:
```text
Apps/shell
Libs/libimg
```
## Merge commits
> [!WARNING]