[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pourquoi pas un DebianForge ?



On Thu, Aug 30, 2001 at 12:38:45AM +0200, Raphael Hertzog wrote:
> Le Wed, Aug 29, 2001 at 10:53:10PM +0200, Rémi Perrot écrivait:
> > 1) La possibilité de monitorer l'arrivée de nouveaux paquetage
> >    dans des versions très beta. En fait, l'upstream étant très
> >    actif, et le paquetage assez compliqué, je voudrai que d'autres
> >    utilisateurs testent les paquetages avant qu'ils ne soient uploadés.
> >    Cela suppose que ces utilisateurs puissent être alertés de façon
> >    automatique lorsque je mets une pré-version en ligne. 
> 
> Unstable est fait pour cela, pour être cassé ... :) ou si tu juges que
> c'est trop cassant, alors il te reste la possibilité d'utiliser
> experimental.

Mais, qui va aller tester des paquetages qui sont dans experimental ?
En plus, si tu rajoutes experemental dans ton apt/sources.list, tu risques
de ramener beaucoup plus de paquetages expérimentaux que tu ne le souhaites.
Et, enfin, comment les utilisateurs peuvent-ils être informés de l'arrivée
d'une version expérimentale ?

Tu sais que, régulièrement, le projet ne passe pas des zones grises. Cela
correspond au moment où la version stable est trop vieille ce qui se
traduit par des versions de paquetages trop anciennes où l'absence de
nouveaux paquetages que l'on trouve dans unstable ou testing d'une part,
et d'autre part qu'il n'est plus possible de reconstruire les
paquetages unstable/testing sur potato du fait de l'évolution des
outils et des normes de packaging. Une conséquence de tout ça est qu'il y
a forcement des utilisateurs qui ont des woody ou des sid en production.

Dans ces conditions je me vois mal uploder un paquetage dont je sais
qu'il est cassé en ouvrant simultanément un bug avec un tag help par
exemple.

 
> > 3) La mise en place mailinglist ou de forum de façon simple.
> >    notamment des mailinglist pour la coordination de la traduction
> >    des templates, mais aussi pour l'information sur les nouvelles
> >    versions en beta.
> 
> Pour les nouvelles versions il y a déjà les listes Debian standard.
Comment inviter les utilisateurs à s'abonner à des listes généralistes où
ils vont recevoir dans les 400 mails par semaine alors qu'il ne risque
d'y avoir que 1% de mail qui les intéresse.

> Pour le maintien des traductions de templates, c'est vrai qu'il y a un réelle
> lacune sur ce point là.

Je conviens qu'il n'y a pas de solution miracle pour les traductions, mais ce
que je cherche c'est avoir un système qui minimise et standardise le travail
de relation traducteur/mainteneur. Pour cela un système SF n'est qu'une solution
parmi d'autres.


> > Il se trouve que SF fait déjà très bien toutes ces choses alors pouquoi
> > réinventer la roue ?
> 
> Personellement je pense que SF est un peu overkill malgré tout,
> mais si cela peut aider certains mainteneurs, pourquoi pas ?

Je parle de SourceForge parce qu'il est bien connu, d'une part, et parce qu'il est
packagé d'autre part, mais je ne suis pas attaché particulièrement à SF.
La solution pourrait être DebianFamilly ou autre.

Cela dit 'qui peut le plus peut le moins'. Il est évident que si l'idée est
retenue il restera un travail énorme à faire.

> Personnellement je pense que je ferai quelque chose de plus
> spécifique. Peut-être une sorte de portail où les contributeurs
> peuvent suivre les nouvelles versions des paquets qui les intéressent.
> Et pour les mainteneurs ils pourraient avoir un point de vue global sur
> les paquets qu'il maintient.

Pourquoi se limiter dès le départ ?

Le gros intérêt de SF dont je n'ai pas encore parlé, c'est qu'il inclut la délégation
d'administration, ce qui est indispensable pour faire du travail collaboratif.

De toutes manières, en adoptant l'hypothèse de travail que SourceForge est retenu,
il n'est probablement pas utile d'activer toutes les fonctionnalités de SF, et
parmi ces fonctionnalités chaque mainteneur choisira celles qu'il veut utiliser.

> C'est des idées vagues qui trottent depuis longtemps dans ma tête mais que
> je n'ai pas le temps de coder. :)

J'ai remarqué aussi que ça prend moins de temps d'avoir des idées que de les
mettre en pratique :-)

A+

Rémi Perrot



Reply to: