Reprise du message précédent :

tu peux commencer par trier les listes si t'as un ordre interne, et ensuite essayer de caler une séquence entre les éléments, ça te fait passer la complexité en nombre de comparaisons de n^2 à N log(N)
 
sinon, j'ai jamais fait mais c'est du clustering peut-être que google peut t'aider avec ce mot clef.

Je vois pas le soucis avec deux boucles. Edit: merde, je veux dire l'inverse, tu fais pas le produit cartésien complet, mais juste

 
Est-ce que tu peux trier tes collections selon les champs et faire de la programmation dynamique pour mettre de côté certains candidats?
Sinon dans les bibliothèques de ML y pas un classifieur adapté à ce genre de chose?
 
Edit: grillé, tout pareil que nray.

C'est quoi un numéro de version de dev ? Il vient d'où le numéro ?

Merci.

@plam : écrire un article de blog à chaque release et tous les mois faire un résumé des 2 articles par email ?

C'est le numéro de version mineur de chaque « release » de xo-server et xo-web. Exemple : on est à 5.24 en ce moment. Avant on le faisait 1 fois par mois (le dernier jours travaillé du mois). C'est incrémenté via npm ("npm version --minor" ) quand on décide de release. C'est ce numéro qui est affiché dans l'appli via le système de MAJ et la vue about.

Il se peut qu'on ait des versions « patch » si nécessaire, entre 2 releases (là on est à 5.24.2 pour xo-server et 5.24.0 pour xo-web).

C'est une possibilité MAIS :

• le user recevait dans sa boîte mail le recap et le lien vers le blog post, là il va voir la MAJ dans son soft sans recevoir un récap dans sa boîte, on « force » l'user à aller chercher l'info au lieu de simplement la recevoir dans son flux de donnée « classique » (sa boîte mail)
• ça veut dire des titres de sujets de mail de release un peu différent, parce que je peux plus facilement à la fois donner la version qui vient de sortir et une autre info dans le sujet (enfin ça veut dire changer un peu la façon de communiquer). Par exemple avant c'était : « Xen Orchestra 5.21, new backup features ». Quand tu mélanges plusieurs release, c'est un peu plus délicat.

edit : pour être franc, ça me fait chier que la tambouille interne des devs me force à réfléchir autant à conserver notre communication habituelle

 
Est-ce que ton produit Xen Orchestra possède un module de messaging?
 
On a implémenté un module de messaging au sein même de notre solution pour que lorsqu'une nouvelle feature essentielle est développée, on puisse l'annoncer "hors channel, comme les emails qui saoulent tout le monde ou finissent à la poubelle".
On conserve les emails une fois par mois pour avoir un suivi pour ceux que ça intéresse, mais le dev de l'application n'est jamais dicté par la communication.
 
Edit: on a différents niveau de notification. On peut par exemple forcer l'apparition d'un popup si la nouvelle feature est vraiment supra importante.

 
Pourquoi les devs releasent + fréquemment sur un repo public ? C'est ça en fait ton pb.

Pas vraiment « directement » mais c'est quelque chose vers lequel on va tendre dans les prochains mois (il y a déjà une issue en interne pour ça).
 
La grosse motivation c'est parce que les acheteurs et les users sont pas corrélés, et du coup les expirations d'abonnements sont évitables si on averti l'user directement dans l'appli (parce que le service achat en a rien a branler).
 
Donc ça pourrait aussi servir à ça moi. Mais du coup je vais tout de même me retrouver à écrire des mails de « récap » et pas un mail par release. Ça se fait mais je trouve ça un peu moins « naturel ».
 
C'était bien quand le cycle de dev était lié au cycle de comm'

tu écris un texte de com' par micro release, eventuellement repris dans l'appli comme le propose hlm ( et comme fait trello)  
 
et une fois par mois , tu prends les textes et tu les agglomère dans un mail / post
 
d'un autre côté forcer le rythme de dev sur le cycle de com devait rajouter pas mal de pression , par exemple sur les gros morceaux qui passent difficilement dans 15j de dev , ou quand il y a des congés, des formations, des maladies

Koskoz si tu te tâtais toujours pour l'Essential phone: https://www.amazon.com/gp/product/B078SQ7GWK/
$224

il va y avoir quoi comme taxe/douane la dessus ?

 
Oui donc plus « d'effet d'annonce » sauf à faire une majeure pour une grosse feature un fois par an. J'annonce quoi dans mon mail ? Je peux plus dire « Xen Orchestra X.Y », et ça casse ceci : https://xen-orchestra.com/blog/tag/release/ Je trouvais ça pas mal.
 

Pas de douanes sur l'électronique.
Amazon s'occupe de l'importation donc pas de frais supplémentaires il me semble.    
Donc normalement que la TVA.

C'est pas le coeur du pb justement ?
 
Je remets ma question d'avant :  
Pourquoi les devs releasent + fréquemment sur un repo public et pas juste en interne ?

Bah à un moment faut choisir, soit tes releases sont "marketing" et tu cut ton truc officiel tous les mois avec récap et tout soit tes releases sont "techniques" et t'es zob

Après je vois pas pourquoi un cycle de dev de 2 semaines ça se traduit en une release externe.

Repo public ou privé c'est même pas un facteur, la question c'est le rapport avec un tag release. Tout le boulot peut être fait en public, c'est pas gênant.

Les devs  numérotes les releases mineures  5.22.1->5.22.3.
A la fin du mois tu annonces "Récapitulatifs des nouveautés de la 5.22", éventuellement en précisant sur quelle mineure c'est tombé

Si tu veux annoncer avant de livrer alors tu stockes les release et tu les livres plus tard, mais ça me semble contraignant et avec un bonus faible.

@marsklinn : on décide à un moment que « master » contient assez de modifs pour en faire une release. Avant c'était 1 fois par mois (dicté par la comm'/marketing), modulo les releases patch quand un problème sérieux sortait.
 
Je suis pas sûr de comprendre la remarque : « Après je vois pas pourquoi un cycle de dev de 2 semaines ça se traduit en une release externe. ».
 
Qu'est-ce que tu veux dire par là ? Qu'on sorte pas une version mineure toute les 2 semaines ?

Tu veux dire « patch » à la place de « mineure » non ?

edit : le truc c'est que eux sont basés sur « toutes les 2 semaines » et ça tombe random dans un mois, puisque le cycle est plus calé sur un mois (qui fait pas pile 4 semaines)

Ouais tu continues à tagger ton master une fois par mois.

est ce que le fait de tagguer une release declenche des update automatiques chez  les utilisateurs  ?

import fee deposit = tva ? (ça fait pile 20%) ou c'est en plus ?

Pas d'accord du côté dev : selon eux, si on décide de faire un tag une fois par mois et que ça tombe sur master en milieu de leur run, eh bien la release sera toute pourrie (genre tu maj tes deps en début de cycle de 2 semaines, et ça tombe en fin de mois pour une release = caca)

Non, ya un process de build et de publication chez nous.

Ça a l'air d'être vraiment le prix net.
Sur ma commande j'ai 7.7% ce qui correspond bien à la TVA locale (par contre moi en Suisse je devrais payer 3% de douanes en plus normalement ).
 

C'est même mieux que ça : il n'y a pas de douane pour les pays membres de l'UE
(c'était avant Trump, j'ai passé 2 commandes sur Amazon.com avant son élection et c'était le cas, j'avais posé la question au service client d'Amazon.com, ça m'avait paru louche, mais j'ai rien payé. Maintenant je sais pas)

edit: ça peut aider : https://www.amazon.com/gp/help/cust [...] eId=596194

void modifierAdresse(String adresseLigneUn, String adresseLigneDeux, String adresseLigneTrois,
            String adresseLigneQuatre, String adresseLigneCinq, String adresseLigneSix,
            String adresseLigneSept) {
        if (uneLigneEstNonNulle(adresseLigneSept, adresseLigneSix, adresseLigneCinq)
                || uneLigneEstNonNulle(adresseLigneQuatre, adresseLigneTrois, adresseLigneDeux)
                || adresseLigneUn != null) {
            this.perPhyAdresseLigneSept = adresseLigneSept;
            this.perPhyAdresseLigneSix = adresseLigneSix;
            this.perPhyAdresseLigneCinq = adresseLigneCinq;
            this.perPhyAdresseLigneQuatre = adresseLigneQuatre;
            this.perPhyAdresseLigneTrois = adresseLigneTrois;
            this.perPhyAdresseLigneDeux = adresseLigneDeux;
            this.perPhyAdresseLigneUn = adresseLigneUn;
        }
    }
 
void mettreAjourAdresse(String adresseLigneUn, String adresseLigneDeux,
            String adresseLigneTrois, String adresseLigneQuatre, String adresseLigneCinq,
            String adresseLigneSix, String adresseLigneSept) {
        this.perPhyAdresseLigneSept = adresseLigneSept;
        this.perPhyAdresseLigneSix = adresseLigneSix;
        this.perPhyAdresseLigneCinq = adresseLigneCinq;
        this.perPhyAdresseLigneQuatre = adresseLigneQuatre;
        this.perPhyAdresseLigneTrois = adresseLigneTrois;
        this.perPhyAdresseLigneDeux = adresseLigneDeux;
        this.perPhyAdresseLigneUn = adresseLigneUn;
    }
 
private boolean uneLigneEstNonNulle(String ligneA, String ligneB, String ligneC) {
    return ligneA != null || ligneB != null || ligneC != null;
}

 
MAIWAI!

Oui. Si les devs veulent absolument leur release (idk y but w/e) ça peut être un pseudo-namespace séparé basé sur la date. Ou l'inverse d'ailleurs, tes releases marketing peuvent passer en date-based à la Ubuntu ou quoi.

Ça d'un point de vue technique bof, s'ils essaient de faire un truc semver ça correspond juste pas, mieux vaut avoir deux versions découplées (une interne/technique et une extern/marketing)

Bah tu récup la fin du cycle précédent (genre une branche à la fin de chaque cycle, d'où les patch releases peuvent être générées indépendamment du sprint courant), ou bien ils arrêtent de bosser sur master et le boulot est intégré en fin de cycle.

 
Cf Masklinn
Mais un master stable c'est pas possible ? Juste pour savoir hein

un master moisi ? ça me se semble bancal

c'est peut etre ça la solution : ta version c'est celle donnée lors du build, celle qui va se déployer

Si on dit que master devient « stable », ça veut dire que potentiellement on doit backporter des fix dessus quand c'est urgent. Ils ont pas l'air chaud pour changer de flow. M'enfin on fait venir un externe pour aider l'équipe XO à sortir la tête de l'eau (je suis « plus » que le product manager, et forcément, c'est le carnage… la transition a été faite d'un coup parce que je pouvais plus être partout à cause d'XCP-ng)

C'est semi-moisi disons, en fonction de quand tu t'y trouves. En général par exemple, en début de cycle (post release), on MAJ toutes les dépendances sur master, ça permet à la communauté de faire nos beta testeurs (et j'aime bien le principe que ça puisse exploser sur les utilisateurs des sources de temps en temps QA gratos )

edit : je vous dirai ce que ça donne le RDV avec le type (super CdP par ailleurs avec qui j'ai déjà bossé), ça va être intéressant un juge de paix là dessus

Vous avez déjà touché des cartes cadeau amazon avec les sondages VDC research vous ?

Ouch les prix des rtx

Je dirais comme Masklinn : tu decoreles les releases techniques et les releases marketing.
Avantages
- tes dev gardent leur flexibilité
- tu gardes un plan de com predictible
- tu peux laisser la version affichée (le user ne peut pas savoir du la version 12567 cache 1 ou 3 versions par rapport a la version 12243 (les releases win10 suivent ce principe)

Ça suppose que tu pousses tes versions que 1x par mois.

Autre option : tu pousses quand c'est prêt (avec releases notes dispo en cliquant si besoin), et tu fais un update où tu présentes tes updates proprement quand t'as assez. Office communique selon ce principe.

Pas de concurrence + fuck la rastérisation

Ça fait presque 20 ans que j'attends cette techno, la saut qualitatif va être chouette

comment tu vas programmer ça ? tu prends le toolkit du constructeur et tu développes des apps spécifiques?

Je préfère jouer aux jeux que les programmer
 
Nan mais matez moi ces éclairages
Tomb Raider
Metro Exodus
 
Après c'est sûr que c'est balbutiant et que ça ne sera perenne qu'avec l’implémentation du truc sur les consoles. Mais c'est clairement une avancée majeure en CGI.

Putain mais Schiappa
https://twitter.com/MarleneSchiappa [...] 0704205824
 
Cette conne ne prend même pas la peine de vérifier si les voisins sont allés à la police avant d'accuser les voisins et le bailleur de non assistance à personne en danger. Elle mériterait une plainte pour diffamation

.. Sur ce coup là elle a raison, hein.

http://www.leparisien.fr/la-garenn [...] 850802.php

Le tribunal qui écrit OKLM que "la plainte déposée par Mme Machin ne fait que corroborer les troubles".
Ben voyons, donc le tribunal a connaissance d'une situation de violence conjugale, mais décide de faire passer la plainte pour trouble et l'expulsion avant.

Alors qu'il aurait pu suspendre sa décision le temps de l'examen de la plainte pour violences, et le mec éventuellement mis sous le coup d'une mesure d'éloignement.

Pour le coup, la victime aurait bien raison de porter plainte contre les voisins et le bailleur pour non assistance à personne en danger.

[edit]

Cela dit, elle s'adresse au bailleur.

Là encore, elle n'a pas tort : le bailleur aurait pu faire le choix de se renseigner sur la situation, et assister la nana pour qu'elle obtienne l'éloignement de son conjoint.

Mais il a préféré porter plainte suite aux signalements des autres locataires (c'est le bailleur qui a saisi le tribunal... Il n'a  manifestement pas pris la peine de prévenir la police, la gendarmerie ou les services sociaux)

Avoir « tort » car sinon c'est le verbe « tordre ». Moyen mnémotechnique : « le tort tue »

fixed.
SHAME.