Exploration de la base de données LKML

NB : ce qui suit est un document de travail

Nous avons récolté l’ensemble des données disponibles sur l’archive de la Linux Kernel Mailing List à l’aide de notre scraper. Il a suffi d’environ 15 heures au script pour récupérer à peu près 2,5 millions d’emails, le premier datant du 23 juin 1995 et le dernier du 31 octobre 2016. Nous avons récupéré diverses métadonnées dans un fichier csv (0.8 Go) ainsi que le corps de tous les emails (16Go bruts, 4Go compressés).

Cette base de données pourra s’avérer utile à plusieurs titres :

1. Donner une perspective d’ensemble sur les circonstances qui ont mené à la création de git entre 1995 et 2005 : le volume d’emails était-il vraiment devenu ingérable ? Peut-on discerner d’autres motifs qui confirment ou enrichissent notre compréhension de la genèse du dispositif ?
2. Nous informer sur la relation entre git et des gestionnaires de version sur les échanges entre développeurs : l’implémentation d’un gestionnaire de version change-t-elle significativement la nature des échanges ? Observe-t-on une nouvelle hiérarchie dans les conversations avant et après l’emploi de git ? Ou à l’inverse, les données de collaboration git imitent-elles celles de la LKML ?
3. Être un outil pour nous assister dans le travail qualitatif de lecture des archives, pour identifier les conversations intéressantes (polémiques, mots-clés pertinents, etc.).

Pour l’instant, nous nous contentons d’une analyse exploratoire en suivant les étapes suivantes :

• Préparation des données
• Évolution du volume d’échanges sur la LKML
• Dates et horaires des contributions
• Peut-on voir qui répond à qui ?
• Bilan

Préparation des données

Étant donné la taille de la base de données et les requêtes relativement coûteuses à mener, nous allons utilisons le paquet data.table dans R :

library(data.table)
library(ggplot2)
library(ggthemes)

Commençons par charger la base de données en mémoire :

# Load dataset and drop useless columns
lkml <- fread('hypermailByEmail.csv',
              drop = c("emailId", "mailingList","timeSent","timeReceived"))

Pour les besoins de l’analyse, il est plus pratique d’avoir plusieurs variables pour la date qu’une unique variable année-mois-jour heures:minutes:secondes fuseau. Nous devrions d’ailleurs l’incorporer directement dans le scraper pour simplifier les analyses par la suite.

# Reorganize datetime metadata
lkml[, `:=` (sentDate = as.IDate(timestampSent),
             sentTime = as.ITime(substr(timestampSent, 12, 19)),
             sentTZ = substr(timestampSent, 20, 24),
             receivedDate = as.IDate(timestampReceived),
             receivedTime = as.ITime(substr(timestampReceived, 12, 19)),
             receivedTZ = substr(timestampReceived, 20, 24),
             timestampSent = NULL,
             timestampReceived = NULL)]

Enfin nous indexons nos données sur la date et l’horaire de réception du message. Nous limiterons aussi notre étude exploratoire aux années 1995-2015, l’année 2016 n’étant pas encore terminée. Il nous reste environ 2,4 millions d’emails dans la base.

# Set keys by reference
setkey(lkml, receivedDate, receivedTime)
# Focus on 1995-2015
lkml <- lkml[year(receivedDate) >= 1995 & year(receivedDate) <= 2015]

Évolution du volume d’échanges sur la LKML

Comme nous l’avons montré lors d’une première exploration des archives de la LKML, le problème majeur qui a occasionné une réflexion sur le choix d’un gestionnaire de version était la croissance du nombre de contributeurs et de correctifs envoyés directement à Linus Torvalds. Bien que nous n’ayons pas accès à ses archives personnelles, il est raisonnable de penser qu’on devrait observer conjointement une augmentation du volume de messages sur la LKML. C’est ce que nous allons vérifier.

Nombre de messages

On commence par s’intéresser très simplement à l’évolution du nombre de messages sur la LKML. Nous essayons d’identifier sommairement les messages automatiques générés par git [Voir plus loin] à partir de 2005 :

msgByYear <- lkml[, .(.N,
                    auto = sum(grepl("\\[.*\\d{1,2}/\\d{1,2}.*\\]", subject))),
                  by = year(receivedDate)]
msgByYear.m <- melt(msgByYear, id.vars = "year")
ggplot(msgByYear.m, aes(x = year, y = value, fill = variable)) +
  geom_bar(stat = "identity") + theme_minimal()

Nous observons très peu de messages en 1995 parce que l’archive commence en cours d’année (au mois de juin). Néanmoins, nous constatons bien une forte augmentation (facteur 2) du nombre de messages sur la LKML entre 1997 (24 225 messages) et 1998 (52 299 messages), ce qui correspond effectivement aux années qui précèdent la première crise autour des gestionnaires de version en 1998. La croissance du nombre de messages à partir de 2005-2006 est en partie liée à des messages automatiques, générés automatiquement par git.

Nombre de contributeurs

Il importe de déterminer dans quelle mesure la croissance du nombre de messages est liée à une implication plus importante des développeurs et à un nombre croissant de contributeurs. Essayons de voir comment le nombre de contributeurs évolue au fil du temps. Nous avons deux proxies possibles : le nom de l’expéditeur ou l’adresse email.

sNameByYear <- lkml[,
  .(count = 1),
  by = .(year(receivedDate), senderName)
  ][,
    .(nb_sender_name = sum(count)),
    by = year
  ]
sEmailByYear <- lkml[, .(count = 1), by = .(year(receivedDate), senderEmail)][, .(nb_sender_email = sum(count)), by = year]
senderByYear <- merge(sEmailByYear, sNameByYear)
senderByYear.m <- melt(senderByYear, id.vars = 'year')
ggplot(senderByYear.m, aes(x = year, y = value, fill = variable)) +
  geom_bar(stat = "identity", position = "dodge") + theme_minimal()

Plusieurs remarques :

• On observe bien un bond important de contributeurs entre 1997 et 1998.
• L’évolution du nombre de contributeurs est loin d’être linéaire, elle diminue même assez significativement entre 2006 et 2007 (baisse d’environ 1000 contributeurs). Faut-il interpréter ces baisses comme le résultat de scissions ou de découragement, ou bien s’agit-il d’opérations de maintenance (mise en place d’un meilleur filtre anti-spam, par exemple) ? [À FAIRE]
• On a plus toujours plus d’emails uniques que de noms d’utilisateurs : il est probable que les utilisateurs aient plusieurs adresses. On remarque d’ailleurs que le nombre d’emails augmentent fortement en 2014, ce qui est lié à une innovation dans git (publication de correctifs sur la LKML via une adresse spécifique git-bot). Pour les années antérieures, il nous faudra vérifier qu’il ne s’agit pas simplement d’un malfonctionnement de l’archive email et tirer parti de l’information pour identifier les expéditeurs à coup sûr. [À FAIRE]

Il serait également intéressant de connaître les développeurs qui ont le plus contribué à la LKML, et si leurs contributions étaient des réponses ou bien des nouveaux messages :

lkml[,
     .(.N,
       re = sum(grepl("Re\\s?:", subject, ignore.case = T))),
     by = .(senderName)][, ratio := round(re/N, 2)][order(-N)]

De ce tableau, on peut faire l’hypothèse que les mainteneurs (Linus, Cox, Miller, etc.) ont typiquement un ratio de réponses plus important (90% et plus) que les autres contributeurs, puisque leur fonction les oblige à modérer et à corriger les correctifs soumis à la LKML.

Nombre de nouveaux sujets

Nous voudrions aussi voir quel est le ratio de messages qui commencent une conversation par rapport au nombre de réponses :

newMsgByYear <- lkml[year(receivedDate) >= 1995,
                     .(new = .N,
                       re = sum(grepl("Re\\s?:", subject, ignore.case = T))),
                     by = year(receivedDate)][, new := new -re ]
newMsgByYear.m <- melt(newMsgByYear, id.vars = "year")
ggplot(newMsgByYear.m, aes(x = year, y = value, fill = variable)) +
  geom_bar(stat = "identity", position = "dodge") + theme_minimal()

Quelques remarques :

• 1995-1997 : le ratio est d’environ deux réponses pour un nouveau message.
• À partir de 1998, ce ratio augmente assez notablement, on a à peu près 3 réponses pour un nouveau message, la taille moyenne des discussions augmente. C’est peut-être une conséquence “logique” de l’augmentation du nombre de contributeurs ; ou bien un reflet de la nouvelle vivacité des discussions (emails avec plusieurs dizaines voire centaines de réponses lors de discussions polémiques, comme dans la crise de septembre 1998).
• À partir de 2005, on remarque que l’augmentation du nombre de nouveaux messages est plus rapide que celle des réponses. C’est probablement lié aux nouvelles fonctionnalités de git et la capacité d’envoyer rapidement un email pour documenter son correctif [voir plus loin].

Dates et horaires des contributions

Les dates et les horaires des contributions peuvent nous fournir plusieurs informations intéressantes :

• Tout d’abord, il pourrait être intéressant de connaître les horaires d’envoi d’emails pour reconnaître les personnes qui contribuent sur leur temps libre (envoi de nuit, tôt le matin ou durant le week-end).
• Ensuite, nous pourrons utiliser les dates et les horaires d’envoi pour constater le temps de réaction à différents types d’emails, et voir si certaines discussions « s’emballent » plus que d’autres.

Nous avons collecté deux métadonnées qui datent les emails : la date d’envoi et la date de réception. Loin d’être redondantes, ces informations peuvent apporter des informations supplémentaires pour l’analyse :

• Dans les années 1990, il nous a semblé que le delta entre l’envoi et la réception était considérable (souvent plusieurs minutes, parfois plusieurs heures), ce qui témoigne probablement de la qualité des connexions Internet des développeurs ou des aléas du serveur email.
• La métadonnée de date et d’horaire d’envoi contient le fuseau horaire, ce qui pourrait nous donner une information rudimentaire sur la localisation des contributeurs.

Malheureusement, à partir de 2003, il semble que les métadonnées d’envoi sont des simples copies de celles de la réception… Notre analyse des horaires des contributions sera pour l’instant cantonné à cette période.

Horaires

Commençons par étudier les horaires des programmeurs entre 1996 et 2002. Puisque le volume d’emails évolue considérablement, nous avons choisi d’observer les variations en pourcentages :

hourByYear <- lkml[
  year(sentDate) >= 1996 & year(sentDate) <= 2002,
  .N,
  by = .(hour = hour(sentTime), year = year(sentDate))
  ][, prop := N/sum(N), by = year][order(year, hour)]
ggplot(hourByYear, aes(x = hour, y = prop, fill = factor(year))) + 
  geom_bar(stat = "identity", position = "dodge") + theme_minimal() +
  theme(legend.position = "bottom")

Nous constatons une augmentation du nombre d’emails envoyés pendant l’après-midi (14h-17h) ainsi qu’une diminution marquée du nombre d’emails envoyés entre 7h et 9h. À première vue, cela pourrait suggérer que les profils des contributeurs se professionnalisent ; il faudra le vérifier par la suite.

Jour de la semaine

Nous effectuons la même analyse pour les jours de la semaine (1 = dimanche, 2 = lundi, …, 7 = samedi) :

wdayByYear <- lkml[
  year(sentDate) >= 1996 & year(sentDate) <= 2002,
  .N,
  by = .(wday = wday(sentDate), year = year(sentDate))
  ][, prop := N/sum(N), by = year][order(year, wday)]
ggplot(wdayByYear, aes(x = factor(wday), y = prop, fill = factor(year))) + 
  geom_bar(stat = "identity", position = "dodge") + theme_minimal() +
  theme(legend.position = "bottom")

Nous constatons ici que l’activité est réduite pendant le week-end (jour 1 et 7), mais aucune évolution temporelle claire n’est perceptible.

Peut-on voir qui répond à qui ?

L’objectif est, à terme, de faire des analyses de réseau sur la LKML, de détecter les motifs par sujet, etc. Pour cela, nous aurons besoin de savoir à quel email répond un message. Malheureusement, cette question n’est pas triviale. Dans les métadonnées récupérées, nous avons bien un champ indiquant à quel email un message répond, mais ce dernier fait souvent défaut.

Notre but est donc d’évaluer la qualité du champ replyto, en le confrontant à un autre indicateur, la présence du mot-clé “Re:” dans le sujet de l’email.

msgsByYear <- lkml[,
                   .(messages = .N,
                     re_in_subject = sum(grepl("Re\\s?:", subject, ignore.case = T)),
                     nb_replyto = sum(!is.na(replyto))),
                   by = year(receivedDate)][,ratio := nb_replyto/re_in_subject]
msgsByYear

Pour plus de visibilité, traçons l’évolution du ratio \(\frac{\text{Nombre de replyto}}{\text{Nombre de "Re"}}\) :

ggplot(msgsByYear, aes(x = year, y = ratio)) + geom_point() + theme_minimal()

Nous constatons non pas un, mais deux problèmes :

• Le ratio est très bas avant les années 2000 (\(<0.4\)), ce qui est cohérent avec nos observations réalisées lors du travail d’archives.
• Plus surprenant, le ratio dépasse 1 en 2005, ce qui signifierait que des contributeurs se répondent entre eux sans utiliser le mot-clé “Re:”.

Autrement dit, il est possible que le ratio s’améliore non pas parce que la première catégorie d’emails diminue mais parce que la deuxième augmente. Vérifions cette hypothèse avec le graphique suivant :

replByYear <- lkml[,
                   .(re_no_reply = sum(grepl("Re\\s?:", subject, ignore.case = T) & is.na(replyto)),
                     reply_no_re = sum(!is.na(replyto) & !grepl("Re\\s?:", subject, ignore.case = T))),
                   by = year(receivedDate)]
ggplot(replByYear) +
  geom_point(aes(x = year, y = re_no_reply, colour = "Re sans replyto")) + 
  geom_point(aes(x = year, y = reply_no_re, colour = "Replyto sans Re")) + theme_minimal()

Effectivement, on constate une grande augmentation de la deuxième catégorie après 2005. Comme notre analyse va, dans un premier temps, se concentrer sur la période qui précède 2005, ce « problème » n’est pas si urgent.

En revanche, il est clair que l’archive a connu de nombreux déboires en 1998 et 1999 : les emails étant manifestement des réponses (contenant “Re:” dans le titre) mais sans champ replyto sont très nombreux. Ces années étant cruciales pour comprendre la conception de Git, il nous faudra trouver un moyen de palier ce défaut de la base de données.

Le cas des emails “Re:” sans replyto

L’une des solutions envisagées pour reconstituer a posteriori le champ replyto est de créer un script qui explore le contenu des emails. Sur la LKML, il est de coutume de citer le passage de l’email auquel on répond dans le corps du message (voir un exemple ici).

Toutefois, cette méthode peut s’avérer très fastidieuse (temps de calcul), surtout appliquée à 272286 emails. Toute information supplémentaire nous aidera à optimiser l’algorithme. C’est pourquoi nous essayons de trouver quelques mécanismes a priori pour expliquer ce phénomène de non-réponses.

L’archive est structurée en petits dossiers qui regroupent les emails reçus selon la date. Les groupes sont déterminés selon le schéma suivant :

• 1-7 janvier 1995
• 8-15 janvier 1995
• 16-23 janvier 1995
• 24-31 janvier 1995
• 1-7 février 1995
• …

En explorant l’archive, une des hypothèses émise est que l’archive repère mieux les réponses quand une conversation se déroule dans l’un de ses intervalles, mais pas quand elle commence dans l’un et se termine dans l’autre. Un échange se tenant entre le 3 et le 6 du mois aura donc beaucoup plus de chances de conserver son replyto intact qu’une conversation ayant lieu sur plusieurs semaines.

Si cette hypothèse est vraie, et si nous supposons que la plupart des contributeurs répondent rapidement (1-2 jours) aux emails, on devrait alors observer un pic d’emails sans replyto autour du 1, 8, 16 et 24 du mois. C’est ce que nous vérifions avec le graphique suivant :

reNoReply <- lkml[grepl("Re\\s?:", subject, ignore.case = T) & is.na(replyto),
                  .N,
                  by = mday(receivedDate)]
ggplot(reNoReply, aes(mday, N)) + 
  geom_bar(stat = "identity") + theme_minimal()

Cette hypothèse semble confirmée. Il faudrait maintenant aller plus loin et vérifier si ce phénomène est uniquement valable pour les messages qui répondent après ces jours limites à un email reçu avant [À FAIRE]. Si c’est bien le cas, alors l’algorithme pourra fonctionner comme suit :

Pour chaque email "Re" sans replyto :
  Extraire la citation de l'email
  Pour chaque email dans la même conversation envoyé avant le 1, 8, 16 ou 24 :
    Vérifier si la citation correspond à l'email
    Si oui :
      Remplir le champ `replyto`

Le cas des emails replyto sans “Re:”

Dans le cas des emails ayant un champ replyto non vide mais pas le mot-clé “Re:” dans le sujet, nous n’avons pas repéré de motifs similaires, ce qui nous laisse penser qu’ils ne sont pas un artefact de l’archive elle-même.

Pour nous faire une meilleure idée de ces cas de figure, nous regardons les 50 premiers mails de ce type pour chaque année :

replyNoRe <- lkml[!grepl("Re\\s?:", subject, ignore.case = T) & !is.na(replyto),
                  .(subject, year = year(receivedDate), senderName, url)]
setkey(replyNoRe, year)
replyNoRe[.(1995:2015), .SD[1:min(50,.N)], by = .EACHI]

Notre exploration de ces emails nous amène à distinguer deux sous-catégories.

Liens de filiation entre différentes conversations

Certains emails semblent être les premiers d’une conversation, mais répondent en réalité à un autre email. Il est probable que cela soit dû au comportement des clients emails des contributeurs, qui répondent à un message avant de changer le sujet, auquel cas le mail conserve la métadonnée de réponse même si le sujet ne contient pas le mot-clé « Re : ».

Il faudra décider de la façon dont nous traiterons ces emails : ouvrent-ils de nouvelles conversations ou bien prolongent-ils une même discussion avec un titre différent ? Une décision raisonnable pourrait être de les considérer comme de nouvelles conversations, et que l’information replyto joue ici le même rôle que le mot-clé “Was:” pour indiquer des liens de filiation entre différentes discussions.

Emails produits par bitkeeper et par git

D’autre part, à partir de 2003, nous remarquons que la plupart des emails contiennent des sujets de ce type :

[PATCH 1/3 RFC] Coccinelle: drop unecessary duplicated init_compltion calls
[PATCH 2/3 RFC] Coccinelle: check for incorrect DECLARE_COMPLETION use
[PATCH 3/3 RFC] Coccinelle: incorrect use of multiple init_completion   

Ils sont de plus rédigés par la même personne.

Il s’agit visiblement d’une fonctionnalité des gestionnaires de version apparue en 2003 dans bitkeeper et implémentée par la suite dans git, ce qui explique que ces emails se multiplient après 2005, date d’adoption officielle de git. Pour résumer, les contributeurs du noyau peuvent soumettre un correctif à la LKML directement depuis la ligne de commande. S’ils modifient n fichiers, alors [PATCH 0/n] contient le message explicatif et les [PATCH 1/n]…[PATCH n/n] contiennent les diff pour chaque fichier modifié.

Ces emails ne sont donc ni un bug de l’archive, ni des « vrais » emails (ils n’ont pas été rédigé par leur expéditeur).

Bilan

Il reste encore un travail relativement important à effectuer pour nettoyer et standardiser la base de données, en particulier pour récupérer les replyto, mais cela nous paraît réalisable. Par ailleurs, il nous faudra travailler sur la base pour être en mesure de produire facilement des analyses à 3 niveaux : les contributeurs, les conversations (un message et ses réponses) et les messages individuels. À partir de là, nous pourrons procéder à des analyses plus complexes (analyse de réseau, clustering et classification).

Enfin, dans un second temps, il pourra être intéressant d’incorporer le contenu des emails à la base pour l’enrichir (textmining) avec de nouvelles caractèristiques (longueur des emails, mots-clés employés, etc.).