outil client-side pour le bts (fut: péremption)
J'ai passé un temps fou à fouiller l'archive en tout sens, en me disant que
c'est pas possible que des gens qui maintiennent une 20aine de paquets
soient encore à l'age préhistorique de l'interface web actuelle et des mails.
Voici ce que j'ai trouvé :
dmbt - Debian maintainer's bug-tool
Il fournit une interface gnome pour butiner sur les rapports de bogues.
Mais il fonctionne quand il a rien de mieux à faire. Il utilise ldap pour
se connecter au bts, et le serveur ldap ne semble pas tres... conventionnel.
Je n'ai jamais réussi à me promener dedans avec des outils classiques pour
ldap, comme gq.
dmbt est écrit en perl, ce qui devrait ravir certains, et herisser le poil
d'autres...
Permet de sauver sur disque les rapports de bogues pour un usage ultérieur,
mais il ne sauve que les titres des différents rapports. Plus exactement,
disons que j'ai pas trouvé comment sauver tous les rapports de bogue, avec
les détails inclus.
querybts, du paquet repportbug
Interface texte pour butiner les rapports, télécharge puis parse les pages
web (ou utilise ldap, c'est une option que je n'ai pas testé)
Je l'utilise pour me cracher les rapports sous une forme pratique quand on
veut faire des greps et des sed sur leurs titres dans des scripts, c'est
tres bien pour ca.
Fait en python.
bts, du paquet devscript.
Interface en ligne de commande pour interagir avec les bogues. Je connais
mal car je suis pas DD, alors je n'ai jamais à interagir avec des bogues,
moi. Je veux juste faire des recherches, en général.
D'apres la page de manuel, ca s'utilise comme ca.
% bts close 85942
% bts severity 69042 normal
% bts merge 69042 43233
% bts retitle 69042 blah blah
C'est du perl.
Voila, c'est tout, c'est à dire pas grand chose à mon gout. Mais si
quelqu'un veut se lancer dans l'écriture d'un programme comme le rêve
Raphaël (et qui serait réellement *cool*), autant qu'il se base sur des
trucs qui existe déjà, au lieu de réinventer la roue...
Bye, Mt.
On Sat, Feb 02, 2002 at 08:52:19PM +0100, Raphael Hertzog wrote:
> Le Sat, Feb 02, 2002 at 01:51:15PM -0500, Laurent Pelecq écrivait:
> > - si le bug n'est pas reproductible, il faut que celui qui l'a soumit
> > fournisse plus d'information ou alors le bug est clos.
> > - si le mainteneur ne sait pas le corriger, il le passe en help ou
> > quoi que ce soit. Mais il faut qu'il est un suivi du responsable de
> > la release dans ce cas.
> > - sinon il faut que le mainteneur dise comment il compte le corriger
> > et approximativement quand. Ce qui n'est pas fait actuellement (ex:
> > 33782). il faut aussi que ça soit mis à jour si ce n'est pas fait
> > dans les temps.
> >
> > C'est possible d'automatiser cela avec un courrier envoyé au
> > mainteneur pour lui rappeler.
>
> Ca me fait penser, que cela serait super cool, si on avait un outil
> simple (et graphique tant qu'on y est) pour gérer les bugs. J'ai
> découvert récemment la commande "bts" (paquet devscripts) qui est
> déjà sympathique en soi.
>
> Mais on peut aller plus loin, un petit programme qui interroge le BTS
> (avec l'interface ldap ou autre) et qui représente tout de manière
> graphique. Il pourrait sélectionner un ou plusieurs bugs et effectuer
> la même opération rapidement (genre ajouter un tag). Ca permettrait
> aussi d'envoyer quelques messages "type" (genre "merci de filer plus
> d'infos ou ce bug sera clos dans 30 jours", ou encore un message pour
> forwarder le bug). Ces messages types seraient personnalisables. Le
> logiciel serait configuré à la première utilisation en demandant
> l'adresse email à utiliser, les paquets à suivre, et quelques truc dans
> ce genre. Pour chaque paquet, on pourrait configurer l'adresse
> "upstream" où l'on souhaite forwarder les bugs. Chaque fois qu'un mail
> est envoyé par le logiciel, il pourrait offrir la possibilité
> de le "peaufiner" à la main.
>
> Le même logiciel pourrait aller plus loin et exploiter les interfaces
> Corba que Colin Walters a développé et a présenté sur debian-devel. On
> pourrait d'un simple clic savoir quelle version a été compilée sur
> quelle architecture, récupérer le log d'un build qui a échoué avec un
> autre clic.
>
> Vraiment, un logiciel dans ce genre, ca serait *excellent*. Qui veut
> s'y coller ? :-)
>
> A+
> --
> Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
> Formation Linux et logiciel libre : http://www.logidee.com
--
Si les grands esprits se rencontrent, les petits esprits, eux, se cognent.
Reply to: