Author: marcimat@rezo.net
Date: 2020-03-26 00:47:30 +0100 (jeu 26 mar 2020)
New Revision: 24546
Log:
?\195?\137viter une erreur SQL : `Champ: 'id_article' dans where clause est ambigu` sur la liste d?\226?\128?\153articles "Dans la m?\195?\170me rubrique" dans certains cas.
Notamment lorsque l?\226?\128?\153on revient d?\226?\128?\153ajouter un ?\195?\169v?\195?\169nement sur un article, le retour de l?\226?\128?\153URL am?\195?\168ne ?\195?\160 quelque chose comme `?exec=article&id_article=1&id_evenement=1`
et la boucle de prive/liste/articles.html utilis?\195?\169e `(ARTICLES){id_?}{where?}` filtre sur l?\226?\128?\153?\195?\169v?\195?\169nement indiqu?\195?\169 (en plus de la rubrique en cours) avec un `where`
qui exclut l?\226?\128?\153article en cours, et la d?\195?\169claration du where cr?\195?\169?\195?\169ait un usage ambigu du champ `id_article`.
Le 26/03/2020 à 00:48, marcimat-JM9gtpQu/Ho@public.gmane.org a écrit :
Author: marcimat-JM9gtpQu/Ho@public.gmane.org
Date: 2020-03-26 00:47:30 +0100 (jeu 26 mar 2020)
New Revision: 24546
Log:
?\195?\137viter une erreur SQL : `Champ: 'id_article' dans where clause est ambigu` sur la liste d?\226?\128?\153articles "Dans la m?\195?\170me rubrique" dans certains cas.
Notamment lorsque l?\226?\128?\153on revient d?\226?\128?\153ajouter un ?\195?\169v?\195?\169nement sur un article, le retour de l?\226?\128?\153URL am?\195?\168ne ?\195?\160 quelque chose comme `?exec=article&id_article=1&id_evenement=1`
et la boucle de prive/liste/articles.html utilis?\195?\169e `(ARTICLES){id_?}{where?}` filtre sur l?\226?\128?\153?\195?\169v?\195?\169nement indiqu?\195?\169 (en plus de la rubrique en cours) avec un `where`
qui exclut l?\226?\128?\153article en cours, et la d?\195?\169claration du where cr?\195?\169?\195?\169ait un usage ambigu du champ `id_article`.
Tiens j'avais fait un ticket sur le gitea sur le bug
on ferme ?
Le 27/03/2020 à 01:32, nicod_ a écrit :
Le 26/03/2020 à 00:48, marcimat-JM9gtpQu/Ho@public.gmane.org a écrit :
Author: marcimat-JM9gtpQu/Ho@public.gmane.org
Date: 2020-03-26 00:47:30 +0100 (jeu 26 mar 2020)
New Revision: 24546
Log:
?\195?\137viter une erreur SQL : `Champ: 'id_article' dans where clause est ambigu` sur la liste d?\226?\128?\153articles "Dans la m?\195?\170me rubrique" dans certains cas.
Notamment lorsque l?\226?\128?\153on revient d?\226?\128?\153ajouter un ?\195?\169v?\195?\169nement sur un article, le retour de l?\226?\128?\153URL am?\195?\168ne ?\195?\160 quelque chose comme `?exec=article&id_article=1&id_evenement=1`
et la boucle de prive/liste/articles.html utilis?\195?\169e `(ARTICLES){id_?}{where?}` filtre sur l?\226?\128?\153?\195?\169v?\195?\169nement indiqu?\195?\169 (en plus de la rubrique en cours) avec un `where`
qui exclut l?\226?\128?\153article en cours, et la d?\195?\169claration du where cr?\195?\169?\195?\169ait un usage ambigu du champ `id_article`.
Ce ticket sur Agenda, pour sûr oui (ça ne le concerne pas vraiment)
Après il reste donc la question du cadre "Dans la même rubrique", qui réagit à différents critères d’environnement, sans que ça soit forcément bienvenu. C’est pas non plus une catastrophe.
Ben alors, PR ou pas PR au final ?
Ah ? Faut me dire alors…
Mais si je dois faire une PR pour chaque notice PHP que je croise, ça va viiiiite me gaver je pense.
Le 27/03/2020 à 10:30, Matthieu Marcillaud a écrit :
Ben alors, PR ou pas PR au final ?
Ah ? Faut me dire alors…
Mais si je dois faire une PR pour chaque notice PHP que je croise, ça va
viiiiite me gaver je pense.
il me semble que si c'est pratique d'avoir la possibilité de faire des
PR pour *proposer* des changements cad les donner à discuter, on est pas
du tout obligé de passer par ce mécanisme pour tous les commits...
...il n'y a déja pas tant de commiteurs pour qu'on ne les décourage pas!
Le 27/03/2020 à 10:30, Matthieu Marcillaud a écrit :
Ben alors, PR ou pas PR au final ?
Ah ? Faut me dire alors…
Mais si je dois faire une PR pour chaque notice PHP que je croise, ça va
viiiiite me gaver je pense.
il me semble que si c'est pratique d'avoir la possibilité de faire des
PR pour *proposer* des changements cad les donner à discuter, on est pas
du tout obligé de passer par ce mécanisme pour tous les commits...
...il n'y a déja pas tant de commiteurs pour qu'on ne les décourage pas!
(et ce n'est pas comme si on n'avait pas l'habitude de "...on s'engueule
après")
Pour une notice évidemment, ce serait vraiment lourdingue, mais b_b m'a repris quand je voulais commiter une modif (et il a bien fait).
Du coup je soulevais ça pour en parler, qu'on se donne une discipline quoi, sans pour autant tomber dans une technocratie absurde.
Déjà, comment nommer les branches quand un fait une PR ?
issue_xxx avec le numéro du ticket Redmine, s'il y en a un, semble pas mal.
Et dans quel cas un commit direct est acceptable ; une correction de bug ?
En fait, ça pourrait être spécifié dans une doc peut être, même si ça ne concerne que peu de gens...
+1 que ça soit noté quelque part à la fin et pas perdu au fin fond d'un fil de discussion
Pour ma part pour la nomenclature des branches, je suivais la convention "issue_xxx" quand ça correspond à un ticket, et "dev/truc" quand c'est une fonctionnalité (qui peut correspondre à 0 ou plusieurs tickets à la fois quoi).
Désolé de jouer le relou de service, mais une fois de plus cette discussion pourrait avoir lieu sur spip-dev.
Merci de soulever la question, amha on peut rédiger ces "règles de commit" au choix dans un readme dans le repo spip, ou dans le wiki de ce repo.
Pour le passage par PR, je pense que c'est bien dès que ça touche à un changement majeur pour les users (interface chamboulée, déplacement de blocs, etc) ou un changement qui pourrait impacter le code existant, ou une nouveauté, bref les gros trucs. Donc pas la peine de s'emmerder avec une PR pour une notice ou un bugfix anodin (reste à définir le périmètre de l'anodin ^^). Au final, la PR c'est bien quand on souhaite être relu avant d'envoyer.
À propos du nommage des branches pour les PR, comme Charles, j'ai pris l'habitude de les nommer issue_XX en référence au ticket correspondant (ce qui implique qu'un ticket soit créé sur redmine avant d'envoyer la PR), ça permet de s'y retrouver. Une note à ce sujet, ça serait bien qu'on s’astreigne à coller un lien vers le ticket dans le log de commit, ainsi on retrouve bien un lien vers la discussion du ticket dans la page de la PR (c'est pour ça que je l'ai rajouté sur certaines de vos PRs).
