[lang_en] University of Avignon and Open Source Software[/lang_en][lang_fr] Université d'Avignon et Logiciel Libre[/lang_fr]

FileZ-2.0.1

Arnaud Didry — Fri, 27 Aug 2010 15:57:43 +0000

Une mise à jour de maintenance est prête pour FileZ. Voici le court changelog :

Added spannish translation
Documented configuration with an Oracle Ldap Server
Fixed shortened file URL when sending emails (thanks to Cédric Corazza)
Fixed missing smtp credentials on the install form

La procédure de mise à jour est la même, soit en utilisant Git, soit en écrasant vos sources par cette archive (votre configuration -filez.ini- restera intacte).

Filez 2.0

Arnaud Didry — Wed, 07 Jul 2010 20:24:57 +0000

Quatre mois après sa première beta FileZ est enfin disponible en version stable. Cette version aurait pu sortir plus tôt étant donné qu’elle est chez nous en production depuis le mois de mars mais je voulais m’assurer qu’elle soit suffisamment documentée de stable avant d’en faire la publicité.

Vous pouvez donc simplement remplacer vos sources par le contenu de cette archive : http://github.com/UAPV/FileZ/tarball/2.0.0

Si vous utilisiez git, il vous suffit de faire

git fetch
git checkout 2.0.0

Attention : Pour simplifier l’installation, les directive PHP relatives à la taille des fichiers uploadés sont maintenant dans le fichier .htaccess; Il est donc possible que la mise à jours altère la configuration de votre fichier php.ini ou de votre virtual host. Pensez à modifier le fichier .htaccess.

La roadmap pour la version 2.1 reprend les fonctionnalités qui ont été le plus demandées :

Création d’invitations pour les personnes ne possédant pas de compte
Interface d’administration
- Gestion de groupes d’utilisateurs
- Gestion du quota par groupes d’utilisateurs ou utilisateur
- Stats par groupe d’utilisateurs

J’essaierai également d’inclure petit à petit certaines propositions d’amélioration.

Cette première version stable sera l’occasion de mettre à jour la fiche Plume dédiée à FileZ. Je serais donc pour cela très intéressé de connaître les établissements ou entreprises ayant mis en production FileZ afin d’accompagner la fiche de quelques exemples d’utilisation. Merci de me contacter par email ou par la liste de diffusion.

Merci encore pour vos tests et contributions !

Comment utiliser Git

Arnaud Didry — Wed, 07 Jul 2010 19:07:56 +0000

Comme promis, nous allons dans ce billet donner une rapide introduction à l’utilisation de Git pour les administrateurs système souhaitant gérer les mises à jour de leurs installations, ainsi que pour les contributeurs dans une seconde partie.

Utilisation du dépôt pour maintenir facilement votre installation

Première récupération des sources

Vous voulez récupérer les sources de FileZ ou RdvZ avec Git et vous avez bien raison, voici donc quelques explications. FileZ et RdvZ sont des projets appartenant à l’utilisateur UAPV sur GitHub, vous pouvez donc les voir à cette adresse : http://github.com/UAPV. En consultant la page de ces projets, vous pouvez récupérer l’URL du dépôt qui s’initialise comme ceci :

git clone git://github.com/UAPV/RdvZ.git rdvz

Vous voilà donc avec une copie du dépôt courant sur votre machine !

Choisir la version utilisée

Hormis si vous souhaitez tester une nouvelle fonctionnalité, il est déconseillé de se placer sur la dernière modification envoyée par un développeur. Il sera préférable d’utiliser un tag ou une branche pour s’assurer de la stabilité de votre installation. Nos dépôt sont (seront) organisé de la manière suivante :

Chaque version mineure (ex: 2.0, 2.1) possèdera sa branche
Chaque version de maintenance (ex: 2.0.1, 2.0.2) sera tagguée.

Choisir un branche vous permettra de récupérer les dernières corrections de bug tandis que les tags vous permettront de choisir plus finement votre version. Utiliser une des deux commandes suivantes pour lister les branches ou tags :

git branch
git tag

Il suffit ensuite d’utiliser la commande “git checkout” pour se déplacer dans l’historique du dépôt :

git checkout 2.0 # pour la branche 2.0 par exemple
git checkout 2.0.1 # pour le tag 2.0.1

Mettre à jour vos sources

Nos applications libres évoluent selon vos contributions et nos idées, de nouvelles versions incluant des corrections de bugs ou des nouvelles fonctionnalités sont mises en ligne assez souvent. Si vous avez suivi l’étape précédente et que vous avez un dépôt local, vous n’avez qu’à taper cette commande pour récupérer les dernières mises à jour :

git fetch

Tous les commits qui ont eu lieu sont récupérés et un résumé des changements, nouveaux tags ou branches est affiché. Pensez à faire un checkout pour vous déplacer vers ces nouveaux tags ou branches.

Contribuer

Git apporte de nombreuse fonctionnalités qu’il n’est pas évident de prendre en main lorsqu’on vient d’un gestionnaire plus classique comme Svn. La difficulté principale consiste à se détacher des concepts plutôt simples de Svn pour visualiser clairement la notion d’arbre décentralisé. Des très bonnes lectures pour commencer et comprendre le fonctionnement interne des branches et dépôts distant sont les livres ProGit disponible gratuitement et Git Community Book. Le site GitRef.org vous servira ensuite de référence pour vous accompagner au quotidiens.

Forker un dépôt

Un des grands intérêts de GitHub est de permettre le “fork” de dépôts. Il s’agît en réalité d’effectuer une copie publique d’un projet qui va vous appartenir et que vous allez pouvoir modifier à volonté. Une fois les modifications effectuées, il est possible de demander au développeur originel du projet si les changements peuvent être intégrés au projet principal grâce à un “pull request”. L’intérêt de cette pratique est évident dans le cas de projets open source appelant à la contribution communautaire comme les notres. Les paragraphes suivants vont essayer de décrire la ligne de conduite couramment utilisée dans les projet git, il est important de la suivre pour faciliter l’intégration future de votre travail.

Git workflow

La suite de ce tutoriel va présenter une des solutions “best practice” pour contribuer à un projet en utilisant Git.

“Branchez”

Créer une branche est simple et léger sous git, il ne faut pas s’en priver, cela permettra de distinguer facilement votre travail pour qu’il soit évalué par l’intégrateur. Ce type de branche est également appelé “topic branch”

git checkout -b new_feature

Vous pouvez alors commencer votre travail en commitant régulièrement.

git add modified_file.php
git commit -m "Fixed  foobar function..."

“Rebasez”

Pour faciliter le travail de l’intégrateur nous allons lui éviter d’éventuels conflits en utilisant la commande “rebase”. Cette commande a pour effet de réorganiser votre branche “new_feature” sur la dernier commit du dépôt original. Ainsi au lieu d’avoir la configuration suivante (X,Y,Z sont vos commit sur votre topic branche) :

A--B--C--D--E--F
       \
        X--Y--Z

Vous obtiendrez ceci après un rebase :

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

Pour réaliser cette opération il faut d’abord récupérer les derniers commits du projet original dans votre dépôt à l’aide d’une “remote branch”. Nous appelerons cette branche “upstream” :

git checkout master # On se replace sur la branche principale de notre fork
git remote add upstream git://github.com/UAPV/FileZ.git
git pull upstream master # On récupère les dernières modifs dans la branche principale du fork
git checkout new_feature # On peut retourner sur notre feature branch

On peut alors réorganiser nos commits sur la tête de la branche “master” :

git rebase master

En ajoutant l’option “-i” à commande précédente il est également possible de fusionner les commits X, Y, Z en un seul. En tapant “git rebase -i master” un éditeur s’ouvrira; Remplacez alors tous les “pick” SAUF le premier par des “squash”. Vous obtiendrez alors un historique plus simple pour l’intégrateur :

 A--B--C--D--E--F--XYZ

Attention, la commande rebase est à éviter sur des commit ayant déjà été partagés et sur lesquels d’autres personnes ont basé leurs modifications; De la même manière que Marty dans “Retour vers le futur”, il faut être prudent.

Partagez

La dernière étape consiste à rendre visible votre travail en l’envoyant sur github :

git push origin new_feature

Vous pouvez maintenant effectuer un “pull request” sur github pour notifier le mainteneur du projet que votre patch est prêt.

Ce tutoriel n’aurait certainement pas vu le jour si la documentation de contribution de Symfony2 était sortie quelques jours plus tôt. Leurs explications sont en effet plus détaillées et correspond exactement à la marche à suivre que nous vous conseillons d’adopter. Toutefois, il est important de lire un minimum de documentation pour réussir à perdre les réflexes de subversion et comprendre les branches de Git.

FileZ : dernière ligne droite

Arnaud Didry — Wed, 30 Jun 2010 14:11:59 +0000

Filez a subi plusieurs corrections de bugs depuis la deuxième version beta, un seul était majeur, mais la plupart étaient mineurs et n’ont pas gêné notre instance en production. Merci pour vos tests et vos nombreux retours.

Une fonctionnalité a également était ajoutée grâce à la contribution de Bertrand Lecervoisier. Celle ci permet d’utiliser le paquet PECL ProgressUpload lorsqu’il n’est pas possible d’installer APC sur les serveurs en production. Pour cela, installez la librairie ProgressUpload en suivant la documentation au bas de cette page, puis modifiez votre fichier filez.ini et ajoutez la ligne suivante dans la section [app]

progress_monitor=Fz_UploadMonitor_ProgressUpload

J’aurais donc besoin de votre aide pour tester cette version avant la date de distribution de la version finale de FileZ-2.0 qui sera mercredi 7 juillet.

Pour mettre à jour, remplacez simplement vos sources par cette archive. Pour les personnes utilisant le svn de sourcesup, il vous faudra passer au dépôt git ou utiliser le svn de github si vous ne pouvez pas installer git.

Vous trouverez le changelog complet sur la page github.

Filez et Rdvz déménagent

Arnaud Didry — Fri, 25 Jun 2010 14:11:14 +0000

Le code et les tickets de Filez et Rdvz montent finalement dans la barque de GitHub qui accueille maintenant une part importante de la communauté open source. Ce choix ne s’est pas fait pour suivre la mode actuelle mais parce que nous pensons que les gestionnaires de version décentralisés tels que Git sont de véritables moteurs pour des projets open source.

Git est un gestionnaire de version décentralisé, à l’inverse de Subversion ou CVS par exemple. Cela permet à chacun de travailler à son rythme, de façon désynchronisée des autres développeurs ; les changements effectués restent donc en local jusqu’au moment où l’on choisit de les propager sur le dépôt. Cette organisation décentralisée favorise l’appropriation du code par ses utilisateurs, permettant ainsi à chacun, qu’on appartienne au projet ou non, de copier et modifier le code source sans pour autant s’en écarter, laissant la place à de futures synchronisations ou remontées de code vers le dépôt parent.

Le deuxième argument motivant ce déménagement est la simplicité et le côté accueillant de l’interface de GitHub. Nous espérons que l’adoption de cette nouvelle forge favorisera le recueil de vos différentes suggestions et problèmes. En effet depuis quelques temps c’est ce blog qui sert de support développeur et nous voudrions centraliser ce support à un seul endroit : le gestionnaire de tickets Github.

Voici les principaux liens concernant RdvZ :

Concernant FileZ :

Un futur billet présentera la procédure à suivre pour maintenir et partager votre propre copie de FileZ ou RdvZ. En attendant voici quelques liens sur git :

GitHub fournissant un accès svn en lecture seule, les dépôts hébergés sur sourcesup.org vont progressivement disparaître. Il est donc conseillé de migrer vos copies vers Git si possible ou vers sur les nouveaux dépôts svn : http://svn.github.com/UAPV/RdvZ.git et http://svn.github.com/UAPV/FileZ.git

Pour FileZ la procédure à suivre est la suivante (à adapter) :

sauvegarder le fichier config/filez.ini (et vos fichiers uploadés et/ou logs s’il sont dans le répertoire racine de FileZ)
supprimer les sources de FileZ : rm * -rf; rm .svn -rf
cloner le dépôt GitHub : git clone git://github.com/UAPV/FileZ.git .
restaurer le fichier config/filez.ini, vos fichiers uploadés et/ou logs (avec les droits d’écriture pour le serveur web)

Pour RdvZ la manipulation est assez similaire :

sauvegardez les fichiers apps/frontend/config/security.yml, apps/frontend/config/routing.yml, apps/frontend/config/filters.yml et config/databases.yml
supprimez les sources de RdvZ : rm -rf * .svn
clonez le dépôt GitHub : git clone git://github.com/UAPV/RdvZ.git .
restaurez les fichiers apps/frontend/config/security.yml, apps/frontend/config/routing.yml, apps/frontend/config/filters.yml et config/databases.yml en les remettant à leurs emplacements originaux
lancez un php symfony cc pour supprimer le cache

Notez qu’il est très déconseillé d’utiliser le dépôt Subversion proposé par GitHub, Subversion ne gérant pas les liens symboliques de la même façon que Git, ceux-ci sont complètement détruits lorsqu’on récupère les sources à partir du dépôt Subversion de GitHub.