kit-staff team mailing list archive

[Simone Maggiani <maggsimo@xxxxxxxxx>]

>
>
> 1) Il plasmoide me-menù, come ho detto anche a Simone per chat, per me è da
> lasciare da parte per ora sino a che non finiscono RTCC. Detto tra noi non
> sappiamo cosa farà e cosa non fare all'effettivo, quindi direi che
> rinventare la ruota non sia cosa utile.
>

beh allora direi che su questo punto siamo già in tre d'accordo..
sentiamo anche gp, ma credo che alla fine almeno per ora questà opzione sarà
scartata...



>        -Il plugin per Amarok: Si potrebbe fare però come è stato detto
> bisogna vedere se non lo fa il Kubuntu team (penso che sia negli interessi
> di Canonica aprire a più pubblico possibile lo store musicale), inoltre
> direi che è anche qualcosa di secondario e futile, detto onestamente me ne
> faccio poco di uno store o cose simili se poi per installare un pacchetto
> devo sudare sette camice o mi ritrovo davanti ad altri problemi ben più
> gravi.
>

sicuramente bisogna chiedere a loro prima.


>
> 2) Il fattore "essere in grado" vedo che è suddiviso in tre sotto quesiti
> quindi rispondo ad ognuno:
>      - Allora se il codice non ha magheggi strani SI, ma sino a che non lo
> inizio a leggere non lo posso dire, certo che avere una documentazione
> faciliterebbe parecchi la lettura
>      - Capirlo come dal punto sopra una volta letto ed interpretato è anche
> già capito, ma torno sempre a dire con una documentazione la comprensione
> sarebbe più immediata
>      - Come diceva il famoso saggio tra il dire e il fare c'è di mezzo il
> mare, ma penso che se ci mettiamo e lavoriamo con criterio possiamo fare
> tutto (o quasi ). I requisiti minimi sono: avere pazienza e voglia di
> leggere ma sopratutto voglia di sbattere la testa sul debugger.
> Personalmente ho sviluppato software molto più complesso per progetti
> universitari, quindi penso che una mano la posso dare, ovviamente come sa
> già Simone non sono un esperto di Qt ne di C++, anche perché sino ad oggi ho
> sviluppato 1 progetto e mezzo con questi strumenti, ma penso che solo con la
> pratica si può migliorare
>

beh io un pochino ci ho programmato, ma non posso certo definirmi esperto...
imho, si impara :)


>
> 3) La mia idea era quella di contattare lo sviluppatore immediatamente e
> chiedergli se ha un qualche sorta di documentazione, altrimenti dovremo
> scriverla noi (cosa che si può anche fare) però ovviamente dovremo scocciare
> spesso lo sviluppatore ufficiale per eventuali chiarimenti (il mio problema
> è che a leggere l'inglese non ho problemi ma a scriverlo sono un cane).
>
>
si può fare...


> Quindi io dire che se decidiamo di implementare ciò che manca a kpackagekit
> dobbiamo:
> 1) Sentire il team di Kubuntu cosa vuole fare, e su cosa vuole lavorare.
>

vista applicazioni e debconf, ma al momento sono fermi in entrame le
direzioni...
forse fa qualcosa lo stesso sviluppatore di kpackagekit, forse...


> 2) Avere una documentazione (possibilmente ottenendola dallo sviluppatore
> ufficiale)
>

dubito ci sia, nel suo codice lui sa dove andare, quindi....


> 3) Stilare una lista di migliorie da apportare (metterle hai voti magari
> anche su i forum di ubuntu per vedere cosa dice l'utenza finale delle nostre
> idee).
>

imho per iniziare meglio solo tra di noi, non vorrei creare troppe
aspettative.


> 4) Creare una sorta di lista delle priorità. Ovviamente dovremo vagliare
> bene quali sono le cose meno utili e quali quelle più complesse in modo da
> iniziare magari con qualcosa di utile e meno complesso, in modo anche da
> iniziare a sgranchirci le dite e prendere un po più di confidenza con le Qt,
> le kdelibs e il C++.
>

si certo, d'accordo al 100%


>
> Una domanda ma il Kubuntu Team dovrebbe lavorare su KpackageKit suppongo
> che loro tireranno giù una documentazione per lavorarci sopra, perchè non
> chiediamo a loro come faranno o se hanno già qualcosa per le mani?
>
> si potrebbe anche, ma come detto lex mi ha detto che al momento sono fermi