gogle code & github

[Samuel Laulhau]

Bonjour,
le dernier message qui est passé sur ce groupe m'a fait me poser une question.
est ce que vous avez déjà pensé à migrer le projet sur github ?

Voilà c'est tout,

Samuel

[eKameleon]

Hello :)

Pour le moment je n'ai aucunement le besoin de migrer vers GitHub :)

Les raisons simples :

GitHub même si il met en avant un côté "social" pour travailler sur un
projet opensource est très loin de proposer tous les outils
disponibles sur Google Code. Un gros phénomène de mode pousse de
nombreuses personnes à aller sur GitHub mais franchement pour un
développement de qualité il n'y a pas photo pour moi entre ce que
propose Google Code et GitHub. De plus avec tout ce que Google met en
place ces derniers temps avec Google Plus, etc. Je n'ai pas à douter
des évolutions prochaines dans Google Code qui vont le rendre encore
plus ouvert qu'à l'heure actuelle... même si déjà il est possible d'y
faire un peu tout ce que l'on veut :) Le seul soucis peut être de
Google Code c'est l'impossibilité de créer des projets privés
(moyennant finance) ... mais c'est un détail ;)

Niveau de la solution de versionning, j'utilise le combo SVN/TRAC
depuis longtemps et je considère que SVN répond parfaitement à mes
besoins. Sachant que depuis peu Google Code propose lui aussi de créer
des projets au format GIT (ou Mercurial depuis un moment) et
franchement je me vois mal répondre à la mode actuelle de passer mon
projet sur GIT sachant que j'ai tout de même un passif sur SVN de
plusieurs années maintenant et que tout se passe au mieux. A noter que
SVN 1.7 vient de sortir avec son lot de nouvelles fonctionnalités...
que SVN est installé en natif sur OSX par exemple et que je n'ai pas
du tout la philosophie GIT au niveau de mon utilisation quotidienne,
tout cela me suffit pour rester comme je suis pour un bon moment
encore :)

Je n'utilise pas GIT car je considère que cela favorise un travail un
peu trop sélectif et pas assez collaboratif avec la possibilité de
créer des tas de forks qui peuvent aller à l'encontre d'un travail
opensource en équipe comme je l'entends. Si tout le monde à la liberté
de bosser dans son coin pour ensuite fusionner un peu tout est
n'importe quoi.. cela peut devenir rapidement le border sur un projet
de grosse taille.

Pour conclure, il est clair qu'il est inutile de courir dans tous les
sens :) Mes projets opensources sont sur SVN depuis des années, je
n'ai aucune raison de modifier cela et aucune raison de perdre les
utilisateurs dans un nouveau système de versionning... Au début du
projet de VEGAS j'avais mis les sources sur osflash ... avec le
problème qu'après quelques années ils nous ont virés du service
d'hébergement en nous poussant à migrer nos serveurs SVN sur Google
Code ou autre... cela m'a pris beaucoup de temps avec les problèmes de
changement d'ip serveur etc. et du coup une coupure dans la
récupération des sources du projet... pas très positif au niveau d'un
projet opensource de perdre les utilisateurs.

J'espère avoir répondu à ta question ;)

J'attends toujours des commentaires sur mon autre message du coup ;)

EKA+ :)

[Samuel Laulhau]

Oui tu as tout à fait répondu à ma question à un détail prêt :

mais franchement pour un

développement de qualité il n'y a pas photo pour moi entre ce que
propose Google Code et GitHub

A quel niveau ? Qu'est ce que google code propose que github ne propose pas ?

Pour ce qui est de l'autre sujet, j'avouerai que tu m'as un peu perdu, je vais le relire voir si ça m'inspire quelque  chose :)

Bonne journée

[eKameleon]

Hello :)

Je te retourne la question :) Qu'est ce que GitHub propose et SVN ne
propose pas ?

A mon niveau et pour mon usage, je ne vois pas du tout ce que Github
peut m'apporter de plus que SVN.

Exemple, souvent les utilisateurs de GIT mettent en avant la gestion
des merges dans GIT... mais sérieusement au niveau des merges dans mes
projets je les fais toujours manuellement car j'ai des besoin
spécifiques dans mon process de travail et je n'ai pas envie de
laisser faire l'outil de versioning. Donc pas très parlant pour moi
l'argument de travailler avec un outil de merging avancé.

De même j'en ai parlé dans mon commentaire du dessus, je considère que
la possibilité de faire des forks avec des versions qui se croisent
dans tous les sens pour au final refusionner les versions... cela
complexifie énormément la production et l'évolution d'un projet. Je
préfère largement commiter à chaque fois sur le repository SVN pour
éviter justement de bosser dans une direction et avoir dans l'équipe
un développeur qui part dans une autre direction... au niveau d'un
travail basé sur de l'XP et une gestion de projet ouverte je pense
qu'il faut commiter le plus possible vers les autres utilisateurs d'un
projet et ainsi que chacun soit en sync pour bosser sans conflit (ou
du moins avec le moins de conflit possible). Il ne faut jamais oublier
qu'à l'heure actuelle très peu de développeur utilise correctement les
outils de gestions de projets, d'XP etc. et au final on se retrouve
vite dans un grand n'importe quoi si l'outil permet trop de liberté.

Pour le reste SVN est parfait pour mon usage quotidien, s'installe
simplement.

C'est en cela que je disais qu'il n'y a pas photo ;) Je ne vois pas du
tout du coup pourquoi je devrais changer de solution car justement
tout le monde annonce un système de versioning extraordinaire avec GIT
mais je ne vois pas du tout pourquoi ;) Je ne reste donc pas fermé de
l'utiliser si un projet client m'impose de l'utiliser (contrairement à
Mercurial qui par contre me déplait au plus haut point...) mais cela
en restera là pour le moment.

EKA+ :)

[zwetan]

la plus grosse différence entre google code et github
c'est la philosophie du fork

dans github, non seulement parce qu'ils utilisent Git,
mais principalement dans leur interface, ils créent le coté
"social coding" en poussant les devs a faire du fork dans tous les
sens

par ex, tu crées une issue "je pense qu'il manque ca dans ton code",
tu fais un fork du project XYZ, dans ton coins tu patch/ajoutes ce que
toi tu penses manque, et pis apres tu finis par un "pull request"
où en gros tu dis au developeur original du code
"j'ai fais ces modifs, s'il te plait reintegre ca dans le code"

Github l'explique ici
http://help.github.com/send-pull-requests/


et pour moi c'est exactement le probleme de github (et par extension
git)

si je bosse en equipe sur un projet open source, c'est pas de cette
manière
que je veux bosser, je veux pouvoir discuter avec les autres devs
avant que
des modifs soient faites

bref, je vois le fork tres différemment

pour moi un fork c'est quelqu'un qui me dit "je suis pas d'accord avec
la direction que prends le projet",
ok c'est bien, chacun est libre de faire un fork, mais apres avec "ta
vision différente" tu reviens pas me dire d'intégrer ca dans ce que je
fais, parce que si t'as pas pris le temps de discuter du soit disant
"probleme", bref si il n'y a pas de communication au niveau du
development et bah moi ton "pull request" et bah je vais completement
l'ignorer.


Une des choses les plus dure dans un projet open source c'est de
justement garder la ligne directrice
et de ne pas partir dans tous les sens, et perso le seul moyen que je
me vois de faire ca c'est de justement discuter avec les autres devs
du projet, "pourquoi on fait ca", "pourquoi on ajoute ca", "pourquoi
on le fait de cette manière et pas de cette autre facon", etc.

Avec google code, les gens peuvent toujours forker si ils veullent,
mais si ils veullent que ce soit reintegrer dans le code ils vont
devoir
communiquer, obtenir les droits de commit, ou envoyer un diff et
expliquer le truc

pour le probleme "je pense qu'il manque ca dans ton code"

soit la personne est deja dans la team de dev, et donc on discute,
ca peut etre validé ou non

soit la personne est externe au projet et ca rajoute une issue,
qui elle aussi peut etre validé ou non

bref, au lieu de partir dans un fork direct, on discute avant
si ca vaut le coup ou pas, si ca va dans la direction du projet ou
pas, etc.

Et ca je pense que ca évite de perdre du temps et surtout de partir
dans n'importe quelle direction.


Maintenant sur les différences entre Git et SVN,
je pense aussi que Git et Github c'est l'effet de mode
"le truc où il faut se montrer si on est un codeur"
super...

sauf que tout comme je suis contre le fork et pour la communication
entre devs
je suis contre un SCM décentralisé et pour un SCM centralisé

En bossant sur maashaack et d'autres projets avec Eka on est passé par
plusieurs phases,
et en fait SVN c'est vraiment LE bon outil pour nous et il y a
énormément de choses
qu'on peut faire avec SVN qu'on ne pourrait pas faire avec Git ou
Mercurial.

Récemment on a modifier la structure d'organisation de maashaack,
on est passé d'une structure on va dire "monolithique" a une structure
hyper modulaire,
et bah heureusement qu'on est resté sous SVN, parce que sous Git on
aurait pas pu.

Avec Eka on a cette philosophie que le code est vivant et change tout
le temps,
sur un truc comme maashaack on gere vraiment énormément de code et ca
pourrait tres
vite tourner au bordel.

A coté de ces projets open source on aussi des choses qui se passent
au niveau de nos boulots
respectifs, bref on s'est retrouvé dans des situations où
- maashaack vX est deja utilisé dans un projet, on veut faire de gros
changement dans maashaack sans casser
le "vieux" projet qui l'utilise
- maashaack doit etre utilisé a coté d'autres projets comme un
"component"
- on voudrait utiliser maashaack pour tel projet mais il faut modifier
des choses dans maashaack
pour que ce soit possible

bref, en restant dans un seul repo avec tout le code groupé au meme
endroit, a force cela crée
des problemes de sync (meme avec des branches et des tags), et que en
soit le projet est trop gros
pour faire un fork a chaque fois qu'on l'utilise (ce serait trop le
bordel a gérer).


Et donc pour rendre ce code source modulaire, on a copié ce qu'il se
fait avec la gestion du code source
de chromium (google chrome).

En gardant SVN, on utilise au dessus de celui-ci un outil qui
s'appelle 'gclient',
cela permet de créer une 'solution' qui consiste en fait d'une serie
de repertoire auquel on associe
un path de repo SVN.

par ex:

solutionX
|_ toto https://toto.googlecode.com/svn/trunk
|_ titi https://titi.googlecode.com/svn/trunk
|_ tutu https://tutu.googlecode.com/svn/trunk

faire de cette maniere, ca nous permet d'assembler differents projets
open sources pour nos besoins

cet outil 'gclient' permet aussi de faire des override en local,
par ex si je veux bosser depuis branches/test123 au lieu de trunk
j'ai just a modifier le fichier local ".gclient" pour obtenir ca

solutionX
|_ toto https://toto.googlecode.com/svn/trunk
|_ titi https://titi.googlecode.com/svn/branches/test123
|_ tutu https://tutu.googlecode.com/svn/trunk


mais en poussant l'usage de l'outil ca permet d'aller encore plus loin
et de completement maitriser l'arborescence d'un projet

solutionX
|_ toto https://toto.googlecode.com/svn/trunk
|_ test https://toto.googlecode.com/svn/test/trunk
|_ titi https://titi.googlecode.com/svn/trunk
|_ tutu https://tutu.googlecode.com/svn/trunk


et ca, c'est justement ce que Git ne peut pas faire,
avec Git on ne pourrait pas imbriquer des repertoires venant de
different repos dans une arbo comme celle la

plus d'infos sur gclient
http://dev.chromium.org/developers/how-tos/depottools
http://dev.chromium.org/developers/how-tos/chromium-modularization
http://dev.chromium.org/developers/contributing-to-webkit


Pour simplifier je dirais que gclient ca permet de remplacer les
svn:externals
et de garder une liste claire de ce qui se passe avec des fichiers
DEPS.

Et pour maashaack ca permet de passer chaque "package" ou "library" ou
"tool" en module "independant"
que ensuite on re-assemble dans différentes projets.

LA vraie difference SVN et Git, c'est que avec SVN on peut gerer ca
dans un seul repo,
avec Git on devrait créer un repo par "module", bref non merci.
(note que meme si gclient dit qu'il gere les repos Git, j'ai testé et
bref gros bordel,
avec SVN au contraire pas de bordel du tout)


Pour finir je dirais que ce changement d'organisation pour maashaack
n'aurais jamais pu
exister en faisant un fork (ala Github), le seul moyen de le faire
correctement et progressivement
c'etait de discuter avec Eka, de peser le pour et le contre, de bien
verifier que ca reglait
vraiment tous nos problemes, que ca peut evoluer pour le futur etc.
bref discuter


zwetan

[eKameleon]

Il est clair que même si parfois les discussions peuvent être
relevées... que parfois faut un peu de temps pour analyser une
discussion...

Au final en bossant en équipe avec une optique bien définie par le
groupe et une motivation à toute épreuve on trouve toujours les bonnes
directions à force d'écoute, de travail et de discipline sur le code.

Pour moi faire du fork dans tous les sens et du coup proposer aux
utilisateurs des tas de versions d'une même solution (opensource ou
pas) ne facilite pas non plus pour l'utilisateur la direction à
prendre... SI on commence à utiliser le code d'un fork et qu'il n'est
pas maintenu par l'équipe principale du projet ou par la personne qui
a eu besoin du fork à un moment mais qui ne pratique pas vraiment
l'opensouce dans la durée... tout cela provoque au final des gros
soucis avec des projets bien souvent abandonnés ou inaccessibles au
possible !

EKA+ :)

On 13 août, 19:54, zwetan <zwe...@gmail.com> wrote:
> la plus grosse différence entre google code et github
> c'est la philosophie du fork
>
> dans github, non seulement parce qu'ils utilisent Git,
> mais principalement dans leur interface, ils créent le coté
> "social coding" en poussant les devs a faire du fork dans tous les
> sens
>
> par ex, tu crées une issue "je pense qu'il manque ca dans ton code",
> tu fais un fork du project XYZ, dans ton coins tu patch/ajoutes ce que
> toi tu penses manque, et pis apres tu finis par un "pull request"
> où en gros tu dis au developeur original du code
> "j'ai fais ces modifs, s'il te plait reintegre ca dans le code"
>

> Github l'explique icihttp://help.github.com/send-pull-requests/

> plus d'infos sur gclienthttp://dev.chromium.org/developers/how-tos/depottoolshttp://dev.chromium.org/developers/how-tos/chromium-modularizationhttp://dev.chromium.org/developers/contributing-to-webkit

[Samuel Laulhau]

Bonjour,

désolé de répondre que maintenant et merci pour ces avis d'utilisateurs expérimentés :)

En fait je me posais la question car le dépôt de Vegas est un peu rebutant à première vue avec tous ces sous dépôt ce n'est pas facile de rentrer dans son mécanisme.

Pour le reste j'ai travaillé pendant près de 2 ans avec svn avant de passer à git, et je dois dire que sur tout ce qui est envoie/réception des commits, travailler sur des branches, conflits... git est plus rapide et plus puissant. 

Je trouve bizarre cependant que vous vous arrêtiez principalement au système mis en avant par github, c'est vrai que c'est généralement néfaste pour un projet d'avoir plein de fork qui risquent de le vider de ces utilisateurs mais il y a aussi de nombreux exemples qui marchent bien.

Quoiqu'il en soit je n'était pas là pour polémiquer mais simplement savoir si vous n'aviez pas migré sur github parce que vous n'en aviez pas besoin où parce que vous ne  vouliez pas.

Merci

bonne journée

SAmuel

[ekameleon]

Hello :)

Pour pour GIT plus rapide.. dépend du serveur où on l'installe et pas de GIT ou SVN ;) Sinon on ne bouge pas pour la raison simple que SVN est très bien pour nos usages et que le projet utilise SVN depuis trop longtemps pour faire des changements là dessus sans raison. 

Sinon VEGAS justement regroupe dans son SVN tout ce qu'il faut pour bosser, le coup du repo un peu rebutant alors qu'il y a un tuto simple pour expliquer comment installer VEGAS :) Là encore je pense simplement que c'est plus un soucis de prendre le temps de lire la documentation (qui est pas bien grosse) ;)

Suffit d'aller chercher le contenu du répertoire libs/ et d'utiliser les swc en fonction des besoins. 

Tout est expliqué sur le wiki du projet : http://code.google.com/p/vegas/wiki/InstallVEGASwithSVN avec un lien sur l'accueil du projet sur Google Code.

Donc en gros, si tu cibles dans Flash, FDT, Flash Builder, Flash Develop le fichier vegas.swc tu as tout dedans et c'est tout simple ensuite pour utiliser n'importe quelle classe du framework.

Pour la documentation suffit d'aller en ligne : 

http://ekameleon.net/vegas/docs/

ou d'utiliser une des documentations simplifiée.

Sinon dans le wiki ou le fichier readme.txt tu as les indications sur les différentes library, exemple : 

You can use different libraries to compile with VEGAS in your project.

• maashaack.swc : "full" contains all the maashaack packages (core, system, graphics, etc.)
• maashaack modules
• core.swc : the core package only
• eden.swc : the library.eden package only
• system.swc : the system package only
• graphics.swc : the graphics package only

either you want to keep the modularity of the packagesd and you use : core.swc, system.swc, graphics.swc or you want all the packages in one swc and you use only maashaack.swc

In the AS3/trunk/libs directory you can find the libraries :

• vegas-only.swc : contains only the vegas package.
• vegas-sa.swc : "standalone" contains the vegas package and all its dependencies (core, system, graphics)
• vegas.swc : "full" contains the vegas package, its dependencies ant all the vegas extensions (lunas, calista, etc)

Note : The core packages (core, system and graphics) of VEGAS is based on Maashaack, more informations about this opensource framework 

Donc à chaque fois qu'on me dit que c'est compliqué.. je me demande pourquoi ? :) Un seul fichier à utiliser et c'est tout :) Ensuite lire la doc et venir ici pour poser des questions en cas de soucis :)

EKA+ :)

[Xavier MARTIN]

Salut Eka,

Ca serait sympa aussi de mettre les swc sur un repo maven/ivy.

J'ai cree un repo spe AS/Flex il y a un petit moment et je passe le mot doucement aux devs.

http://as-artifacts.org

Si tu veux bien mettre ca sur as-artifacts.org, je pourrai te filer une tache ant que j'ai cree comme base. Aussi te filer un droit d'acces.

++

----------------------------------------------------------------------
Xavier MARTIN aka zeflasher or xxlm
Visit my website if you love flash:
http://www.webbymx.net
http://dev.webbymx.net
----------------------------------------------------------------------

2011/8/22 ekameleon <ekam...@gmail.com>