Reprise du message précédent :

 
Du coup je lis la doc et je comprends pas la différence entre /D et /J

Perso j'ai rien migré mais je comprend la réaction des gens, et au final c'est une bonne chose   (plus de monde sur GitLab)
 
GitHub était vu comme entité indépendante, avec des objectifs « cohérents » (succès du social coding), même s'ils étaient lent à la détente vs les attentes users.
 
Le rachat par MS est interprété comme une potentielle menace par rapport à cette indépendance (no shit) et l'intégration d'autres trucs plus proche de l'env MS. Même si ça change rien, que ça soit vu tel quel, n'a rien d'étonnant.

 
Nope
 
D'ailleurs je serais pas surpris que Google rachète Gitlab :
- pendant à MS
- l'équivalent GCP sucks (juste un repo fut, y'a pas la partie issues, Pull request, etc...)
 
À minima Gitlab va surement avoir une bien meilleure intégration dans GCP (pour l'instant seuls Github et Bitbucket ont une intégration native)

L'intégration GKE et GitLab est deja excellente. Largement meilleure que celle de Github vu que le CD+monitoring est géré.

 
NTFS supporte les liens symbolique depuis toujours, c'est juste pas mis en avant par windows

/D = lien symbolique
/J = jonction

edit : https://www.2brightsparks.com/resou [...] -Links.pdf

Une fois de plus j'ai l'impression d'être dans une impasse concernant mon processus de release :

Avant que la version 1.0.0-dev parte en production elle est transformée en 1.0.0-rc.1 et est publiée sur une machine de recette.

Une fois que la version est stable (admettons que nous sommes en 1.0.0-rc.5) elle part en production.

Sauf que : je vais des builds immuables. C'est donc l'artefact (ici un .tar.gz) de la 1.0.0-rc.5 qui va partir en production. Je peux renommer cet artefact et le repousser sur le Nexus sans soucis.
Le problème c'est que dans cette tarball j'ai un fichier "package.json" qui a contient la version du projet, toujours en 1.0.0-rc.5.

Je ne vois pas comment gérer le passage de la RC5 à la release sans modifier le build
La seule solution trouvée pour le moment est de décompresser la dernière RC, modifier le package.json et la recompresser, mais le build n'est du coup plus immuable.

Je ne veux pas rebuild à partir du dernier commit (de la branche de release) pour deux raisons :
1) Peut-être qu'un nouveau commit a été introduit depuis la dernière RC
2) Peut-être que certains vendors ne seront plus dispo à cet instant T

Des idées

Ou alors le package.json contient déjà la version de release (1.0.0) et les "-rc.X" ne sont portés que par le nom de l'artefact

c'est un vrai feu d'artefact

 
https://github.com/vishnubob/wait-for-it  

Iterator i = staffList.getIterator();
 
// skip first 2 staff members
if (i.hasNext()) {
   i.next();
   i.next();
}
 
while (i.hasNext()) {
...
}

j'ai du être une grosse pourriture dans une autre vie pour être puni comme ça, je sais pas...  ou alors Le Seigneur met ma foi à l'épreuve  

M'ouais, j'aime pas trop ce rachat, en ce qui me concerne.
Ils vont encore foutre une licence d'utilisation de Github moisie.
Github sera intégré dans Visual Studio et le but est naturellement de ramener tous les développeurs sur la plateforme Microsoft/Azure. Alors l'outil de dév est peut-être bien foutu, mais soyons clair, il n'est pas fait pour du dév. sous Linux, donc le but est bien de faire migrer le développement open source sur Microsoft.
 
Ca m'énerve parce que le lead du projet sur lequel je suis est parti sur du tout Microsoft pour des hopitaux. Alors certes, c'est p-ê plus facile à administrer, mais perso j'ai du mal avec l'idée de faire payer 56000€ de licence SQL Server/an aux hopitaux.

Iterator i = staffList.getIterator();
 
// skip first 2 staff members
if (i.hasNext()) {
   i.next();
   i.next();
}
 
while (i.hasNext()) {
...
}

 
Ce qui est fabuleux, c'est qu'en plus d'être totalement affreusement dégueulasse (en dehors d'être du java), ça peut planter sur le second i.next();    

ben ouais... si le staff n'a qu'un membre, le Malin refera surface armé de sa Guru Meditation fatale...

 
Il suffit de catcher l'exception et de l'ignorer.. et hop !

remet moi un jaune Marcel

Gitlab a exactement le même problème long terme: ils ont pris du pognon VC (moins, mais pas loin de 50m), si la boite a pas coulé à un moment les VCs débarquent et demandent leur pognon.
 
Et d'un point de vue technique, j'ai jamais vu une instance gitlab qui soit utilisable, elles sont toutes horriblement lentes, c'est super frustrant

 
Au temps pour moi, j'ai raté un épisode
/retourne lurker
 

CVS j'te dis... C.V.S !

 
Combien d'user ? Pas de soucis de perfs sur une instance interne ici.

Gogs rules them all
 
Je l'ai foutu sur un VPS a 2e, jamais eu de ralentissement, s'installe en 3 min, 50 personnes dessus qui push tous les jours

Ici la version des snapshots est générée à partir de la distance depuis la dernière release, sous la forme majeure.mineure.patch+distance-hash
Par exemple 0.10.5+4-a1463178
 
Tu veux une release? Tu taggues le commit a1463178 avec 0.10.6 et voilà. On fait pas de RC mais tu peux si t'as envie.
 
Je comprends pas ton point 2, c'est en cache.

 
- Les outils de développement ne sont pas un sujet de business pour Google.
- On utilise piper, un gestionnaire de version centralisé, pour notre propre code
 
Du coup je ne pense pas. (Et il va de soi que en vérité j'en sais rien, et que je parle en mon nom.)

Officiel et gnome.

Après si gitlab tient pas plus de 5 utilisateurs, lol.

Après fondamentalement l'intérêt de github c'est surtout que tout le monde a un compte dessus, je peux ouvrir une issue ou faire une petite PR sans avoir à ouvrir des comptes sur 47 services différents.

 
Respect. Tu es indétrônable

https://gitlab.gnome.org/GNOME/gnome-builder ça n'a pas l'air vachement plus lent que github (à l'heure actuelle en tout cas)
 
Après il faut dire que la barre de chargement de github à un effet psychologique énorme aussi

 
1/ en général oui, avec Google Cloud je suis moyennement d'accord : avec Container Builder, ils cherchent vachement à mettre en avant l'intégration continue . Et sur ce terrain Azure est déjà vachement plus fort. C'est un use case tout à fait validé, et bien que rien ne t'empêche de le faire sur GCP, avec des outils tout packagés / SaaS est un super pratique (et : je me suis renseigné pour hoster mon blog dans le cloud (pour pouvoir automatiser les certificats, etc...) : Azure fournit nativement de quoi configurer ton propre pipe de compilation (j'ai besoin de lancer un exécutable sans libs sur un code source, et de oublier le résultat). GCP c'est vachement moins packagé
 
Bref, d'un point de vue client c'est une fonctionnalité désirable
 
2/ ça reste un problème de fond de GCP : c'est pas mangé en interne, Google a ses propres outils pour tout.

J'ouvre https://github.com/GNOME/librsvg mes devtools me disent 1.41MB, 2.67s, et la timeline est complètement finie (plus de xhr ou quoi) à 3.5s (j'ai vidé le cache d'abord).

J'ouvre https://gitlab.gnome.org/GNOME/librsvg, les devtools me disent 2.25MB, 7.76s, et la timeline arrête d'afficher des trucs à 10s.

Ça correspond plus ou moins à la différence d'impression quand je vais regarder les issues, voir les fichiers ou faire un blame.

Non.

ça a l'air de ramer là en effet, par contre j'ai l'impression que c'est au niveau des fichiers statiques que ça rame le plus (les images mettent pas mal de temps à charger même les plus petites), ça ressemble plus à une limitation matérielle du coup (les fichiers statiques sont servis par nginx directement, pas par l'instance de gitlab)

il me fait rire le PDG de MS: "jugez-nous sur nos résultats"  
 
ben j'utilise skype, c'est une horreur.

Microsoft? Changer? https://www.theregister.co.uk/2011/ [...] losed_sum/ http://techrights.org/2017/04/04/m [...] x-watches/
 
Il y a quelque temps sourceforge était de facto le point central du logiciel libre, et on a vu ce qu'un rachat pouvait donner dans ce genre de scénario.  
Github a pris la place de sourceforge (et bien plus), à mon avis une partie de la réaction vient de là.
 
Microsoft hébergeant une part significative du monde opensource doit soulever au minimum quelques questions imho.
 

 
Je confirme pour Skype. J'ai rarement utilisé et j'en avais besoin la semaine dernière pour un call.  
Après 15 min à essayer de faire marcher le truc (j'ai jamais réussi à trouver mon nickname alors que j'étais loggué), je suis allé sur appear.in et en 15 secondes j'étais en call avec mon interlocuteur.

D'un autre côté les projets genre VSCode, Typescript et LSP ont l'air relativement bien gérés. Je suis pas utilisateur (ptet éventuellement de LSP), mais j'en entends rarement du mal.

Je pense que ça dépend pas mal du système de gouvernance et donc du nombre de PMs impliqués. Si github reste relativement indépendant et se tape pas 25 PM par feature il n'y a pas de raison que ça se passe mal, si tout le monde veut y mettre les doigts et que tu te retrouves avec une situation [bouton shutdown](http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html) t'es foutu.

Ça va dépendre à quel point github est considéré comme une propriété "phare" de MS.

edit: Microsoft Research aussi, la majorité du développement de GHC vient de Microsoft Research Cambridge.

Vscode et TS. Clairement les deux choses que je kiff en 2018.  

'tain, je suis en train de dev un bricolage absolument immonde dans l'urgence, et ça doit être utilisé par des milliers d'utilisateurs dans 1 mois...

J'imagine que personne ici n'a déjà cherché à se servir de curl dans du php pour servir de proxy d'accès à une appli java sous tomcat en y ajoutant une surcouche d'authentification multi-sources maison?

Ça a l'air fun et bien géré

 
 
https://kaamelott-soundboard.2ec0b4 [...] out_a_fait

Tu veux coder un SSO à la main en 1 mois en PHP?
 
T'as songé à regarder ce qui était dispo dans les modules apache ou nginx? Ou considéré faire ça avec nginx & lua?

Je confirme, c'est de la merde
Qualité de service digne d'une communication transatlantique à l'époque de Graham Bell.