Bonsoir à tous. Je me pose une question.
J'ai lu je ne sais plus où, que Fedora avait la même politique que les autres distributions, à savoir que l'on ne met pas à jour un logiciel vers sa prochaine version stable, avant la prochaine version stable de la distribution.
Pourtant, regardez ce qui vient de m'arriver en faisant une simple mise à jour sous Fedora 17 :


Je précise que je n'ai pas les dépôts de test d'activés.
Donc, quelqu'un aurait-il une raison de pourquoi est-ce que l'on change de Kernel, qui selon moi entraîne plus de régressions qu'une pauvre mise à jour de LibreOffice en version 3.6, qui m'est bien plus utile dans l'immédiat, et que je ne peux obtenir sans passer par l'archive officielle.
3.5, 3.6 ce ne sont que des numéro. Si l'ABI ne change pas, c'est bon.
On change de kernel régulièrement.
C'est surprenant que tu ne t'en aperçoives que maintenant.
je pense qu'il voulait dire qu'il s'attendait à rester sur du 3.5.x sur Fedora 17, et du 3.6 sur F18. non?
A son lancement, Fedora 17 embarquait le noyau 3.3, donc cela a déjà bien évolué.
Idéalement, ça ne devrait pas évoluer aussi vite, mais certaines corrections du bugs ne sont présentes que dans les dernières versions et sont trop compliquées à backporter d’après ce que j’ai lu quelque part.
madko wrote:je pense qu'il voulait dire qu'il s'attendait à rester sur du 3.5.x sur Fedora 17, et du 3.6 sur F18. non?
Exact. L'ayant installé il n'y a pas si longtemps, je n'avais pas fait gaffe au saut de version. Et si les API du kernel ne changent pas, alors pourquoi ne pas mettre à jour des logiciels comme LibreOffice ? On le fait bien avec Firefox.
Atem18 wrote:
madko wrote:je pense qu'il voulait dire qu'il s'attendait à rester sur du 3.5.x sur Fedora 17, et du 3.6 sur F18. non?
Exact. L'ayant installé il n'y a pas si longtemps, je n'avais pas fait gaffe au saut de version. Et si les API du kernel ne changent pas, alors pourquoi ne pas mettre à jour des logiciels comme LibreOffice ? On le fait bien avec Firefox.
La version livrée par Fedora est la dernière version officielle stable, les version 3.6 étant des pre-release, qui ne sont destinées qu'à évaluation de la prochaine mouture.
Pour firefox c'est trompeur, la 15 puis la 16 ne veulent plus dire changement majeure maintenant. Tant que la mise à jour ne casse rien, c'est possible dans la version actuelle de Fedora. Pour LibreOffice il faut voir que ça ne casse rien non plus, si l'API ne change pas, pas de raison qu'il n'y ai pas de mise à jour.
madko wrote:Pour LibreOffice il faut voir que ça ne casse rien non plus, si l'API ne change pas, pas de raison qu'il n'y ai pas de mise à jour.
Merci, c'est ce que je voulais entendre. Alors, je sais que Fedora est plutôt destinée aux développeurs ou administrateurs systèmes et réseaux (ce que je suis d'ailleurs, et je suis très content de Fedora à ce niveau-là), mais je me dis qu'il n'y a pas de raisons de ne pas mettre à jour certains "grands logiciels". Bon, pour LibreOffice, je pensais en effet que la 3.6 était une release stable, à tord.
Atem18 wrote:Bon, pour LibreOffice, je pensais en effet que la 3.6 était une release stable, à tord.
Avec la communication qui est organisée autour de la moindre nouveauté qu'apporte une version future pour à peu près tous les logiciels, ceci dans le but de tenir en haleine les geeks entre autres, ce n'est pas étonnant de s'y perdre parfois 😉
CanalGuada wrote:
Atem18 wrote:Bon, pour LibreOffice, je pensais en effet que la 3.6 était une release stable, à tord.
Avec la communication qui est organisée autour de la moindre nouveauté qu'apporte une version future pour à peu près tous les logiciels, ceci dans le but de tenir en haleine les geeks entre autres, ce n'est pas étonnant de s'y perdre parfois 😉
Pas faux. Et puis, ce n'est pas comme si l'on attendait pas une révolution de la part de LibreOffice/OpenOffice, depuis des années.
Je suis assez d'accord sur le fait qu'il serait souhaitable d'intégrer plus rapidement dans Fedora les versions de Libreoffice essentiellement parce que chaque évolution améliore la compatibilité avec MS Office.

Aujourd'hui et pour une utilisation professionnelle au quotidien, cette compatibilité entre Libreoffice et MS Office reste un problème dès lors que l'on doit échanger des fichiers (et ce même si on a fait d'énormes progrès depuis StarOffice....)
madko wrote:Pour firefox c'est trompeur, la 15 puis la 16 ne veulent plus dire changement majeure maintenant. Tant que la mise à jour ne casse rien, c'est possible dans la version actuelle de Fedora. Pour LibreOffice il faut voir que ça ne casse rien non plus, si l'API ne change pas, pas de raison qu'il n'y ai pas de mise à jour.
Non, la politique est que sur une version de fedora stable, les mises à jour doivent être faites pour corriger des bugs, pas pour apporter de nouvelles fonctionnalités. Pour les paquets importants dont on parle, je suppose que cette politique est respectée.
ça c'est la politique sur le papier, ya qu'a voir le nombre de mises à jour qui sont des enhancements https://admin.fedoraproject.org/updates/F17/pending?_csrf_token=684302852e975b3ce8782716ecfbd1823ec3b23a

Concrètement cette politique vise à faire en sorte qu'une version X de Fedora est un ensemble assez cohérent de fonctionnalités. Et le terme fonctionnalité est assez flou pour qu'on puisse avoir des montées de versions importantes sur firefox, éventuellement libreoffice, vu que la fonctionnalité principal de ces logiciels n'est pas remis en question. Même pour le kernel de temps en temps de nouvelles fonctionnalités apparaissent, du moment que l'abi ne change pas et que c'est pas la révolution pour l'utilisateur je vois pas où serait le problème? D'ailleurs cette politique vu qu'elle n'est pas si simple engeindre des fois quelques questions sympathiques, on se souvient de la suggestion il n'y a pas si longtemps de passer fedora en rolling release.
En effet, ce sont les packageurs qui décident de suivre la politique ou pas sachant qu’on ne peut pas tous les surveiller (au passage je me demande pourquoi les packageurs peuvent indiquer que leur mise à jour est une « enhancement » puisqu’on a normalement pas le droit d’en faire), mais les paquets les plus importants devraient la suivre. Le but de cette politique est certes de garder un ensemble cohérent, mais aussi d’éviter d’introduire de nouveaux bugs dans une version stable de fedora. De ce point de vue, la surprise d’Atem18 est pertinente.
Je pense que les packageurs le font car ce n'est pas toujours évident de backporter. De plus c'est dans la politique officielle de mise à jour des paquets, une mise à jour peut être autorisée si, je cite:
The update doesn't change ABI/API and nothing needs to be rebuilt against the new version.
C'est ce qui permet de proposer n'importe quelle mise à jour.

cf: http://fedoraproject.org/wiki/Updates_Policy#All_other_updates pour plus d'info
madko wrote:Je pense que les packageurs le font car ce n'est pas toujours évident de backporter.
Oui, c’est probablement la raison pour laquelle le noyau a été mise à jour.
madko wrote: De plus c'est dans la politique officielle de mise à jour des paquets, une mise à jour peut être autorisée si, je cite:
The update doesn't change ABI/API and nothing needs to be rebuilt against the new version.
C'est ce qui permet de proposer n'importe quelle mise à jour.

cf: http://fedoraproject.org/wiki/Updates_Policy#All_other_updates pour plus d'info
Tu cites le passage qui concerne les exceptions demandées au FESCO, ce qui n’est pas quelque chose que les packageurs font de façon anodine. De plus, il s’agit seulement d’un élément qui permettrait à l’exception d’être acceptée plus facilement, pas un critère suffisant pour être accepté automatiquement.
non le passage cité ne concerne pas que FESCO (class to FESCO and/or request an exception). Je ne dis pas non plus que c'est implicite, que ça autorise tout, il faut en faire la demande ou en discuter, mais ça ouvre les portes. Bon il y a aussi la section d'avant, que j'aurais pu citer, qui demande d'éviter les mises à jour majeure mais dans la même phrase en même temps indique que si ça ne casse pas l'ABI/API. Bref pas si clair que ça mais en gros on peut comprendre qu'une mise à jour majeure = cassage de l'abi/api, et pas juste un bump du numéro de version.
Avoid Major version updates, ABI breakage or API changes if at all possible.
Tout ça pour dire que c'est presque subjectif 🙂
Il n’y a pas que les cassages d’API qui doivent être évitées.
Package maintainers MUST:

Avoid Major version updates, ABI breakage or API changes if at all possible.
Avoid changing the user experience if at all possible.
Avoid updates that are trivial or don't affect any Fedora users.
Et dans la section « Philosophy » (c’est moi qui ai mis le passage en gras) :
As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.
Ce qui signifie clairement que les mises à jour qui ne font qu’apporter de nouvelles fonctionnalités doivent être évitées, même si elles ne cassent pas la compatibilité au niveau du code.