Tom Lord, mainteneur de GNU Arch, un programme de gestion de sources, a décidé d'abandonner le poste de mainteneur de GNU Arch.
Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.
Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)
Le post sur la mailing list:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)
Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)
Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.
Enfin, bonne chance à Tom Lord pour ces futurs projets.
Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.
Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)
Le post sur la mailing list:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)
Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)
Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.
Enfin, bonne chance à Tom Lord pour ces futurs projets.
> Lire le journal (29 commentaires, moyenne: 2,1).
Vous avez demandé le commentaire #611926.
Run by 
Cette page a été générée par Templeet en 0.0508s (dont 0.0043 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
l'UI ? quelle UI ?
Heuh petite question on parle de quelle UI là ? Parce que je serai assez preneur d'une UI simple à tla qui me permettrait de voir quel fichier à changé (tla changes), de pouvoir tracker la révision d'un fichier (??) et faire des diffs par rapport aux révisions précédentes par exemple.
J'ai essayé octopus qui est très bien, mais sauf si j'ai loupé quelque chose, ça ne permet que de visualiser les patchset. Il y a un autre projet en GTK (archway ?) que j'avais essayé, mais j'avais trouvé qu'au niveau ergonomie c'était pas vraiment ça...
Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs qui marcherait au dessus d'un back end (cvs, subersion, tla, git, ...)
L'idée serait de faire l'interface d'un rcs ultime avec des capabilities (est-ce que tu supportes telle opération) et ensuite de montrer une vue du projet en utilisant l'implémentation du vrai rcs.
A+
David
[^]Re: l'UI ? quelle UI ?
>Heuh petite question on parle de quelle UI là ?
L'UI ligne de commande de arch/tla.
[^]Re: l'UI ? quelle UI ?
C'est bien ce qu'il me semblait, nous parlons donc d'un CLI ! :-)
[^]Re: l'UI ? quelle UI ?
UI = User Interface.
C'est pas parce que c'est en ligne de commande que c'est pas destiné aux utilisateurs. Une interface graphique, c'est une GUI.
[^]Re: l'UI ? quelle UI ?
C'est exact, mea culpa ! :-) Je fais trop vite l'amalgame UI=GUI. Arretons les amalgames !
[^]Re: l'UI ? quelle UI ?
> je serai assez preneur d'une UI simple à tla
< pub >
Si tu n'es pas alergique à Emacs, il y a Xtla ( http://wiki.gnuarch.org/xtla(...) ).
< /pub >
Sinon, en mode texte, bazaar 1.5 aura une option --modifying FILE pour tracker l'historique d'un fichier, et fai permet de faire pas mal de choses aussi.
> Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs
Dans Emacs, il y a un truc qui ressemble à ça: VC. Mais ça ne permet pas grand chose.
[^]Re: l'UI ? quelle UI ?
Et bien justement si, je suis assez allergique à emacs (je suis plutot vi !) :-) (tout ca pour reprendre un bon vieux troll)
J'ai jamais pu me faire à emacs, c'est certainement bien dommage, et oui, je savais que tu t'occupais de xtla (j'avais lu l'annonce ici meme de la 1.0 et j'avais retenu ton pseudo) :-)
J'aime beaucoup WinCVS pour sa vue à plat, ses filtres, sa possibilité de faire un graphe des révisions pour un fichier et de voir ses diffs. Il y a un outil web (proprio malheureusement) qui permet meme de reconstuire la liste des patchset et d'avoir une vue un peu plus moderne. Je pense donc sérieusement qu'on peut faire quelque chose de sympa.
Les commandes de base seraient :
- checkout (tla get)
- lister les changements (tla changes)
- faire un diff par rapport à n'importe quel autre révision (tla file-diff étendu ?) au sein d'une branche ou de plusieurs branches
- lister toutes les révisions d'un fichier (??)
- comitter un fichier ou un ensemble de fichiers (tla commit --)
- avoir une vue par patch (ce que fait octopy)
- avoir des commandes pour faire des move et des delete
- avoir une commande pour faire un undo/redo (tla undo, tla redo, simulable en cvs)
- ...
Bref, cette interface "ultime" peut être assez simple au départ, mais permettre dans un premier temps d'avoir une vue d'un projet cvs/subversion/tla sympa avec des vues synthétiques pertinentes.
Les opérations en ecriture pourraient être envisagées dans un deuxième temps.