[Kos-cvs] [osdm] Modification CVS par d2

[KOS CVS]

Module :	osdm
Modifié par :	d2	22/04/02 19:28:20

Fichiers modifiés :
	.              : osdm.tex 

Détails :
commit = petits arrangements pour menager les susceptibilites + cosmetique.

Pour l'instant, j'ai pas grand chose a ajouter. Mais je vais
reflechir, promis. En particulier, le type de manif est encore vague,
et sa definition va de paire avec la mise en place d'un calendrier
plus formel. D'un autre cote, le calendrier depend de quels
intervenants seront la, etc...

Pour la phase d'accueil, si y'a une 50aine de personnes, ca peut etre
pas mal de faire intervenir les gens par equipe de dev ou en solo si
ils viennnent en electron libre, qu'ils se presentent, sans ordi sans
rien : decrivent leur projet brievement en groupe, oralement et tout a
fait informellement, puis se presentent eux-meme a tour de
role. Apres, 2eme phase : les "shows" de presentation des projets pour
ceux qui veulent : slides, show de la mort, demo, ... En insistant
bien sur 1/ les originalites meme si c'est pas termine (par exemple :
fonctionnement en equipe distante/locale, perfs de l'OS, modele,
features, portabilite, ...), 2/ les trucs qui marchent, 3/ les trucs
qui restent a faire. Ca ferait une entree en matiere qui permettrait
de savoir qui est qui, que fait quel OS, comment ca marche (en gros),
comment il est developpe, etc.

Concernant le show, je pense que fournir une serie de points sur
lesquels les shows peuvent partir est important (quel OS pour la
machine hote, quel langage, quel modele [monolith/micronoyau/autre],
quelle machine cible, debugging, infos techniques :
multi-processus/tread, vm, temps-reel, ...) => une sorte de
mini-plan. Sinon ca va se barrer dans tous les sens, et on risque de
pas trop voir ce qui se cache derriere (surtout si les mecs ont pas
l'habitude).

Apres ca, certains peuvent faire des presentations plus techniques et
detaillees (2eme jour ?) sur les features originales de certains
OS. Eventuellement en s'y mettant a plusieurs equipes de dev sur 1
point particulier (genre : VMM SVR4, gestion mm mode protege
x86, ...). Ca, je pense que c'est le genre de truc a prevoir sous la
forme d'un calendrier a l'avance, histoire que si plusieurs equipes
presentent le meme truc, elles le fassent ensemble, ou alors 1 seule
seulement s'en occupe.

D'ailleurs, je pense a un truc, pour les mecs qui viennent et font
partie d'une equipe de dev, ca serait bien (et ca pourrait aider a la
"selection") qu'ils envoient une description breve du travail de leur
equipe (caracteristiques de l'os, histoire, combien de developpeurs,
comment est developpe l'os, pedigree des developpeurs [etudiants,
pro,...], maturite de l'OS). Pour ceux qui viennent en electron libre,
demander leurs experiences en terme de patches par exemple ou de
comprehension sur divers OS libres ou non libres peut aussi etre pas
mal.

Pour les journees qui suivent, le truc de reve, c'est que ca suscite
ET du brain storming, ET du codage de bourrin. On peut imaginer qu'au
debut les equipes evoluent un peu de leur cote, mais que les
presentations du debut suscitent des interets, et qu'au cours du
coding, une emulation joue, que des equipes aillent voir les autres
equipes parce qu'elles aimeraient en savoir plus sur un point qu'elles
trouvent interessant, etc... Bref, au debut, ca va peut-etre
ressembler a une coding party. Mais si on est optimiste, on peut
imaginer que les presentations du debut auront eveille la curiosite de
quelques uns, qui veulent alors en savoir plus... c'est la que le
brain storming peut intervenir.

Bref, en gros, j'ai l'impression que c'est le debut qui devrait etre
structuré, afin de mener les gens a s'interesser, a vouloir en savoir
plus, a eveiller la curiosite des autres. Apres, faut esperer qu'une
fois lance, le woodstock du coding qui suit pourrait devenir du brain
storming inter-equipe. C'est peut-etre un peu idealiste tout ca. Car
ce qui est a craindre, c'est que ca derape en "mon OS est mieux que le
tien. D'abord.". Et la ca serait con. Si l'etape de presentation est
bon enfant, faut esperer que la suite "ideale" (cf supra) viendra
d'elle-meme.

PS : si il manque des 'h', c'est normal (mon clavier est pourri)