This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".
The branch master has been updated
via 82a6014b5b7dd1db0c21048d7cf4aa4b7d8b66ef (commit)
from dab30968b27f1a0641a18de08b40590066af42cf (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
82a6014 Update the menu of BuildBots' Web site.
-----------------------------------------------------------------------
Summary of changes:
buildbot/masters/ChangeLog | 9 +++++++++
buildbot/masters/www/index.php | 19 ++++++++++---------
2 files changed, 19 insertions(+), 9 deletions(-)
hooks/post-receive
--
UNNAMED PROJECT
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".
The branch master has been updated
via dab30968b27f1a0641a18de08b40590066af42cf (commit)
from f70e3f5b1318b99bf1fbf28fc4d881de3b6acb23 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
dab3096 Fix the invocation of lrde-upload.sh in the Olena build.
-----------------------------------------------------------------------
Summary of changes:
buildbot/masters/ChangeLog | 6 ++++++
buildbot/masters/oln_master.cfg | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
hooks/post-receive
--
UNNAMED PROJECT
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".
The branch master has been updated
via f70e3f5b1318b99bf1fbf28fc4d881de3b6acb23 (commit)
from 0e7da893b1fe0bd8fbeba3cc6e317fbfc77d8191 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
f70e3f5 Replace the sole Olena ICC slave by two slaves (for ICC 10 and 11).
-----------------------------------------------------------------------
Summary of changes:
buildbot/masters/ChangeLog | 7 +++++++
buildbot/masters/oln_master.cfg | 7 ++++---
2 files changed, 11 insertions(+), 3 deletions(-)
hooks/post-receive
--
UNNAMED PROJECT
Le comportement est parfois bizare, mais la tracnav fonctionne. Il y a
parfois des problemes de cache avec firefox. En arrivant sur la page
d'Olena, elle fonctionne, pareil avec tranformers, mais elle ne
fonctionnait pas avec vaucanson...sauf apres un reload.
Olena Trac wrote:
> #205: Repair the TracNav bar
> ------------------------+---------------------------------------------------
> Reporter: levill_r | Owner: Olena Team
> Type: defect | Status: new
> Priority: minor | Milestone:
> Component: Trac | Version: 1.0
> Keywords: system web |
> ------------------------+---------------------------------------------------
> Since the update of Trac, many Wiki pages using the !TracNav plug-in won't
> display the !TracNav bar (menu on the right of some pages), and show this
> error instead :
> {{{
> Error: Failed to load processor TracNav
>
> No macro or processor named 'TracNav' found
> }}}
> The curious thing is, the !TracNav bar is working ''sometimes''!!
>
> To see this in action, try reloading a page several times (e.g.
> CodingStyle): sometimes you'll see the bar, other times you'll get the
> error.
>
> I assume other Tracs ([https://trac.lrde.org/vaucanson/ Vaucanson's],
> [https://trac.lrde.org/transformers/ Transfomers'], etc.) face the same
> problem; we should discuss this issue with their maintainers. Therefore I
> (Roland) am cc'ing this ticket to the `projects` mailing list as well.
>
"Benoit Perrot" <benoit(a)lrde.epita.fr> writes:
>> De même, n'utilisez qu'une seule espace après « * » ; ceci
>>
>> * foo.hh: Blah blah.
>> * bar.cc: Other blah blah.
>>
>> est à proscrire.
>
> Je ne comprends pas. Qu'est-ce que l'on cherche a ecrire ici ?
> Comment faut-il ecrire ?
La même chose, mais avec une seule espace derrière l'étoile :
* foo.hh: Blah blah.
* bar.cc: Other blah blah.
>> 2. Ce n'est pas la peine de documenter les entrées que svn-wrapper
>> génère par pur zèle :
>
> Alors, une option `--no-pedantic' serait bienvenue ;)
Oui, mais je pense que personne n'a vraiment envie d'aller patcher
svn-wrapper.
>> 4. Les fichiers doivent toujours être prefixés d'une étoile
>
> (Heee mais euh ! C'est de la faute a emacs qui fait n'imp' avec Meta-Q
> en mode Change Log :) )
Oui, c'est vrai... Mais c'est mieux que rien.
>> 5. Les entrées s'écrivent à l'impératif (et non au prétérit). Une
>> entrée comme :
>>
>> * foo.cc: Fixed 'float' bug on edges.
>>
>> devrait s'écrire :
>>
>> * foo.cc: Fix 'float' bug on edges.
>>
>
> (Discussion ouverte)
>
> Je pense parfois que ce n'est pas tout a fait ca non plus. Le destinataire
> de l'imperatif, c'est le fichier/la fonction modifie, non ?
>
> Si oui, alors, on ne devrait pas ecrire :
>
> * foo.cc: Create.
>
> ("foo.cc, Cree !")
> Mais plutot :
>
> * foo.cc: Provide foo-feature.
>
> ("foo.cc, Donne-moi la fonctionalite foo !")
>
> Dans la meme idee, on ne doit pas ecrire :
>
> * foo.cc: Fix bug.
>
> ("foo.cc, Corrige-moi ce bug !")
> Mais plutot :
>
> * foo.cc: Have the good behavior.
>
> ("foo.cc, Comporte-toi bien !")
>
> Euh... C'est vendredi aprem, la semaine a ete longue ...
Je ne sais pas. Le sujet, ce peut être le patch aussi.
Quelques critiques...
>>> "VO" == Vincent Ordy <ordy(a)lrde.epita.fr> writes:
[...]
VO> +# Check 80 columns.
VO> +if grep -q '^.\{80,\}' "$file"; then
VO> + warning 'Please avoid long lines in your ChangeLog entry (80 columns max):'
VO> + grep >&2 '^.\{80,\}' "$file"
VO> + error=true
VO> +fi
1) Une tabulation devrait compter pour 8 colonnes dans un ChangeLog
=> il faudrait utiliser "expand" avant grep.
2) Vaucanson contient des noms de fichiers de plus de 80 caractères.
Découper un nom de fichier pour le faire tenir sur 80 colonnes
ne me paraît pas souhaitable car ça empêche d'utiliser grep ensuite.
En fait c'est un cas où il me semble raisonnable de ne pas imposer
les 80 colonnes. Peut-être peux-tu ignorer les lignes qui
n'ont pas d'espace (de la forme "^\t[^ ]*$") avant de compter les
colonnes.
VO> +++ b/trunk/git-hooks/post-commit
[...]
VO> +## Add the log to the ChangeLog
VO> +mv "$changelog" "$changelog".old
VO> +git > "$changelog" \
VO> + log -n1 --date=short \
VO> + --pretty="format:%ad %an <%ae>%n%n %s%n%n%b%n"
VO> +cat >> "$changelog" "$changelog".old
VO> +rm "$changelog".old
VO> +
VO> +## Amend the last commit to add the ChangeLog
VO> +git add "$changelog"
VO> +tree_ref=$(git write-tree)
VO> +commit_ref=$(git log -n1 --pretty="format:%s%n%n%b%n" | \
VO> + git commit-tree $tree_ref -p 'HEAD^')
VO> +git update-ref HEAD $commit_ref
VO> +git gc --auto
Perso il est hors de question que j'utilise un truc pareil.
L'intérêt de git est justement que je peux faire plein de
commits intermédiaires : certains qui disparaîtront par la
suite, d'autres qui seront fusionnés et pour lesquels j'écrirai
le ChangeLog plus tard, ou bien des commits que je réordonnerai
avant de les rendre publiques. Je ne veux pas que mon ChangeLog
soit pollué systématiquement avec ma cuisine.
Par hasard est-ce que ce "truc" ne rajouterait pas une
entrée de ChangeLog si j'essaye de modifier une typo
dans le dernier message de commit avec "commit --amend" ?
Non, non, franchement pour éviter le travail de dupliquer
les messages des commits et du ChangeLog je vois d'autres
solutions :
- écrire le ChangeLog confortablement (p.ex. à l'aide
de "C-x 4 a" sous emacs) et avoir un script qui appelle
"git commit" en lui passant le texte de la dernière entrée.
Ça nous permet d'appeler "git commit" normalement pour
les commits moins formels.
- ne plus écrire de ChangeLog, mais les générer
automatiquement juste avant de faire une release (c'est
l'approche de GNU Coreutils et de Xorg); ça simplifie
les merges.
- ne plus écrire de ChangeLog et ne même plus les générer
(c'est l'approche de Linux).
Pour nous développeurs, les ChangeLogs ne nous servent plus à
grand chose à partir du moment où l'on a une copie du dépôt git
en local. Mais comme on ne distribue pas le dépôt git en même
temps que les sources dans une release, c'est un peu dur de
respecter les GPL sans trimbaler de ChangeLog (au moins pour les
parties du projets dont nous ne sommes pas propriétaires) :
« a) You must cause the modified files to carry prominent
notices stating that you changed the files and the date of
any change. »
--
Alexandre Duret-Lutz