Topic: Ultime novità su Thunderbird

[pegasoc]

Come non detto. 

[deckard]

Staremo a vedere, anche se sono molto curioso di conoscere le opinioni - tra gli altri - di deckard, next e filigrana... 

Io ho dato una occhiata alla Tabella delle Caratteristiche e al sito.
Betterbird si propone come una alternativa migliorata di Thunderbird perché contiene nuove funzionalità esclusive, contiene correzioni di bug esclusive e contiene correzioni che Thunderbird potrebbe fornire in una fase successiva. A onore del vero diverse di queste funzionalità sono richieste da tempo, come pure le correzioni ai bug. Bisognerebbe cercare di capire perché certe funzioni non siano presenti in Thunderbird, come pure le correzioni e adoperare la giusta imparzialità. Il rischio è che guerre filosofiche e religiose applicate all'informatica miste a una visione incompleta e opinionata porti a trarre delle conclusioni scarsamente funzionali.
È ovvio che si può apprezzare ogni progetto che nasce sinceramente per venire incontro alle necessità dell'utenza, ma non riesco ancora ad avere una visione obiettiva.

[Omissis...]
Conoscevo Betterbird solo di striscio perché è una delle soluzione che si trovano su alternativeto.net come alternativa a Thunderbird. Non l'ho provata, ma mi pare che alcune cose interessanti ci siano. Tuttavia nasce in modo troppo polemico per i miei gusti. Non ho nulla contro i fork, ma farli sulla base del «non si è fatto quello che dicevo io» non è la migliore premessa. Questo non toglie che su alcune cose il team di Thunderbird sembri davvero troppo autoreferenziale.

Se «non si è fatto quello che dicevo io» forse qualche ragione c'è. Se si è trovato il modo di implementare delle funzionalità all'interno di Thunderbird e di correggere dei difetti o dei bug, forse si poteva anche trovare il modo di migliorare il dialogo con il team di Thunderbird e adoperarsi per comprendere se e come apportare determinate modifiche all'interno del progetto originario. Credo che ne gioverebbero tutti...

[pegasoc]

... forse si poteva anche trovare il modo di migliorare il dialogo con il team di Thunderbird e adoperarsi per comprendere se e come apportare determinate modifiche all'interno del progetto originario. Credo che ne gioverebbero tutti...

Forse sbaglio perchè non è che seguo molto l'argomento ma mi sembra che Mozilla non sia molto aperta alle richieste degli utenti e a suggerimenti che non vanno nella direzione che dice lei.

[deckard]

In alcuni casi probabilmente si sarebbe potuto rimediare perché almeno alcune delle modifiche che sono state inserite in Betterbird erano compatibili con la direzione scelta da Mozilla e da Mozilla Messaging.
C'è stata una “chiamata alle armi” affinché si fornissero delle idee ad Alessandro @alecaddd Castellani ed egli ci venisse incontro fornendoci dei riscontri.
Oltre a ringraziarlo per il lavoro gli si potrebbe sottoporre alla sua attenzione anche questo elenco.

Le scelte sullo sviluppo di un software vanno accettate e rispettate, ma ritengo che sia poco funzionale e scarsamente strategico chiudersialle richieste degli utenti e a suggerimenti...

[filigrana]

A onore del vero diverse di queste funzionalità sono richieste da tempo, come pure le correzioni ai bug

piuttosto emblematica è la questione già citata altrove fino alla noia del bug 243258 https://bugzilla.mozilla.org/show_bug.cgi?id=243258 aperto il 10/05/2004 dove hanno praticamente chiuso i commenti perchè secondo loro erano irrispettosi e inaccettabili...
certo, se lasci aperto 20 anni un bug, gli utenti (anche piuttosto avanzati, visto il portale) ti chiedono con insistenza di risolverlo perchè è un bug di sicurezza, tu non solo non lo assegni a nessuno, ma invece di rassicurare in qualche modo chiudi la discussione, poi non venire a piangere se la gente ti molla e cambia programma eh?

[deckard]

In inglese c'è un espressione “to come to terms” che suona più o meno come: raggiungere un accordo, scendere a patti, venire a patti, ma anche, in senso figurato, arrivare ad accettare, riuscire ad accettare, accettare.
Forse bisogna riuscire ad accettare che l'approccio alla risoluzione dei bug e la proposta di nuove funzionalità dovrebbero trovare una situazione di dialogo tra l'utenza e gli sviluppatori per quanto ci possano essere delle linee guida su dove l'azienda vuole andare a parare.
Oltre al fatto che probabilmente dovremmo rivedere gli strumenti per capire che cosa serve veramente all'utenza e comprendere che la telemetria non è affidabile da questo punto di vista.
I riscontri da parte dell'utenza servono e continueranno a servire per sapere, ma per capire che cosa funziona oppure no e che cosa manca forse dovremmo veramente procedere per slu77 altre vie....

[filigrana]

slu77

[deckard]

Gatta Birra che diceva cose... Comunque altra cosa su cui forse bisognerebbe convenire è la comprensione di quali siano, onestamente e rispettosamente parlando, le priorità e la missione aziendale di Mozilla Messaging e le capacità lavorative di far fronte alle richieste e alle aspettative dell'utenza, anche solo per assegnare la risoluzione di un bug, fosse anche soltanto per dire che hanno capito che è una richiesta importante, ma il personale è impegnato nella risoluzione di altri bug / problemi...
Se poi sia giusto che si adoperi Bugzilla per proporre nuove funzionalità (anche quando queste vanno a correggere gravi difetti di implementazione di Thunderbird) oppure no, questo è un altro discorso...

[next]

anche solo per assegnare la risoluzione di un bug, fosse anche soltanto per dire che hanno capito che è una richiesta importante, ma il personale è impegnato nella risoluzione di altri bug

Penso che sia un problema anche motivazionale. Se hai le competenze per lavorare su un codice complesso come quello di Thunderbird, forse a correggere piccoli bug ti passa anche un po' la voglia.
Forse -e dico forse- sarebbe il caso di assumere qualche programmatore con questa specifica mansione (risorse permettendo)

[deckard]

Per lavoro avevo conosciuto una azienda settentrionale nel settore metalmeccanico, azienda gestita da dei fratelli e uno di loro, pur essendo socio e consigliere delegato, si trovava in più occasioni alla reception mentre rispondeva alle telefonate o cambiava la carta alla stampante o svolgeva altre mansioni che non fossero puramente dirigenziali. Forse si tratta di umiltà e di modestia, forse si tratta anche di fare la gavetta e di sapersi dar da fare e rendersi utili...
Io posso comprendere il discorso motivazionale e le competenze, ma una azienda è fatta da persone oltre che di cose e da assetti.
Anzi le aziende forse sono fatte prima ancora dagli individui che la portano avanti con le varie mansioni e poi da ciò che le compone come le immobilizzazioni e i cespiti...
Credo anche io che sarebbe il caso di assumere qualche programmatore con questa specifica mansione (le risorse possono essere trovate se ci si impegna e si riesce a vedere l'opportunità insita in ciò...)...

Post scriptum:

Penso che sia un problema anche motivazionale. Se hai le competenze per lavorare su un codice complesso come quello di Thunderbird, forse a correggere piccoli bug ti passa anche un po' la voglia.

Quelli che sono “piccoli bug” rischiano di essere delle bucce di banana su cui scivolare e dettagli che possono lasciare a pensare a un ipotetico e putativo osservatore cose non vere o tendenziose (e irrispettose della fatica profusa fin ora), cioè che l'azienda ha poco interesse nell'ascoltare l'utenza e nel venire incontro alle sue esigenze.
Capisco il burn-out, comprendo pure la perdita di motivazioni, ma non il messaggio che leggo fra le righe e andando oltre tutto ciò.
Poi è ovvio che l'adozione di un programma non è un matrimonio indissolubile ed è altresì ovvio che non è corretto andarsene limitandosi a sbattere i tacchi mentre ci si volta e si proferiscono parole intrise di sangue cattivo che nemmeno a una riunione di persone ammalate di emofilia...
Spesso il diavolo si infila nei dettagli... e si sa che “Le peggiori cose sono sempre state fatte con le migliori intenzioni.” — Oscar Wilde

[next]

Forse si tratta di umiltà e di modestia, forse si tratta anche di fare la gavetta e di sapersi dar da fare e rendersi utili...

Quelli che sono “piccoli bug” rischiano di essere delle bucce di banana su cui scivolare e dettagli che possono lasciare a pensare a un ipotetico e putativo osservatore cose non vere o tendenziose (e irrispettose della fatica profusa fin ora), cioè che l'azienda ha poco interesse nell'ascoltare l'utenza e nel venire incontro alle sue esigenze.
Capisco il burn-out, comprendo pure la perdita di motivazioni, ma non il messaggio che leggo fra le righe e andando oltre tutto ciò.

Come me, caro deckard, sfondi la proverbiale porta aperta. Sia perché ho fatto lavori di basso profilo (e non non ho problemi a farli anche ora), sia perché provengo da un ambiente in cui lavoro è sempre da rispettare.
Quando sento alcuni discorsi pompati su quanto sia fondamentale la ricerca, l'alta specializzazione, il lavoro intellettuale, la cultura e via dicendo*, ricordo a tutti che un mese di sciopero degli operatori ecologici e la civiltà come la conosciamo sarebbe finita. E non credo di esagerare peraltro.

Il mio era un discorso più generale e descrittivo conoscendo un po' l'ambiente informatico e quello della programmazione dove purtroppo ci si entusiasma per delle sciocchezze (ricordi il cubo di Compiz?) e ci disinteressa degli elementi fondanti (Heartbleed, Spectre, Meltdown, il recentissimo XZ stanno li a ricordarcelo).

_{* non che non lo siano ovviamente, ma l'argomentazione è usata in modo pretestuoso per chiedere privilegi, tutele, retribuzioni oltre la decenza, riconoscimenti pubblici automatici, vantaggi sociali, e via di questo passo.}

[deckard]

Certo che mi ricordo di Compiz e del fatto che è stato di moda per diverso tempo oltre a varie funzionalità avanzate per la gestione dei desktop virtuali quando poi io mi sono abbontantemente accontentato di ambienti come XFCE o Mate. Sì è vero che KDE Plasma è molto migliorato negli ultimi rilasci, che Cinnamom dà delle belle soddisfazioni, ma Less is More.
Ci sono vari problemi oltre a quelli citati da te come Poodle, EternalBlue e WannaCry, il componente aggiuntivo WOT, e via discorrendo, Avast cheaveva dei componenti aggiuntivi all'interno del Market di Mozilla e di Chrome adoperati per trafugare dati personali, et cetera...
Inutile avere il codice sorgente se nessuno lo analizza facendosi delle serie domande. Se Andres Freund non avesse fatto le sue indagini chissà se mai ci saremmo accorti del cyberattacco in corso?
Io non ho nulla contro i volontari, anzi ho profonda stima per i volontari. Quanti avrebbeo il fegato e la forza di, che so, andare a fare la clown terapia in un reparto di oncologia pediatrica senza andare in burnout? Ma se buona parte del mondo di Internet e del software libero si regge con il nastro adesivo di seconda mano, pardon sul lavoro di volontari ci sono tante cose che non vanno.
E non parlo solo del fatto che se il volontario succitato in tanti hanni ha ricavato solo mezzo grazie e quanto basta per un trancio di marinarara al fast food, una bottiglietta d'acqua frizzante e un caffè... non chiedo un fine settimana in un resort di lusso con centro benessere, terme, ristorante stellato e possibilità di rilassarsi in mezzo alla natura, magari vicino a un agriturismo...
Portare avanti un progetto non è un obbligo contattuale verso la comunità e se c'è un miliardo di persone che ha giovato del progetto forse dovremmo farci delle domande serie e fornirci delle risposte...

Poi c'è il discorso che la cultura è chiaramente importante, ma tutti i lavori hanno una dignità e meritano rispetto, anche far le pulizie dei cessi nel peggiore autogrill della autostrada A666.
Mio padre e altre persone che ho conosciuto sostenevano che prima di chiedere bisognerebbe pensare a che cosa si può dare e fare per il prossimo.

[miki64]

Test automatizzati: Come catturiamo i bug di Thunderbird prima di voi

Dal rilascio di Thunderbird 115, ci siamo concentrati sul miglioramento dello stato dei nostri test automatici.
I test automatizzati aumentano la qualità del software, riducendo al minimo il numero di bug introdotti accidentalmente dalle modifiche al codice. Per ogni modifica apportata a Thunderbird, le nostre macchine di test eseguono una serie di test su Windows, macOS e Linux per individuare errori e conseguenze non intenzionali.

Per una singola modifica (o per un gruppo di modifiche che avvengono nello stesso momento), da 60 a 80 test vengono eseguiti su Windows, macOS e Linux.

Il nostro codice sarà sottoposto a una pressione maggiore rispetto al passato, con un team più grande che apporta più modifiche e rilasci mensili che riducono il tempo che il codice trascorre nei canali di test prima di essere rilasciato.

Perché facciamo i test
Non scriviamo test solo per sentirci meglio. I test migliorano Thunderbird poiché:

    Prevengono gli errori
    Se sperimentiamo che un codice si comporta in un modo atteso, scopriremo immediatamente se non si comporta più in quel modo. Questo significa un ciclo di feedback più breve e possiamo risolvere il problema prima che infastidisca gli utenti.

Scopriamo quando qualcosa a monte ci "rompe"
Thunderbird è costruito a partire dal codice di Firefox. Il codice di Firefox, di cui non siamo responsabile, è da 30 a 40 volte più grande del codice di cui siamo responsabili. Quando inevitabilmente in Firefox cambia qualcosa che ci riguarda, vogliamo saperlo immediatamente per poter reagire.

Liberare i tester umani
Se usiamo i computer per dimostrare che il programma fa quello che dovrebbe fare, in particolare se si evitano
ripetizioni noiose e compiti difficili da impostare, allora le limitate risorse umane di cui disponiamo possono fare più cose in cui gli uomini sono migliori delle macchine.
Per esempio, ho aggiunto di recente dei test che verificano 22 modi per attivare il fetching mail e 10 circostanze in cui il recupero della posta potrebbe non funzionare.
È impossibile che i nostri tester umani (per quanto bravi) li verifichino tutti, ma i nostri test automatici possono farlo e lo fanno, più volte al giorno.

Pensare a ciò che il codice dovrebbe fare
I test  costringono un ingegnere a guardare il codice da un punto di vista diverso, e questo è utile per pensare a ciò che il codice dovrebbe fare in più circostanze. Inoltre, rende più facile dimostrare che il codice funziona in circostanze oscure.

Trovare i bug esistenti
In termini di software, stiamo lavorando con un codice molto vecchio e in gran parte non "testato". Provarlo
è un nuovo punto di vista sul codice e rivela alcuni degli errori del passato, dove il tempo ha danneggiato le cose. Inoltre aiuta la persona che scrive i test a capire cosa fa il codice, molto più di quanto non faccia la semplice lettura del codice.

Non stiamo cercando di coprire completamente una funzione o ogni caso limite nei test. Stiamo cercando di creare un framework di test intorno alla funzione, in modo che quando troviamo un bug, oltre a risolverlo, possiamo facilmente scrivere un test per evitare che il bug si ripeta senza essere notato. Per gran parte del codice, questo è stato impossibile senza una settimane di test.

Infrangere nuovi orizzonti
Negli ultimi mesi abbiamo capito come eseguire test automatizzati per cose che prima erano impossibili:
    - Comunicazione con server di posta tramite canali crittografati.
    - Autenticazione OAuth2 con server di posta.
    - Non deve essere utilizzato la comunicazione con server web dove deve essere utilizzato un indirizzo specifico e un canale non crittografato.
    - Server su qualsiasi nome host o porta.

In precedenza, se volevamo avviare un server per i test automatizzati, doveva trovarsi sul computer locale in una posizione non standard. Ora possiamo far finta che il server sia ovunque e utilizzi porte standard, necessarie per provare adeguatamente le funzionalità di configurazione dell'account. (In realtà prima era possibile, ma ora è molto più semplice).

Queste nuove funzionalità vengono utilizzate per effettuare test migliori sulle funzionalità di configurazione dell'account, in vista dello sviluppo del nuovo Account Hub, in modo da poter essere sicuri che nulla si "rompa" senza essere notato. Aiutano anche a verificare che la raccolta della posta funzioni quando dovrebbe o forniscano i messaggi di errore previsti quando non funziona.

Copertura del codice
Registriamo ogni riga di codice eseguita durante i nostri test. La raccolta di tutti questi dati indica quale codice non viene eseguito durante i nostri test. Se un blocco di codice non viene eseguito durante uno qualsiasi dei nostri test, nulla ci dirà quando si danneggia finché qualcuno non usa il codice e si lamenta.

I nostri dati sulla copertura del codice possono essere visualizzati su cover.thunderbird.net . Puoi anche consultare i dati di Firefox su cover.moz.tools .

Osservando i dati, potresti notare che il nostro numero complessivo è ora inferiore rispetto a quando abbiamo iniziato a misurare. Ciò non significa che i nostri test siano peggiorati, in realtà mostra dove abbiamo aggiunto molto codice (che non è gestito da noi) nella directory di terze parti. Per una migliore rappresentazione dei progressi che abbiamo fatto, controlla le singole directory, in particolare mail/base che contiene il codice dell'interfaccia utente più importante.

È sufficiente  impostare gli strumenti di copertura del codice e osservare i risultati per scoprire diverse perdite di memoria (una perdita di memoria è il punto in cui la memoria viene allocata per un'attività e non viene rilasciata quando non è più necessaria).
Abbiamo corretto queste perdite e alcune altre che esistevano nel nostro codice di test. Ora abbiamo livelli molto bassi di perdite di memoria durante i nostri test, quindi se commettiamo un errore è facile da individuare.
I dati sulla copertura del codice possono anche indicare codice che non viene più utilizzato. Abbiamo rimosso alcune grosse parti di questo codice morto, il che significa che non stiamo perdendo tempo a mantenerlo.

Mozmill non più
Verso la fine dello scorso anno abbiamo finalmente ritirato una vecchia suite di test conosciuta come Mozmill. Questi test sono stati parzialmente migrati in una suite di test diversa (Mochitest) circa quattro anni fa e le cose funzionavano per lo più bene, quindi non era una priorità completarli. Questi test ora fanno le cose in un modo più convenzionale invece di fare affidamento su una serie di trucchi intelligenti ma strani.

Quanto del codice è codice di prova?
Circa il 27%. Si tratta di una stima molto approssimativa basata sui file nel nostro repository di codice (meno alcune directory di terze parti) e sul fatto che si trovino o meno all'interno di una directory con "test" nel nome. È aumentato da circa il 19% negli ultimi cinque anni.

Non c'è un obiettivo particolare in mente, ma posso immaginare un futuro in cui ci sarà tanto codice di test quanto codice non di test. Se riusciremo a raggiungere questo obiettivo, Thunderbird si troverà in una situazione molto sana.

https://blog.thunderbird.net/files/2024/03/Screenshot-2024-03-25-at-9.14.08%E2%80%AFAM.png

Guardando al futuro, chiederemo ai contributori di aggiungere test alle loro patch più spesso. Questo dipende ovviamente dalle circostanze. Ma se stai aggiungendo o correggendo qualcosa, è il momento migliore per assicurarti che continui a funzionare in futuro.
Come sempre, non esitate a contattarci se avete bisogno di aiuto per scrivere o eseguire test, tramite le mailing list Matrix o Topicbox:

    - Matrix: puoi unirti al nostro canale di chat di sviluppo su #maildev:mozilla.org
    - Topicbox mailing list:  l'elenco degli sviluppatori di Thunderbird è un buon posto per sollevare domande sullo sviluppo di Thunderbird.

Geoff Lankow, Staff Engineer

[Alessandro Castellani]

Salve a tutti, passo qui per dare un po di informazioni a grande linee.
Non posso parlarne troppo perchè alcune cose sono troppo spiacevoli e preferisco non condividerle per evitare problemi.
Ma ci tengo a chiarire dei fatti che purtroppo Jorg tende a distorcere.

Da un post di fabrix:

In realta volevo intervenire per segnalare Thunderbird con gli steroidi: Betterbird che ho trovato su Flatpak ma non ci tengo a provare

Orbene, a parte alcune dichiarazioni decisamente "forti" sul loro sito, c'è un mucchio di roba interessante contenuta nel sito del progetto.

Ciò che distingue Betterbird è il fatto che il suo sviluppatore principale non è altro che Jörg Knobloch, l'uomo che quasi da solo faceva andare avanti Thunderbird durante le sue ore più buie. Dopo essere diventato il suo primo dipendente, si è ritrovato scacciato per aver sollevato preoccupazioni per una mancanza di impegno per la qualità, una squadra di controllo qualità completamente scomparsa e un bug triage“ difettoso poco prima che il progetto passasse a un modello di proprietà aziendale a scopo di lucro.

Questo è abbastanza falso.
Jorg è stato bannato a causa di molteplici comportamenti negativi ed inappropriati contro membri dello staff. Ho lavorato con lui per quasi 3 anni e non è stato per niente piacevole.

Il punto sul "mancato controllo della qualità" lo trovo abbastanza divertente perchè i peggiori bug e crashes li abbiamo avuti quando lui era a capo e non ci teneva molto alla qualità del codice.

Il punto del modello aziendale penso si riferisca alla fondazione di MZLA Tech, che è una società for-profit.
Oltre a tanti motivi riguardanti la sostenibilità del prodotto e garantire la permanenza a lungo termine, era necessario questo passo per poter rientrare sotto Mozilla Foundation e poter usufruire del supporto legale e social, e anche ritornare sotto le regole del Mozilla Manifesto in modo ufficiale, così da garantire che Thunderbird rimanesse sempre Open, Free, and Ethical.

Jorg aveva un accordo molto particolare con un'altra società che lo pagava per lavorare su Thunderbird. Questa società non ha voluto più pagarlo perchè Thunderbird non era più "community driven", e lui ha iniziato ad avanzare richieste monetarie assurde. Quando il Consiglio di Thunderbird (non Mozilla, il consiglio eletto dalla community era a capo a quel tempo) non ha accettato le sue richieste, lui ha deciso di non lavorare per 3 mesi, sparendo completamente e lasciando cose a metà, creando molti problemi technici.

La situazione è peggiorata molto rapidamente con altri comportamenti che non posso mensionare, e questo a portato all decision del consiglio di bannarlo permanentemente.

... Betterbird dimostra come l'app tenti di risolvere problemi di lunga data —, una delle funzionalità principali (una visualizzazione della casella di posta multi-riga come quella utilizzata da Outlook) è stata una richiesta di funzionalità in Thunderbird dal 2003, ad esempio.

Jorg ha lavorato a Thunderbird per un decennio e non ha mai prestato attenzione a queste cose.
Quando inizialmente ho provato ad aggiornare la UI e modernizzare un po, uno dei suoi primi messaggi è stato "Non sprecare tempo su queste sciocchezze, Thundebird ha bisogno di impegno in altre parti e la UI non è importante" (parafraso perchè le sue parole erano molto più aggressive).

Thunderbird è veramente difficile e complicato da aggiornare e mantenere. Ogni volta che cambi una virgola in un punto un'altra sezione da una parte completamente diverse prende fuoco. Cambiare cose e farlo in modo corretto richiede tempo, ma ora che Jorg non deve più gestire niente, usa il suo tempo per creare queste patch di dubbia qualità per aggiungere funzionalità temporanee e chiamarle "better".

Altrove, altre modifiche includono opzioni personalizzabili come schede verticali, colori dell'account e la possibilità di visualizzare gli allegati sopra le e-mail, nonché vantaggi più pratici come il supporto per termini di ricerca complessi (comprese le espressioni regolari).

Stiamo lentamente implementando queste cose a nostra volta, ma ci vuole più tempo visto the dobbiamo aggiornare codice vecchio di 20 che si rompe ogni 10 minutes. Jorg preferisce aggiungere funzioni in modo veloce e senza test, invece di mantenere e migliorare l'architettura di base e garantire sicurezza e sostenibilità.

Capiamo benissimo che molti utenti non guardano queste cose, e molte delle migliorie fatte nel back-end non vengono neanche notate, ma stiamo cercando di andare un pochino più lenti proprio per garantire qualità e stabilità.

Gli utenti Linux ottengono per la prima volta un'icona nella barra delle applicazioni che mostra il numero di nuovi messaggi e puoi scegliere anche una cartella di avvio diversa. Fondamentalmente, è tutto completato da correzioni per bug lasciati intatti dal team di sviluppo di Thunderbird.

Praticamente Jorg ha usato un codice GPL per questa implementazione che va contro le limitazioni del codice MPL su cui Thunderbird è basato.
Ma vabbè, questi son dettaglie che forse non interessano, in ogni caso stiamo investigando l'implementazione di questa icona, nel mentre ricostruiamo il database vecchio di 20 anni per poter supportare conversation view

In generale come policy a Mozilla, adoriamo forks e miglioramenti dalla community, ma non possiamo supportare ne tenere in considerazione un progetto se la persona a capo va in giro attivamente a parlare male di noi, accusandoci di cose infondate, e mantenendo un approccio ostile verso Thunderbird e Mozilla.

Ci rendiamo conto di tutte le mancanze di funzionalità e supporto che Thunderbird ha, e stiamo lavorando attivamente per poterle risolvere. Putroppo per fare cose bene e renderle sostenibili ci vuole molto tempo, ed il codice sorgente è molto complicato e delicato.
Attualmente siamo solo 14 programmatori, divisi fra back-end e front-end, e dobbiamo decidere su cosa concentrarci come priorità, e nel corso dei passati vent'anni ci sono stati bugs che per un motivo o per l'altro sono stati dimenticati, e ci sentiamo responsabili.

Stiamo cercando di migliorare.
Grazie a tutti per il support.

[pegasoc]

Salve a tutti, passo qui per dare un po di informazioni a grande linee.
...

Grazie per le delucidazioni.