kanzenminarai / rcg

Random Character Generator

hello@everyone $ cat about.c

#include <stdio.h>

int main() {
  printf("Hello!, I'm Kanzen and welcome to this profile on Git-Hub!\n"
    "I like to learn and talk, and if you do just chat with me on discord: kanzenminarai\n"
    "Be free to check it out the projects hosted on Git-Hub\n");
  return 0;
}

rcg's Issues

Proposal: change to contributing guidelines

Hey! It's me, again, I know, I'm annoying.

So, I'd like to propose here another contributing model that addresses both the issues raised in this issue, and some others, it consists of:

• A protected main branch where only you, the maintainer, can push to.
• A protected dev branch where only you, the maintainer, and trusted contributors (listed as 'developers' in Github) can push to, but, people can issue a merge request to this branch with their hot new changes, before being merged into main when it's seen as stable.
• A (optionally protected) testing branch where you and other people can test crazy (fun) stuff that you would never in a hundred moons put in your main code, but, if it works out, you can merge into your dev branch for additional testing, or you can just burn it all to the ground when you see it's a clearly bad idea, it's part of the fun of it I suppose.

Feel free to take what I say, take it apart or tweak it as it fits you, no need to be shy!

Edit:

But, yeah, I noticed something odd with your current model, why the email part? Why? I don't really mind it all that much, but it's a hell of a lot of bureaucracy for something that could be easily discussed in the merge request itself.

If you intend to keep the email requirement, I'd really appreciate it if you would specify why in the readme.

Contributing is confusing

Hey! I found this project through Low Level Learning's code review that just went up.

What you're doing looks great! Big encouragements from me.

But, I noticed some things looking through.

Let's say I wanted to contribute, where do I even start? I have no idea if you prefer git merge vs rebase, if you have a dev branch I can push to, or if they're all protected and I need to fork the repo to then do a merge request to the dev branch, or if the main branch isn't protected and I can just commit whatever way I want it (though it'd be a huge risk since anyone could just go and delete your codebase, recoverable, but not pleasant), and all that other stuff.

Clarifying this in a CONTRIBUTING file, like I found in some projects, would really do wonders both for people like myself, or newbies who have no idea what git even is :P

Oh, and another low-hanging fruit would be to populate your issues trackers, with, well, issues, or stuff that needs to be worked on, but for general discussion I'd recommend activating the 'Discussions' tab somewhere in the settings.

The code review will garner some attention but if it's too hard to find a way to interact with the project (or with you, the maintainer), most will just click away, I don't mean that badly, it's the just the reality of it.

Even if nothing comes from it, it'd still be fun to chat with people, no?

And, before all, thanks for contributing to the Libre and Open Source software movements! Hugely appreciated

Documentation: platform support

So, you know, I looked through the readme again, to see how things were going, but I saw something strange.

Here's the section that kind-off bothered me, under 'dependencies':

• RCG was created and tested on linux x86_64 based OS, install the [...]

Huhhh.. what's linux x86_64 based OS??

Let's think over it, what information does these kinds of sentences tend to convey:

• The OS it was made on (optionally)
• What platforms it supports
• OS version supported, or, in the case of Linux and potentially Unix, distribution name and version

The reason why some people call Linux -- GNU/Linux, is because it's the kernel that empowers the environment, not the other way around, most of the time, so the stuff you see on the screen, the environment and such, is a vital part of the user experience. It can, and often does introduce bugs and vulnerabilities.

So what works on one distro, might not work on the other, simply because, for example, Debian doesn't have an up-to-date compiler, so it doesn't even build. That's important information, even just mentioning on what distro it was made would help.

Some people basically hand-craft their Linux environments, like people following the Linux From Scratch handbook. If they were, they're probably vastly more knowledgeable than either one of us, but even the little things help.

(tldr: distro's important)

• If it makes kernel API calls, I wouldn't say it's needed, but it's really important to mention the latest supported kernel, or, at least, the latest kernel version it was known to work on, even more so if it uses new, bleeding edge security APIs, like, maybe, randomisation. Your program may expect behavior from an API call that might have changed throughout the kernel's lifetime, for example. Of course, you don't need to do all that homework, but it'd be amazing both for educational purposes and for people who your program, simply breaks, and they want to help fixing it.

And, btw, the architectures not important, for end-users, it's basically a buzzword, if it runs Linux, it abstracts it all away, unless you're doing really low level operations. At least, it's not important to the end-user. If they're running some really exotic architecture, that's doesn't have complete, or official support yet, like ARM, they're likely aware of it and it's they're job to report it in the bug report.

Whoo! I think.. that's about all? Quite the sprint there

But, as you might have noticed, while 'linux x86_64 based OS' sounds funny, it lacks a bit of substance, if nothing else, I hope you learned something.

Blurry video in README

Hey! It's me again.

I noticed that the video in the README is kind off blurry, that's not really important, but it's good eye-candy and gives an idea of what the program looks like.

I recommend using a specialized tool like asciinema to record your terminal sessions, it'll look much better.

Security: main git branch isn't protected

Hey!

Like I mentioned in a previous issue about how to contribute, I was confused about how one is supposed to contribute to your project, turned out it was because I skipped the README, so my bad, but I do have some concerns I'd like to raise here, like:

• Any troll passing by can delete your codebase, since your main branch isn't protected.
  (well, it's totally recoverable, but it's not pleasant)

• As related to the above, anyone can submit whatever code (or code deletion) they want to the project, without your approval. Since it's said in the contributing section of the README that one should fork and merge their changes back, I assume that's what you really want them to do instead.

I don't think it's that likely someone will bother doing this, but I'd still protect my main branch just for peace of mind, but I guess if you didn't know it wouldn't have bothered you, huh, well sorry for that.