Re: recherche sponsor pour nouveaux paquets [OBM]
Yves-Alexis Perez a écrit : L'avantage de l'API c'est que quand même les données sont cohérentes d'un point de vue applicatif. Après effectivement faut gérer les upgrades de façon cohérente aussi, mais ça me parait moins chaud qu'avec du SQL « pur ». Mais bon c'est ptet une mauvaise idée. Ben oui, mais le problème c'est que ton api est moins stable dans le temps qu'un bon vieux sql, en gros ton api fait l'upgrade aujourd'hui, mais dans 6 mois quand tu auras oublié, que ton api sert aussi à l'upgrade entre 2 vielles versions tu jetteras le bout de code qui fera foirer l'upgrade du gars qui upgrade tous les ans. du coup ton api n'est plus cohérente, tu peux me faire confiance on a aussi essayé ;-) Eventuellement il faudrait garder les apis de chaque upgrade, pas forcement simple. Tu auras du mal à faire renter le minig d'obm dans debian car il te faudra surement gwt, et gwt pour lequel j'ai posé un ITP est difficilement compilable, mais faut pas se décourager, qqn y arrivera bien un jour... Arg/ Si tu as du temps, faudrait aller demander aux dev de gwt de nous dire comment ils font, de plus la dernière fois que j'ai essayé il manquait au moins un bout de lib de dev dans Iceweasel Sinon, sur les problèmes de conf avec ldap/exim/.. on a exactement les mêmes problèmatiques dans gforge. Avec le temps les choses s'améliorent et les paquets fournissent de plus en plus les moyens, de modifier proprement leur conf. Mhmh, si les problématiques se ressemblent ça me paraitrait intéressant d'avoir un peu plus d'avis des gforgeux (Roland ? :) ) et voir s'ils ont déjà un état de l'art sur ce genre de choses. Je vois au moins une problèmatique commune qui est la gestion des utilisateurs, voir des groupes. Externaliser le problème avec LDAP, est probablement une solution, pour mettre la gestion de différentes briques en commun, mais cela pose des fois de problème de perf, chaque appli aime bien aussi avoir accès au nom de l'utilisateur, donc tu mets ça dans une table et ensuite tu te cognes les problèmes de synchro avec l'annuaire. On pourrait en discuter des heures, c'est pas le boulot qui manque entre les nss, les pam et autres ce serait interessant d'etre capable de proposer un ensemble minimun cohérent dans un premier temps, on doit se rencontrer entre forgeux en Janvier sur Paris, peut être une bonne occasion d'en discuter et d'avancer. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Yves-Alexis Perez wrote: On Wed, May 07, 2008 at 11:29:48AM +0200, Sylvain Garcia wrote: Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. […] Actuellement les paquets proposés ne configurent pas tout un OBM, mais seulement la BD, et la configuration d'apache. On a donc accès à beaucoup de fonctionnalité d'OBM dans un premier temps. Mon but est d'intégrer le reste petit à petit; la gestion de l'annuaire LDAP, de Samba, et surtout de la messagerie. Où ça en est, au final ? Cheers, Pour l'instant, rien n’est fait, c'est toujours au point mort. En fait, j'ai eu pas mal de discussion sur la ml debian mentors (et aussi sur celle-ci ;-) ). Nous ne sommes pas parvenus à nous mettre d'accord sur le découpage des paquets, des deux cotés nous comprenions les points de vue, mais on a rien fait ensemble.Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 OBM - La messagerie collaborative - http://www.obm.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On jeu, 2008-11-13 at 14:18 +0100, Sylvain GARCIA wrote: Pour l'instant, rien n’est fait, c'est toujours au point mort. En fait, j'ai eu pas mal de discussion sur la ml debian mentors (et aussi sur celle-ci ;-) ). Nous ne sommes pas parvenus à nous mettre d'accord sur le découpage des paquets, des deux cotés nous comprenions les points de vue, mais on a rien fait ensemble. Et en gros le statut final c'était quoi ? Et quelles étaient les dissensions ? (un rapide résumé des discussions éparpillées, genre) Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. À un moment il faudrait prendre une décision aussi :) Si c'est rapport à la policy Debian c'est sur que y'a pas vraiment moyen de transiger (pour de bonnes raisons). Pour le reste… Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Donc ceux de deb.obm.org il vaut mieux pas les utiliser, ils sont « crapy » ? Ceux de Ubuntu sont comment ? (je veux bien qu'ils aient des règles moins strictes mais tout de même) Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. Argh. De mon côté je serais intéressé éventuellement intéressé par OBM, mais ça serait clairement sous réserve d'avoir des paquets propres et bien intégrés à la distrib. Donc pas des paquets « crapy » et pas des paquets Ubuntu à peine remodelés :) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: recherche sponsor pour nouveaux paquets [OBM]
Quoting Yves-Alexis Perez: On jeu, 2008-11-13 at 14:18 +0100, Sylvain GARCIA wrote: Pour l'instant, rien n’est fait, c'est toujours au point mort. En fait, j'ai eu pas mal de discussion sur la ml debian mentors (et aussi sur celle-ci ;-) ). Nous ne sommes pas parvenus à nous mettre d'accord sur le découpage des paquets, des deux cotés nous comprenions les points de vue, mais on a rien fait ensemble. Et en gros le statut final c'était quoi ? Et quelles étaient les dissensions ? (un rapide résumé des discussions éparpillées, genre) Alors, pour commencer tu trouveras l'architecture tous les paquets (de deb.obm.org) sur cette page: http://www.obm.org/doku.php?id=debian_etch Le problème vient de l'utilisation du paquet de obm-conf avec obm-storage qui utilise dbconfig-common. J'explique le topo: * L'architecture des paquets (au complet) permettent dinstaller un OBM sur un seul serveur mais aussi sur plusieurs serveur répartis. Le but étant de répondre correctement au questions et hop! j'ai un OBM installé sur 4,5,.. serveurs qui fonctionne out of the box. Dans le schéma tu remarqueras que chaque paquets (ou presque) dépend de obm-conf, car nous avons centraliser la conf dans un paquets. Le problème et que dbconfig-common est capable de générer le fichier de conf, mais je ne l'utilise pas. * pourquoi je ne l'utilise pas? tu remarquera que obm-storage dépend de obm-core qui est en fait le code php d'OBM. Cela est necessaire lors d'upgrade de BD. Lors d'upgrade il arrive que nous utilisions les API ou je devrait dire des bouts de code d'OBM afin de manipuler les datas du calendrier, des contacts, du CRM ou autres. *si je génère la configuration avec obm-storage alors j'aurais obligatoirement a installer tout le code php sur tous les serveur, ainsi que le SGBD... *une solution possible: jouer avec le type de dépendances, mais cela oblige a devoir installer au préalable le SGBD, et donc le simple aptitude install obm ne fonctionnera pas out of the box petite précision le paquet obm est un meta paquet qui tire le tout. Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. À un moment il faudrait prendre une décision aussi :) Si c'est rapport à la policy Debian c'est sur que y'a pas vraiment moyen de transiger (pour de bonnes raisons). Pour le reste… Non, a priori pour la policy debian je respecte (enfin j'espère) ;) Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Donc ceux de deb.obm.org il vaut mieux pas les utiliser, ils sont « crapy » ? Ceux de Ubuntu sont comment ? (je veux bien qu'ils aient des règles moins strictes mais tout de même) hummm.. j'ai vu passé un troll.. passons.. (ps: je suis utilisateur de la sid ;-) ) Attention, petite méprise :D une partie des paquets sur obm.org ne respecte pas la policy debian et j'en suis conscient et je ne peux pas faire autrement pour l'instant, petit aperçu: - j'explose des fichiers de conf - le vhost par défaut d'apache et dégager, j'en met un en https.(il me semble que dans la lenny ou la ubuntu on a maintenant un site-enable pour https, donc se sera a corriger) - lintian m'insulte et ça déjà c'est pas bien. Il y a des pistes pour améliorer tous ça, et je le fait petit a petit, exemple du vhost,. il y a aussi openldap qui par exemple dans ubuntu passe par défaut en cn=config (je sais pas pour debian) Le travail que j'effectue sur les paquets d'ubuntu est réparcuter sur les paquet d'obm.org, et vis versa. Cependant le paquet Ubuntu ont donc été alléger de tout les truc crapy que j'ai fais ( enfin j'espère qu'il en reste pas :D) Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. Argh. De mon côté je serais intéressé éventuellement intéressé par OBM, mais ça serait clairement sous réserve d'avoir des paquets propres et bien intégrés à la distrib. Donc pas des paquets « crapy » et pas des paquets Ubuntu à peine remodelés :) sauf si les paquet ubuntu sont correcte non? ou a remodeler? :-D Cheers, -- Yves-Alexis Mon but est d'intégrer au fur et a mesure dans les distribs (Debian ET Ubuntu) tous les composants d'OBM. Cela est difficile a gérer car OBM a besoin d'une configuration spécifique pour chaque services, et je n'ai pas trouver d'exemple d'autres logiciels (dans Debian) qui utilise par exemple cyrus avec une conf spécifique, et c'est un peu la même chose pour tous les services qu'obm a besoin. Je suis pas DD, je ne suis pas non plus MOTU, juste un membre de la team OBM qui souhaite diffuser au mieux OBM pour tous le monde. voilà :D -- Sylvain Garcia [EMAIL PROTECTED] -- To
Re: recherche sponsor pour nouveaux paquets [OBM]
On jeu, 2008-11-13 at 23:44 +0100, Sylvain GARCIA wrote: Quoting Yves-Alexis Perez: Et en gros le statut final c'était quoi ? Et quelles étaient les dissensions ? (un rapide résumé des discussions éparpillées, genre) Alors, pour commencer tu trouveras l'architecture tous les paquets (de deb.obm.org) sur cette page: http://www.obm.org/doku.php?id=debian_etch Le problème vient de l'utilisation du paquet de obm-conf avec obm-storage qui utilise dbconfig-common. J'explique le topo: Ouais visiblement c'est de toute façon pas trivial. * L'architecture des paquets (au complet) permettent dinstaller un OBM sur un seul serveur mais aussi sur plusieurs serveur répartis. Le but étant de répondre correctement au questions et hop! j'ai un OBM installé sur 4,5,.. serveurs qui fonctionne out of the box. Dans le schéma tu remarqueras que chaque paquets (ou presque) dépend de obm-conf, car nous avons centraliser la conf dans un paquets. Le problème et que dbconfig-common est capable de générer le fichier de conf, mais je ne l'utilise pas. * pourquoi je ne l'utilise pas? tu remarquera que obm-storage dépend de obm-core qui est en fait le code php d'OBM. Cela est necessaire lors d'upgrade de BD. Lors d'upgrade il arrive que nous utilisions les API ou je devrait dire des bouts de code d'OBM afin de manipuler les datas du calendrier, des contacts, du CRM ou autres. *si je génère la configuration avec obm-storage alors j'aurais obligatoirement a installer tout le code php sur tous les serveur, ainsi que le SGBD... Hmhm, et tout faire à partir d'un truc central (celui sur lequel obm-conf est installé, quitte à ce qu'il ait aussi besoin du code php), et faire en remote les upgrades de DB, c'est pas possible ? *une solution possible: jouer avec le type de dépendances, mais cela oblige a devoir installer au préalable le SGBD, et donc le simple aptitude install obm ne fonctionnera pas out of the box petite précision le paquet obm est un meta paquet qui tire le tout. Je vois pas très bien comment ça peut marcher sur n serveurs de toute façon. Dans ces cas là, on fait pas apt-get install obm sur chacun des serveurs, on installe juste ce qu'il faut sur chacun des serveurs de la boucle ? (enfin je connais pas trop le fonctionnement en haute dispo des divers services) Attention je ne dis pas:bouu Debian ils ont pas voulu de moi, je dis juste qu'il y a encore des discussions a avoir si les paquets ne plaisent pas comme ils sont actuellement. Cela dit, comme je l'ai déjà dit, je ne suis pas fermé et les discussions peuvent se réouvrir. À un moment il faudrait prendre une décision aussi :) Si c'est rapport à la policy Debian c'est sur que y'a pas vraiment moyen de transiger (pour de bonnes raisons). Pour le reste… Non, a priori pour la policy debian je respecte (enfin j'espère) ;) C'est juste une histoire d'utiliser ou non dbconfig-common ? Je suis pas extrèmement au courant de ces choses là. C'est sur que c'est mieux d'utiliser cet outil, mais qu'est-ce qu'on perd à ne pas le faire ? Les paquets que je voulais intégrer a debian sont en fait exactement les même que ce de Ubuntu(et pas ceux de deb.obm.org), car je suis conscient que le reste des paquets est vraiment crapy pour l'instant. Donc ceux de deb.obm.org il vaut mieux pas les utiliser, ils sont « crapy » ? Ceux de Ubuntu sont comment ? (je veux bien qu'ils aient des règles moins strictes mais tout de même) hummm.. j'ai vu passé un troll.. passons.. (ps: je suis utilisateur de la sid ;-) ) Non mais ta phrase était ambigüe en fait. Je sais pas quels packages sont « crapy », si c'est ceux de deb.obm.org ou ceux d'Ubuntu. Attention, petite méprise :D une partie des paquets sur obm.org ne respecte pas la policy debian et j'en suis conscient et je ne peux pas faire autrement pour l'instant, petit aperçu: - j'explose des fichiers de conf - le vhost par défaut d'apache et dégager, j'en met un en https.(il me semble que dans la lenny ou la ubuntu on a maintenant un site-enable pour https, donc se sera a corriger) - lintian m'insulte et ça déjà c'est pas bien. Il y a des pistes pour améliorer tous ça, et je le fait petit a petit, exemple du vhost,. il y a aussi openldap qui par exemple dans ubuntu passe par défaut en cn=config (je sais pas pour debian) ha oui non là c'est sur que ceux là, c'est délicat :) Le travail que j'effectue sur les paquets d'ubuntu est réparcuter sur les paquet d'obm.org, et vis versa. Cependant le paquet Ubuntu ont donc été alléger de tout les truc crapy que j'ai fais ( enfin j'espère qu'il en reste pas :D) Je dirais que t'as intérêt à faire ça petit à petit, et à publier ce que tu fais au fur et à mesure, histoire qu'éventuellement des gens puissent t'aider à monter ça. Si de ton coter, cela t'intéresse d'intégrer OBM dans la Debian je suis ouvert a toute remarque. Argh. De mon côté je serais intéressé éventuellement
Re: recherche sponsor pour nouveaux paquets [OBM]
On ven, 2008-11-14 at 01:42 +0100, Christian Bayle wrote: Juste une remarque, utiliser l'api est d'expérience une mauvaise idée, car l'api évolue et du coup tes upgrades finissent par foirer chez les malheureux qui ne migrent pas avec la même combinaison api-base que toi, donc soit tu fais du bon vieux sql soit tu gardes les versions des api que tu utilises à l'upgrade. Tu as aussi intérêt à upgrader sur les transactions et aussi à garder une version dans la base. Tu peux jeter un oeil au db-upgrade.pl du paquet gforge pour un posgresql + transaction qui ne nous a jamais pourri une base. L'avantage de l'API c'est que quand même les données sont cohérentes d'un point de vue applicatif. Après effectivement faut gérer les upgrades de façon cohérente aussi, mais ça me parait moins chaud qu'avec du SQL « pur ». Mais bon c'est ptet une mauvaise idée. Tu auras du mal à faire renter le minig d'obm dans debian car il te faudra surement gwt, et gwt pour lequel j'ai posé un ITP est difficilement compilable, mais faut pas se décourager, qqn y arrivera bien un jour... Arg/ Sinon, sur les problèmes de conf avec ldap/exim/.. on a exactement les mêmes problèmatiques dans gforge. Avec le temps les choses s'améliorent et les paquets fournissent de plus en plus les moyens, de modifier proprement leur conf. Mhmh, si les problématiques se ressemblent ça me paraitrait intéressant d'avoir un peu plus d'avis des gforgeux (Roland ? :) ) et voir s'ils ont déjà un état de l'art sur ce genre de choses. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : OoO En cette soirée bien amorcée du jeudi 29 mai 2008, vers 22:08, Sylvain GARCIA [EMAIL PROTECTED] disait: Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un ensemble d'API ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les API disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D ) Tous ces scripts de mise à jour peuvent être exécutés à distance, non ? Il y a bien une partie d'OBM qui constitue le coeur et qui va être le composant central de la solution. C'est ce coeur qui doit s'occuper de la base de données (qui n'est pas optionnelle). L'installation du paquet obm-core va donc installer avec dbconfig-common la base de données sur un serveur distant (qui ne contient qu'une base de données) et sa mise à jour va exécuter des scripts PHP pour mettre à jour la base de données. Mais bon, du coup, cela remet un peu en cause le paquet obm-ui qui s'il dépend d'obm-core et est installé sur une autre machine va aussi vouloir configurer une base de données, ce qui va perdre un peu l'utilisateur. Mais comme pour le moment, il n'existe pas d'autres paquets, il suffit d'intégrer obm-ui (un fichier de configuration pour Apache) dans obm-core. hum, ouai, je vais réflechir a cela avec l'équipe de dev OBM. Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Perso, je ne pense pas qu'il faut se projeter autant dans l'avenir. P'tet que le découpage paraîtra plus évident une fois qu'il y aura réellement un composant qui devra s'installer sur une autre machine. La situation actuelle, c'est qu'il y a deux paquets (obm-ui et obm-storage) qui sont quasiment vides en dehors des scripts de postinst (dbconfig-common inclus). J'ai déjà eu le cas avec uuwaf-preferences qui se contente de configurer une base MySQL pour être utilisée avec uuwaf (un peu comme obm-storage donc). Cependant : - uuwaf-preferences est optionnel - la base de données est tellement générique qu'elle peut utiliser directement la couche d'abstraction du framework ; elle n'a donc pas de code propre à elle Il me semble que dans obm, le premier point n'est pas vérifié. Pour le second, n'y-a-t'il pas dans obm-core du code qui n'est utile que pour obm-storage ? Découper un logiciel en plusieurs paquets a l'avantage de la modularité (ce que tu cherches à obtenir). Toutefois, il y a aussi quelques gros inconvénients : - les utilisateurs peuvent rapporter des bugs contre chacun des paquets, ne pas rapporter le bug contre le bon paquet, ne pas consulter les bugs des autres paquets (on a fait l'erreur de couper roundcube en deux paquets, ce qui n'a finalement pas apporté grand chose, mais du coup, les utilisateurs sont un peu perdus) - les mises à jour sont plus difficiles, il faut faire attention en transférant les fichiers d'un paquet à un autre, il faut faire attention aux versions, on peut casser une installation parce qu'un des paquets n'a pas réussi à s'installer et le système sera alors dans un état bancal (ce peut aussi être le cas avec un seul paquet, mais c'est généralement moins grave) - un paquet ne peut pas modifier les fichiers de configuration d'un autre paquet (ce que tu résous en ayant deux mécanismes de configuration de la base de données pour obm-core, l'une qui pose les questions, l'autre qui récupère les réponses de obm-storage si elles sont présentes ; il me semble d'ailleurs que ce n'est pas garanti que les scripts de postinst vont s'exécuter comme tu l'entends vu qu'il y a une dépendance circulaire. Par contre, il est relativement aisé de couper en deux un package (même s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu essaies de faire ici). Ok, Bon on a eut beaucoup
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : [...] Par contre, il est relativement aisé de couper en deux un package (même s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu essaies de faire ici). Et dans un autre message : Suite a nos conversation et vos remarques, j'ai cherché un moyen de regrouper les paquets. J'ai discuter avec Yann Dirson, un nouveaux collaborateur de ma société et aussi DD. Il en pense quoi du découpage ? :) Je l'ai juste croisé dans un couloir et on a discuté en vitesse. Il a pas encore jeter un oeuil aux paquets. -- No fortunes found -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Thu, 05 Jun 2008, Sylvain GARCIA wrote: ok, mais là j'ai besoin de plus d'explication. Sur mon paquet obm-storage, j'ai le choix de l'installer soit en frontend, soit en backend, je met un recommends sur mysql-server. Si j'utilise aptitude ( suivant la conf biensur) il va me tirer mysql-server même si je ne veut que le frontend. aptitude install obm-conf mysql-server- ou alors taper - mysql-server lors de la confirmation de la liste des paquets à installer. Ce n'est vraiment pas compliqué. Maintenant je n'ai pas dit que c'était forcément la solution à retenir, à toi de juger en fonction des éléments que l'on t'a donné. A+ -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
OoO En cette soirée bien amorcée du jeudi 29 mai 2008, vers 22:08, Sylvain GARCIA [EMAIL PROTECTED] disait: Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un ensemble d'API ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les API disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D ) Tous ces scripts de mise à jour peuvent être exécutés à distance, non ? Il y a bien une partie d'OBM qui constitue le coeur et qui va être le composant central de la solution. C'est ce coeur qui doit s'occuper de la base de données (qui n'est pas optionnelle). L'installation du paquet obm-core va donc installer avec dbconfig-common la base de données sur un serveur distant (qui ne contient qu'une base de données) et sa mise à jour va exécuter des scripts PHP pour mettre à jour la base de données. Mais bon, du coup, cela remet un peu en cause le paquet obm-ui qui s'il dépend d'obm-core et est installé sur une autre machine va aussi vouloir configurer une base de données, ce qui va perdre un peu l'utilisateur. Mais comme pour le moment, il n'existe pas d'autres paquets, il suffit d'intégrer obm-ui (un fichier de configuration pour Apache) dans obm-core. Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Perso, je ne pense pas qu'il faut se projeter autant dans l'avenir. P'tet que le découpage paraîtra plus évident une fois qu'il y aura réellement un composant qui devra s'installer sur une autre machine. La situation actuelle, c'est qu'il y a deux paquets (obm-ui et obm-storage) qui sont quasiment vides en dehors des scripts de postinst (dbconfig-common inclus). J'ai déjà eu le cas avec uuwaf-preferences qui se contente de configurer une base MySQL pour être utilisée avec uuwaf (un peu comme obm-storage donc). Cependant : - uuwaf-preferences est optionnel - la base de données est tellement générique qu'elle peut utiliser directement la couche d'abstraction du framework ; elle n'a donc pas de code propre à elle Il me semble que dans obm, le premier point n'est pas vérifié. Pour le second, n'y-a-t'il pas dans obm-core du code qui n'est utile que pour obm-storage ? Découper un logiciel en plusieurs paquets a l'avantage de la modularité (ce que tu cherches à obtenir). Toutefois, il y a aussi quelques gros inconvénients : - les utilisateurs peuvent rapporter des bugs contre chacun des paquets, ne pas rapporter le bug contre le bon paquet, ne pas consulter les bugs des autres paquets (on a fait l'erreur de couper roundcube en deux paquets, ce qui n'a finalement pas apporté grand chose, mais du coup, les utilisateurs sont un peu perdus) - les mises à jour sont plus difficiles, il faut faire attention en transférant les fichiers d'un paquet à un autre, il faut faire attention aux versions, on peut casser une installation parce qu'un des paquets n'a pas réussi à s'installer et le système sera alors dans un état bancal (ce peut aussi être le cas avec un seul paquet, mais c'est généralement moins grave) - un paquet ne peut pas modifier les fichiers de configuration d'un autre paquet (ce que tu résous en ayant deux mécanismes de configuration de la base de données pour obm-core, l'une qui pose les questions, l'autre qui récupère les réponses de obm-storage si elles sont présentes ; il me semble d'ailleurs que ce n'est pas garanti que les scripts de postinst vont s'exécuter comme tu l'entends vu qu'il y a une dépendance circulaire. Par contre, il est relativement aisé de couper en deux un package (même s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu essaies de faire ici). Et dans un autre message : Suite a nos conversation et vos remarques, j'ai cherché un moyen de regrouper les paquets. J'ai
Re: recherche sponsor pour nouveaux paquets [OBM]
On Wed, 2008-05-28 at 21:16 +0200, Vincent Bernat wrote: OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55, Cedric Delfosse [EMAIL PROTECTED] disait: En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui). En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus. Vincent, est-ce la même chose qui te gênait dans le packaging ? Un peu. En fait, obm-storage se contente de configurer la base de données avec dbconfig-common. Mais si obm le faisait, ce serait pareil : dbconfig-common sait configurer une base distante. obm-ui se contenter d'installer une conf d'Apache. obm pourrait le faire de la même façon. Maintenant, Sylvain a donné sur debian-mentors@ quelques arguments dont un schéma pour expliquer les dépendances. Du coup, je suis un peu moins catégorique qu'avant, mais ça me semble toujours bizarre (je trouve que tout devrait être dans le même package). Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Re, Suite a nos conversation et vos remarques, j'ai cherché un moyen de regrouper les paquets. J'ai discuter avec Yann Dirson, un nouveaux collaborateur de ma société et aussi DD. Je me suis penché sur le raprochement des paquet obm-conf et obm-storage. Le but étant de généré le fichier de conf par dbconfig-common soit en backend ou en frontend, comme-ça, soit on install la BD soit on a juste le fichier de conf. J'ai donc modifier les paquet pour que cela fonctionne. Et là je me suis souvenu de pourquoi je n'ai pas utilisé cela à l'origine: Pour re-situer, obm-conf est requis par presque tous les autre paquets, c'est simplement un fichier de conf. Le problème c'est que si je regroupe obm-conf avec obm-storage, je n'aurais pas de problème pour généré le fichier de conf correctement.MAIS dans le cas d'une installation multiserveur si on a 1 seul paquet pour la conf et la BD, ce même paquet doit avoir une dépendance sur Mysql, sauf si on l'install en Backend pour avoir seulement le fichier de conf... DOnc cela n'est pas jouable, à la limite on se retrouve avec un paquet obm-frontend et obm-backend ce qui revient au même que obm-conf et obm-storage. Voilà, en attente de vos retour. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Thu, 05 Jun 2008, Sylvain Garcia wrote: généré le fichier de conf correctement.MAIS dans le cas d'une installation multiserveur si on a 1 seul paquet pour la conf et la BD, ce même paquet doit avoir une dépendance sur Mysql, sauf si on l'install en Backend pour avoir seulement le fichier de conf... DOnc cela n'est pas jouable, à la limite on se retrouve avec un paquet obm-frontend et obm-backend ce qui revient au même que obm-conf et obm-storage. Le serveur de BD peut toujours être distant et il n'y a donc pas lieu de mettre une dépendance en dur sur mysql. Des réponses à des questions debconf permettent au paquet de connaître le souhait réel de l'admin et de s'adapter en fonction. A+ -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Thu, 2008-06-05 at 14:39 +0200, Raphael Hertzog wrote: On Thu, 05 Jun 2008, Sylvain Garcia wrote: généré le fichier de conf correctement.MAIS dans le cas d'une installation multiserveur si on a 1 seul paquet pour la conf et la BD, ce même paquet doit avoir une dépendance sur Mysql, sauf si on l'install en Backend pour avoir seulement le fichier de conf... DOnc cela n'est pas jouable, à la limite on se retrouve avec un paquet obm-frontend et obm-backend ce qui revient au même que obm-conf et obm-storage. Le serveur de BD peut toujours être distant et il n'y a donc pas lieu de mettre une dépendance en dur sur mysql. Des réponses à des questions debconf permettent au paquet de connaître le souhait réel de l'admin et de s'adapter en fonction. oui ok, mais si il n'y a pas de dépendance sur mysql, l'installation du paquet en Backend va échoué lors de la création du user et de la BD. En fait je trouve ça un peu louche. Le but étant d'avoir un aptitude install obm et hop ça marche, pour être le plus facilement utilisable. Il est plus pratique de garder l'architecture des paquets actuel, ainsi l'installation est assez facile et fonctionnel dans tous les cas. Si l'on regroupe obm-conf et obm-storage alors il faut enlever la dépendace sur mysql c'est donc une tache de plus a faire par l'admin,( avant d'installer OBM il faut d'abord installer mysql-server) alors que actuellement tous fonctionne. Je précise que je ne fait que exposer mon avis et que je ne suis pas du tout fermé a une réorganisation des paquets. Mais actuellement je pense que pour l'admin qui va installer OBM cela fonctionnera aisément sur un ou plusieurs serveurs. Là je ne voit pas d'avantage a regroupe ces deux paquets. A+ -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Julien Cristau [EMAIL PROTECTED] a écrit : On Thu, Jun 5, 2008 at 14:57:51 +0200, Sylvain Garcia wrote: En fait je trouve ça un peu louche. Le but étant d'avoir un aptitude install obm et hop ça marche, pour être le plus facilement utilisable. Il est plus pratique de garder l'architecture des paquets actuel, ainsi l'installation est assez facile et fonctionnel dans tous les cas. Si l'on regroupe obm-conf et obm-storage alors il faut enlever la dépendace sur mysql c'est donc une tache de plus a faire par l'admin,( avant d'installer OBM il faut d'abord installer mysql-server) alors que actuellement tous fonctionne. C'est pour ça qu'on a inventé le champ 'Recommends'. Julien ok, mais là j'ai besoin de plus d'explication. Sur mon paquet obm-storage, j'ai le choix de l'installer soit en frontend, soit en backend, je met un recommends sur mysql-server. Si j'utilise aptitude ( suivant la conf biensur) il va me tirer mysql-server même si je ne veut que le frontend. C'est donc de tout façon une manip a faire en plus pour l'admin, tandis que la solution actuelle, pas besoin. Donc recommends ou pas c'est pareille. A la limite ce qui serait jouable, c'est de faire 2 paquets: obm-backend et obm frontend, les deux avec les dependances correct l'un avec mysql l'autre sans. Tous les autres paquets on une dépendance sur obm-frontend et obm-backend provides obm-frontend. Enfin là ça devient compliqué pour pas grand chose, qui est déjà fonctionnel. Des avis? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat [EMAIL PROTECTED] a écrit : OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55, Cedric Delfosse [EMAIL PROTECTED] disait: En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui). En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus. Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un ensemble d'API ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les API disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D ) Vincent, est-ce la même chose qui te gênait dans le packaging ? Un peu. En fait, obm-storage se contente de configurer la base de données avec dbconfig-common. Mais si obm le faisait, ce serait pareil : dbconfig-common sait configurer une base distante. obm-ui se contenter d'installer une conf d'Apache. obm pourrait le faire de la même façon. Maintenant, Sylvain a donné sur debian-mentors@ quelques arguments dont un schéma pour expliquer les dépendances. Du coup, je suis un peu moins catégorique qu'avant, mais ça me semble toujours bizarre (je trouve que tout devrait être dans le même package). Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ? Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Comme tu l'as dit, le schéma sur debian.mentors explique l'architecture complète de l'objectif. Tous les paquets du schéma existent, mais ne sont pas intégrable en l'état. L'un des avantages ( ou inconvénients ) d'OBM est que l'on utilise les logiciels fournis par les distributions. Nous n'avons pas notre porpre cyrus ou notre propre postfix; la configuration de ces services est difficile dans le cadre d'une intégration dans Debian (remplacement des fichiers de conf...On en reparlera dans une autre discussion :-D ). Mais j'étudie et cherche une solution pour incorporer le tous. Je pense que commencer par intégrer les paquets actuels serait un bon pas en avant pour permettre ensuite de travailler sur le reste. Comme je l'ai déjà précisé, je suis à l'écoute de toutes vos remarques, notamment sur le découpage du packaging. Cependant pour l'instant, et pour ma part, je ne pense pas qu'un autre découpage des paquets soit possible pour assurer l'objectif final qui est une intégration totale d'OBM. Pour l'instant, tous les arguments que vous m'avez avancé étaient justifiés pour une intégration partielle d'OBM et surtout mono serveur. Mon but est que tout le monde puisse installer un OBM sur une grosse architecture et non seulement sur un seul serveur. Pour une install monoserveur il existe le Meta-paquet OBM qui lui tire tous les autres paquets. L'install reste donc facile pour une installation monoserveur via le paquet OBM mais peut ensuite se faire de façon plus fine en installant seulement les paquets et donc services que l'on veut sur tous nos serveur. Tous les monde est donc content.. ( boutade!) En tous cas, je vous remercie de vos retours, et surtout de cette discussion pour faire avancer le shmilblik. -- NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS -+- Bart Simpson on chalkboard in episode 7F23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Le mardi 27 mai 2008 à 20:36 +0200, Vincent Bernat a écrit : OoO En ce début de soirée du lundi 19 mai 2008, vers 21:03, Cedric Delfosse [EMAIL PROTECTED] disait: je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Si tu es toujours intéressé, n'hésite pas à regarder. Sylvain a refait un package. Je suis toujours un peu gêné par le découpage donc ce serait cool de donner ton avis sur le packaging. C'est sur mentors.debian.net. J'ai pu tester les packages et ils sont fonctionnels. Alors en effet, je trouve dommage que dans le packaging il n'y ait pas une partie purement client, et une partie purement serveur. En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui). En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus. Vincent, est-ce la même chose qui te gênait dans le packaging ? Cédric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
OoO En ce début de soirée du lundi 19 mai 2008, vers 21:03, Cedric Delfosse [EMAIL PROTECTED] disait: je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Si tu es toujours intéressé, n'hésite pas à regarder. Sylvain a refait un package. Je suis toujours un peu gêné par le découpage donc ce serait cool de donner ton avis sur le packaging. C'est sur mentors.debian.net. -- I WILL NOT TEACH OTHERS TO FLY I WILL NOT TEACH OTHERS TO FLY I WILL NOT TEACH OTHERS TO FLY -+- Bart Simpson on chalkboard in episode 9F05 pgpFNYsYnqRky.pgp Description: PGP signature
Re: recherche sponsor pour nouveaux paquets [OBM]
Le mardi 27 mai 2008 à 20:36 +0200, Vincent Bernat a écrit : OoO En ce début de soirée du lundi 19 mai 2008, vers 21:03, Cedric Delfosse [EMAIL PROTECTED] disait: je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Si tu es toujours intéressé, n'hésite pas à regarder. Sylvain a refait un package. Je suis toujours un peu gêné par le découpage donc ce serait cool de donner ton avis sur le packaging. C'est sur mentors.debian.net. Je me mets dessus demain soir. Je n'étais pas très dispo ces derniers temps :S Cédric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
On Mon, 2008-05-19 at 21:03 +0200, Cedric Delfosse wrote: Le mercredi 07 mai 2008 à 11:29 +0200, Sylvain Garcia a écrit : Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Bonjour, je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Cédric J'ai uploader sur mentors.net une nouvelle version, obm_2.1.9-3, qui gère maintenant le fichier de conf /etc/obm/obm_con.ini via ucf. Je pense que les paquets sont maintenant pret a être uploader. Merci pour ta vérification. -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Le mercredi 07 mai 2008 à 11:29 +0200, Sylvain Garcia a écrit : Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Bonjour, je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Cédric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Cedric Delfosse [EMAIL PROTECTED] a écrit : Le mercredi 07 mai 2008 à 11:29 +0200, Sylvain Garcia a écrit : Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Bonjour, je vérifie les paquets et j'uploade dès que possible. Ce serait dommage de ne pas avoir OBM dans Debian ! Cédric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Ah merci!!, par contre j'ai une nouvelle version que j'ai pas encore uploader qui gère le fichier de conf via ucf, attend un peu que je l'upload sur debian mentors :-D, je fais ça demain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recherche sponsor pour nouveaux paquets [OBM]
Sylvain Garcia a écrit : Bonjour, Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Excellente nouvelle ! Je ne suis pas DD, je ne peux donc sponsoriser quoi que ce soit, mais OBM a l'air d'être une solution très intéressante, et disposer de paquets propres réalisés par un développeur amont est toujours une bonne chose. Il y a peu de solution de groupware libre, et leur mise en place est souvent complexe, disposer de paquets maintenus est un vrai plus pour debian je pense. A+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
recherche sponsor pour nouveaux paquets [OBM]
Bonjour, Dans la nouvelle Ubuntu j'ai intégrer OBM, cependant utilisateur de Debian j'aimerai bien voir OBM dans Debian. J'ai uploader les paquets sur mentors.debian.org. Je travail chez AliaSource, société qui édite OBM. Qu'est ce qu'OBM: Open business Management OBM est beaucoup de chose en fait, groupware, CRM, gestion de projet de facturation, ... Actuellement les modules les plus utilisés sont les modules de groupware. OBM met a disposition gestion de calendrier partagé en Ajax, gestion des contacts, synchronisation possible avec Outlook, thunderbird +lightning, PDA. OBM gère la messagerie des utilisateurs, liste de diffusion, boite aux lettres partagées. OBM a été choisi par plusieurs institutions françaises par exemple : Ministère de la Defense, Ministère des finances, STIF, CE RATP, Université Technique de Troyes,... Tous ça pour quoi? Pour trouver un Sponsor afin d'intégrer OBM dans Debian. ET à terme... devenir DM. Actuellement les paquets proposés ne configurent pas tout un OBM, mais seulement la BD, et la configuration d'apache. On a donc accès à beaucoup de fonctionnalité d'OBM dans un premier temps. Mon but est d'intégrer le reste petit à petit; la gestion de l'annuaire LDAP, de Samba, et surtout de la messagerie. OBM est un projet qui se sert des briques traditionnel du Libre: Cyrus, Postfix Mysql/postgre Openldap .. A votre bon coeur :-D http://www.obm.org http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=obm -- Sylvain Garcia Aliasource - Groupe LINAGORA 20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE Téléphone : +33 (0)5 62 19 24 91 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
