Skip to content
Lets make OSDEV disclaimers lie
C Assembly TeX Python Shell Makefile C++
Branch: master
Clone or download
Pull request Compare This branch is even with Involture:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
Rapport
aux_kbd_kmp
documents
kernel
libc
loader
scripts
.gitignore
README
mk

README

# picOS
Lets make OSDEV disclaimers lie

# De l'usage de ce README

Alors oui j'aime bien les README, parce que c'est inclus dans le git et ca
permet de le faire évoluer au fil des commit. Je pense pas que ce soit pour tous
les usages par contre.

En gros le README doit servir à inscrire les informations susceptible d'etre
consultees plusieurs fois. Pour les autres messages on utilisera une messagerie
instantanee !

Les informations que vous mettez dans ce README ne sont pas forcement pour les
autres, vous pouvez y mettre des infos pour vous, pour vous en rappeler ou a
titre indicatif.

Enfin je suis vraiment un putain de maniaque alors merci de garder le fichier un
peu structure.


# LES CONVENTIONS PRATIQUES (SUPER IMPORTANT).
A completer par vous

Pour ne pas perdre en efficacité, et ne pas frustrer les manies de chacun
(surtout les miennes), c'est mieux de respecter quelques regles. Hesitez pas a
en rajouter ou a contester celles que j'ai inscrites.

  PARTIE PRATIQUE
  * Tout ceux qui savent pas utiliser git (moi compris) on prend une heure pour
  lire un tuto git et on l'utilise proprement. En particulier :
    - uniquement des rebase pour integrer les changements locaux au git
    - A peu pres : Un commit par idee (par heure en gros).
                   Un ou deux push par jour.
    - Des messages de commit explicites.
    - Bon usage des branches (si idee alternative).
    - Ecrire, utiliser et maintenir un .gitignore correct.
  * On garde un arbre de fichier propre et ordonne.
  * Cohérence dans l'usage de la langue : 
    hormis ce fichier, tout en anglais : variables, abreviations, commentaires,
    messages de commit, noms de fichiers, noms de dossiers ...

  PARTIE CODE
  * Ne pas ecrire apres la colonne 80.
  * 2 espaces par indentation (comme au début de cette ligne).
  * Conventions d'indentation C a definir ci dessous :
    -
    -
    -
  * Des noms de variables explicites (faut au moins essayer).
  * Convention underscore pour les noms de variables.
  * Documenter TOUT
  * Avoir des conventions communes de documentation.
  * Commenter tout bout de code non trivial

# PLANNING.
Tres important aussi, ca evite de tout faire la derniere semaine.

  * Date de début : Mardi 6 mars.
  * Date de rendu : Dimanche 20 mai.
  * Temps disponible : 75 jours = 11 semaines.

Organisation par semaine :
  * Jusqu'au Mardi 27 mars : 3 SEMAINES
    - Lecture de documentation.
    - Ajout de la documentation d'interet commun ou durable au git.
    - Definition du cadre exacte du projet.
    - Ecriture d'une synthese du travail prévisionnel.
    - Ecriture du planning prévisionnel jusqu'au rendu.
  * ...


# AUTRES SECTIONS A AJOUTER A VOLONTER.
You can’t perform that action at this time.