Reprise du message précédent :

Le plus gros progres par rapport a kde 4.2 c'est que ca serait relativement stable d'apres Mikala

Suse était initialement très orienté KDE, et propose encore aujourd'hui une des meilleures intégrations de KDE. Ils font un gros travail sur KDE, ce qui explique leur avance.
 
Pour ce qui est d'être à jour, Gentoo propose via des overlays des ebuilds qui permettent de compiler directement le trunk donc pour être à jour, c'est à jour.  
 
Bon je vais rester avec ma Gentoo et mon kde-4.2.* un petit moment encore. J'installerais bien une autre distrib en // pour tester ces dernières versions de kde...  

Par rapport à la 4.2 actuelle ? ou bien par apport au début de la 4.2 ?

euh...
il faudrait citer l'ensemble de mes propos hein
je n'ai aucunement fait de comparaison avec kde 4.2 (je ne l'ai pas installé), je me contente de rapporter ce qu'a dit un empaqueteur  de mandriva.

En même temps Arch étant prévue pour être légère il n'y a "pas grand chose" dans les dépôts officiels. De plus le dépôt KDEmod est tout à fait fiable.
 
Enfin bref on va pas faire la guerre de qui est le plus à jour.

@Changaco
+1000
 
Je n'ai pas pris personnellement ton post, mais je réponds quand même . J'ai juste posté à titre informatif. Chacun sa distribution principale. Je suis à l'aise avec la mienne, mais loin de moi l'idée de pisser le plus loin. Je souhaite que l'aventure kde se passe du mieux possible pour toutes les distributions (j'ai du en oublier quelques-unes vu le nombre...).
 
Au delà de ça, il est aussi parfois utile d'indiquer sa distribution, même si ça peut être mal perçu (je dirais tant pis...). Ça permet lors d'un soucis de savoir si c'est propre à kde ou bien propre à une distribution. Si je le fais, c'est uniquement dans ce but là.

Surtout que la vous parlez de branches expérimentales...
AMHA c'est absolument pas un atout d'intégrer précipitamment les dernières versions d'un soft dans une distrib, au contraire
Sans lancer de troll je trouve ça plutôt idiot d'intégrer kde4.3 maintenant alors qu'il y a rien de fait.

Qui a parlé d'intégrer des paquets instables dans un dépôt stable ?

Personne pourquoi ?

Bah je comprends pas ton message ...

Parce que ton précédent message est équivoque. C'pas grave...

kde4.3 est déja en Soft freeze.
la beta étant prévu pour le 5 Mai...
Donc ce n'est pas aussi instable que cela a mon avis.
 
cf: http://techbase.kde.org/Schedules/ [...] e_Schedule

Quand je disait :

Je voulais juste ajouter à ton message "loin de moi l'idée de pisser le plus loin" que vanter les mérites d'une disrib car elle utilise une branche plus 'expérimentale' ca serait une erreur
 
Dans la suite de mon message j'ajoute juste que selon moi c'est idiot pour une distribution de se précipiter maintenant dans l'intégration de kde 4.3 (même dans une branche expérimental).
L'avantage d'intégrer un soft dans une branche expérimental c'est de pouvoir le tester et faire remonter les bugs.
La on commence juste le cycle de développement de kde 4.3, donc a part pour dire chouette j'ai testé kde4.3 avant tout le monde, ca sert pas a grand chose .
 
PS : Cela n'engage que moi  

 
Je pense pas que ce soit une une question  de stabilité.
C'est juste que pour le moment le travail est fait sur le développement des features et non pas sur les corrections de bugs http://techbase.kde.org/Schedules/ [...] ture_Plan.
Donc je vois pas l'intèret de l'utiliser (sauf pour le fun )

Là pour le coup, je suis d'accord.
 

Développer une distribution qui sort début octobre (c'est juste un exemple), attendu que kde 4.3 est très bientôt en béta, se doit d'avoir des dépôts unstable (disons les dépôts associés au tronc), c'est logique non ? Je ne vois pas comment développer autrement.
Pour le reste, la curiosité a aussi son mot à dire. Je ne suis pas développeur et je ne suis pas sous kde 4.3 (j'attendrai la 4.2.90 probablement), mais je lis régulièrement les différentes expériences, ça m'aide à me faire une idée plus précise des nouveautés. Je me suis mis sous kde 4.2 bien avant la version finale, et bien au vue des options en plus comparativement à la 4.1, je referais la même chose. Je trouve aussi sympas d'échanger sur les changements quotidien, sur ce qui merdoye, sur ce qui évolue.
Ca n'engage aussi que moi... Je conçois très bien qu'effacer un .kde4 une fois par mois puisse saouler  

 
Je suis d'accord avec toi sur le fait qu'il faut intégrer une version pre-release assez rapidement. Cependant je vois pas trop l'interèt de se précipiter pour ajouter une beta (ici kde 4.3) dans un dépot unstable/experimental, pourquoi pas attendre la RC1 par ex ?

On peut retourner la question: pourquoi attendre ? De plus un dépôt instable avec des RC c'est pas vraiment un dépôt instable ...

Le soft freeze, c'est à peu près la date la moins respecté du planning

Deja que le Hard Freeze, y'en a pas mal qui balance des commits avec des fonctionnalités à peine implémentées et codées en 1 nuit histoire de pouvoir l'intégrer  et le finir après sous forme de "correction de bugs"

Honnetement, il a raison, une distrib ne doit pas intégrer des paquets que les developpeurs considèrent comme non fini... çà n'a juste pas de sens.

EDIT : Sinon oui évidemment que c'est stable. Quasiment tous les devs se servent du trunk comme desktop (et moi aussi) et il n'y a pas de probleme. Une fois que les libs sont là et la base aussi (donc depuis les beta de 4.0), personne ne casse le trunk.

 
Si on attend la RC :
 
- On évite au utilisateurs d'unstable de se retrouver avec une version pas beaucoup plus différente que la 4.2  (la moité des features sont pas implémentées) mais beaucoup plus buggé
- Des que la RC arrive dans unstable, ces même utilisateurs garde un système beaucoup plus stable, et peuvent faire remonter les bugs.
 
Celui qui veux utiliser la beta (Dans quel but ?) n'a qu'a utiliser le svn.

Pour une sortie d'ici deux mois, j'en conviens.
 
Pour une sortie début octobre (dans 6 mois...), ça reste très discutable, et je reste convaincu qu'il y a certainement plus de nuances à avoir question planning. Le planning de la distribution et le planning des développeurs annexes est parfois contradictoire.
Je ne suis pas du métier, mais mon observation personnelle m'indique que toutes les distributions n'intègrent pas aussi bien kde les unes des autres (oui, je sais, facile comme observation !    ) , et que cette tache demande quelques mois quand même pour que ce soit fait proprement. Ça serait rapide et facile à intégrer, on ne parlerait pas de bonne ou moins bonne intégration. Avec 6 mois de développement et kde rc1 qui sort fin juin, il restera grossomodo 4 mois aux développeurs annexes (pas ceux qui bossent sur la distrib) avec au pire kde rc1.
 
D'autre part, si suse a fait ce choix (je me tape de suse ou autre, c'est juste l'exemple qui convient), ils ont dû peser le pour et le contre j'imagine et j'ai tendance à leur faire confiance sur ce plan. J'ajoute qu'à propos de la "précipitation", ils ont pris la décision de ne plus sortir de distributions tous les 6 mois mais tous les ans (ou 10 mois je ne sais plus exactement). C'est pourquoi il n'y aura pas de version de printemps. Bref, les décideurs de suse n'ont pas l'air de se précipiter et ont choisi d'intégrer kde 4.3 dès maintenant. Il doit bien y avoir une raison.
 
Voilà, tout ça pour dire, qu'un planning est un compromis, un pari, et que chaque cas demande réflexion.  

Pour moi il y a une différence entre le trunk, unstable et testing. On ne met en effet pas de versions de développement dans testing, on y met les nouvelles versions ou les RC. Par contre pour moi unstable c'est pour ceux qui veulent utiliser le trunk sans compiler. Chaque dépôt a son utilité et son public, et d'ailleurs si ce n'était pas le cas ils n'existeraient plus ...

Je susi assez d'accord, néanmoins les termes testing ou unstable n'ont pas forcément la même signification suivant les distruibutions. Testing sous Arch et testing sous Debian, ce n'est pas la même chose, ne serait-ce que par la méthode de développement de la distribution (release ou rolling). Du coup, tout est relatif quand même.

D'ailleurs pour la Debian on à toujours la 4.2.2 dans experimental.
Pour rappel chez Debian : stable < testing < unstable < experimental

et à ce propos sur debian, squeeze < sid

Tout a fait, d'autant plus que lenny = stable ; squeeze = testing ; sid = unstable    
 
 

bonjour,
sous dolphin on peut noter les documents, ça à l'aire rigolo mais concrètement ça sert à quoi?
est ce pris en compte lors d'une recherche? lors d'un partage de doc entre plusieurs utilisateurs?
 
sinon très bien ce kde4, j'ai l'impression qu'il prend moins de place que son prédécesseur, par contre sur mon portable qui se fait vieux, ça ramouille un peu...

koffice 2 rc est sorti, quelqu'un a testé ? (en ces périodes d'incertitudes sur le devenir d'ooo, peut être que koffice sera la relève)

Si tu parles tu rachat de Sun pas Oracle concernant l'avenir de OOo, je ne vois pas trop ce que ça va changer. Dans le pire des cas, si Oracle décide de tuer OOo, un fork apparaitra non ?

 
Encore faut-il qu'il soit maintenu efficacement

 
enfin sun a fait l'essentiel du boulot sur ooo, et ibm a basé star office dessus, à mon avis ca ne plait pas trop à oracle

Koffice est encore largement en dessous d'ooo. J'ai dû me taper quelques documents avec kword et, à mon goût, on est plus proche d'une beta1 que d'une RC. En résumé, c'est pas très stable et il traîne encore pas mal de bugs évidents.

 
Je suis bien d'accord avec vous deux, mais Oracle ne pourra pas tuer OOo comme ça. Si ils décident d'en arrêter le développement, un fork apparaitra, se développera (probablement moins vite qu'actuellement) et le projet sera finalement toujours dispo. De plus, il me semble qu'on ne sait toujours pas quelles sont les intentions d'Oracle sur le sujet, et même si je ne porte pas cette boite plus que ça dans mon coeur, pas la peine de leur faire un procès d'intention non plus, non ?

 
Tout à fait    
 
Mais ce que je voulais dire, c'est qu'en cas d'abandon il ne suffit pas qu'un fork apparaisse : tout le monde peut forker en recopiant les sources et en leur donnant un nouveau nom, mais faire évoluer le projet dans une direction qui lui assure un avenir, surtout pour un projet aussi gros, c'est autre chose.

Ah ça c'est sur, et on est bien d'accord pour dire que si le fork devient la seule solution pour OOo de continuer à exister et évoluer, ce sera un coup dur. Néanmoins, OOo ne disparaitra pas comme ça, quel que soit la suite. On peut aussi imaginer une reprise intégrale du projet par IBM ou un autre gros si Oracle décide de fermer cette branche de Sun.

Il y a un autre point à garder en compte, vu l'emploi d'Ooo de par le monde, ça fait quand même une belle image de marque pour Oracle, et je doute qu'Oracle ou n'importe qui d'autre voudrait fermer un projet qui apporte autant de visibilité sur leur entreprise... Enfin ça reste mon avis.

Et il me parait assez judicieux je dois dire

La part de marché d'open office est estimée à 15%. Ça m'étonnerait qu'Oracle l'abandonne.

 
même impression que toi

Star Office c'est aussi Sun, pas IBM

http://www.kde.org/announcements/c [...] o4_2_3.php
Et voila \o/

 
je voulais dire lotus symphony