openSUSE: Ciclo de lançamentos será de 8 meses
“O openSUSE está adotando um ciclo de 8 meses para as suas versões. A justificativa apresentada por Stephan Kulow, gestor de liberações do openSUSE, na mensagem de anúncio da adoção imediata da novidade, é que não é viável manter a qualidade do openSUSE em uma janela menor que 8 meses. Além disso um calendário até 2011 foi informado, mostrando que, apesar das demissões da Novell, a distribuição continua com planos bem definidos.”
Enviado por Marcolino (marcolinoΘwebviva·com·br) – referência (blog.marcolino.com.br).
• Publicado por Augusto Campos em
2009-03-09
@brlinuxblog
Feed RSS
Otimo, melhor assim do que querer freneticamente criar uma nova versão onde muita das vezes a qualidade fica em segundo plano. Na minha opinião até uma por ano estava legal.
Embora até hoje a qualidade do OpenSUSE tem sido inquestionavel, ao menos para mim.
Apesar de não usar o openSUSE, vejo isso como uma decisão sensata. Acho que esse caminho já deveria ter sido trilhado pelo Fedora e principalmente pelo Ubuntu. O ciclo de 6 meses que ambos adotam acabam primando mais pela inovação do que pela qualidade, quando ambos poderiam ser priorizados. Utilizo essas duas distros e acho que ambas, mas principalmente o Ubuntu, têm sido lançadas com bugs irritantes e que poderiam ter sido evitados com um ciclo um pouco maior de lançamento de versões. Tanto isso poderia ser resolvido que em 1 ou 2 meses depois de lançada uma versão nova, a maior parte dos problemas mais comuns é resolvida. Já há uns 2 anos eu não instalo mais uma versão assim que ela sai e na única vez que fiz isso, me arrependi amargamente e voltei atrás. Sempre espero alguns meses até que os principais bugs sejam resolvidos.
Tomara que essa dicussão seja bem longa e levada a sério pelo pessoal da Canonical, Red Hat, Mandriva e _________________ (qualquer outra distribuição com ciclo de lançamento de 6 meses).
Acho que o ciclo ideal de lançamento fica em torno de 8 a 10 meses, viu, galera do Debian? ;-)
Creio que 2 meses de diferença não fazem o Opensuse ter men os bugs que o Ubuntu nas novas versões.
Geralmente os bugs ocorrem em novas funcionalidades, é o preço que se paga pelo ciclo mais rápido de novas versões.
O ponto positivo é o melhor suporte as tecnologias que não param de brotar. quem teve que instalar o Linux com saída HDMI de áudio e vídeo sabe o que estou dizendo. Ou quem sabe para quem sofre com o dispositivo usb wi-fi de qualidade questionável? O suporte está vindo no kernel 2.6.28. O Ubuntu está no .27!
Tudo tem seu lado bom e ruim. Alias, por isso existe o LTS, não precisa ficar atualizando se para você está funcionando!
Que o “efeito Ubuntu” de atualizações continue influenciando os distros!
Até mais,
PoolS, acho que 2 meses já faz uma baita diferença. O Leonardo disse tudo… às vezes alguns bugs simples escapam por descuido… creio que com um ciclo de lançamento um pouco maior, mais pessoas encoragen-se a testarem as versões beta e divulgar a tempo os erros. Seis meses é pouquíssimo tempo pra isso e a galera acaba esperando sair a versão final que acaba por ter qualidade de beta.
Não era o Mark que queria que as distribuições unificassem os períodos de lançamento? Tá aí uma boa oportunidade.
Também gostei da mudança. Com isso a distro deve lançar versões cada vez mais estáveis e polidas.
Seis meses entre lançamentos é pouco no atual estágio de novidades, principalmente porque as maiores distribuições não colaboram entre si, então quando se pensa em colocar algo desenvolvido ou mantido pela Canonical, aparece a RedHat com algo melhor, ou vice-versa, só com muito teste e que se chega a uma definição do melhor.
A novidade exerce um fascínio tremendo, aqui estou com o U-8.10 rodando redondo, mas ontem já instalei o sistema de notificação do 9.04.
Essa demora no ciclo de atualizações é bom para pessoas que nem eu que não gosta dessa coisa louca de ficar atualizando a distribuição a cada 6 meses. Uso o OpenSUSE 11.0 mas antes de atualizar ainda usava a 10.2 porem bem atualizado, kernel atual (mais novo que o padrão do OS 11.0), KDE etc.
Até mesmo para o usuario é ruim essa atualização precoce, quando o camarada está se acostumando com os recursos da distro lá vai ter que instalar tudo de novo, assim fica muito “windows” que tem que ficar formatando a cada 6 meses.
O bom disso tudo é o tempo de duração dos repositorios, quem quiser usar o OpenSUSE 10.1 ainda tem até hoje repositorios atualizados, não obrigando a atualizar a distro por falta de algum aplicativo. Bom pra mim que só pretendo sair do OS 11.0 quando lançarem o 11.2 (ou superior). :D
Mas quem é que tem que atualizar a cada 6 meses? Creio que nenhuma das distribuições populares descontinua o suporte e a manutenção (incluindo os pacotes nos repositórios) de suas versões anteriores imediatamente após lançar uma nova.
Não é só com o openSUSE que você poderia “saltar” versões, como descreveu. O ciclo ser de 6 ou de 8 meses não muda muito a ausência ou presença de necessidade de atualizar imediatamente após cada lançamento.
Augusto, eu concordo plenamente contigo que ninguém é obrigado a atualizar a cada 6 meses, tanto que utilizo o Ubuntu 8.04 e utilizava o Fedora 9 até pouco tempo (já atualizado para o 10, após testar bastante no VirtualBox e sentir segurança na atualização). O que eu não acho bom é lançar versões precocemente, mas que apresentam erros simples e que poderiam ser corrigidos com simples verificações e um período um pouco maior de testes. Quando alguém que nunca viu um Linux na vida resolve instalar o novíssimo Ubuntu 8.10 em 10/2008 ou o novíssimo Fedora 10 em 11/2008, ou seja, ambos recém-lançados, e se depara com erros pequenos e irritantes, a primeira impressão acaba sendo ruim. Um pouco mais de cuidado pode ajudar nessa primeira impressão. Eu entendo essas coisas e sou paciente nas minhas atualizações, mas um usuário em potencial que instala Linux por curiosidade (e normalmente escolhe a versão mais recente) não entende.
Papo-furado! Todo mundo corre para atualizar! Mais tempo = menos bugs? Muito questionável. Mais tempo = Menos empenho! Estou usando o kernel 2.6.28-7 omnislash 5 no Ubuntu em um Acer Aspire One. Fantástico! O som e o bluetooth decolaram. O boot caiu de 41 para 32 segundos no bootchart!!! E, sempre reclamam do Ubuntu, mas tenho Ubuntu, Kubuntu, Fedora, OpenSuse e Easy Peasy instalados e Fedora e OpenSuse não conseguem achar o teclado correto do AA1. Barbaridade! Só os Ubuntu e derivados acertam já na instalação. Falo porque estou testando todos ao mesmo tempo. Não venham com aquele monte de comentários chatos. Instalei todos pq busco o melhor para o AA1.
Eu não corro para atualizar.
É… o Fedora, por exemplo, que parei de utilizar, por causa de alguns problemas com o vídeo, tem este problema com os bugs presentes no lançamento da distro. Outras distribuições que testei também apresentam este mesmo problema,acredito que um tempo maior de “maturação” da distro antes do lançamento seria benéfico.
Ada, mais tempo = menos bugs sim. Debian stable fala por si só. Basta congelar as versões e trabalhar por um intervalo maior apenas em correções de bugs e brechas de segurança e teremos distros bem mais estáveis. Não estou pregando um ciclo longo como o do debian stable para distros inovadoras como Ubuntu, Fedora, Mandriva, openSUSE, etc. Apenas acho que um ciclo entre 8 e 10 meses evitaria muitos problemas comuns e que podem causar má impressão.
Cronografia do Opensuse:
Fonte:
http://www.h-online.com/open/Roadmap-for-OpenSUSE–/news/112791
in:
Roadmap for OpenSUSE
Stephan Kulow, the OpenSUSE project manager, has proposed a roadmap for the future versions of OpenSUSE. While Ubuntu and Fedora distributions currently aspire to provide a new release every six months, which is loosely pinned to the GNOME development schedule, previously OpenSUSE did not have a have a fixed release schedule. OpenSUSE will now try to ship a new version every eight months as part of their new release cycle.
The OpenSUSE 11.2 release (code-named Fichte) due out in November 2009 will be followed by 11.3 in July 2010, version 12 in March of 2011 and 12.1 in November of 2011. Public releases will be available on the Thursday before the 15th of the month. Four weeks earlier, a release candidate will be posted to allow the report and resolution of any major bugs.
According to Kulow, several additions are expected to appear in the November 2009 release of OpenSUSE 11.2. The 2.6.30 or later kernel, KDE 4.3, GNOME 2.28 and Ext4 as the default file system are all on top of the list of features. The YaST Web interface for easier remote administration, improved support for Netbooks, and an over-all “quicker, faster and more colourful” release are also listed.
”
o/
Ciclos rápidos são essenciais para qualquer distribuição que queira ser usada realmente em desktops hoje em dia. Não é tanto por “frescuras gráficas”, mas principalmente por causa de suporte a hardware, ainda mais hoje em dia em que muita gente instala linux em notebooks e quer tudo ou a maior parte funcionando sem configurações manuais extras.
O suporte a hardware do linux é dado basicamente por alguns poucos softwares como o kernel linux, alsa, sane, X.org, cups e poucos outros. Quando se tem um hardware recente, muitas vezes ele só funciona com uma versão recente de um destes programas e instalar um deles num sistema antigo não é trivial.
Essas distribuições mais voltadas para desktop que saem de 6 em 6 meses tem pelo menos 1 ano e meio ou 2 anos de suporte garantido pelo menos, o que significa que dá para atualizar somente a cada 3 a 4 versões lançadas e manter-se seguro e atualizado.
Deve-se optar pelo la nçamento de nova versão:
a) Porque corrige o que há como problemático ou inoperante
b) Há mais recursos adicionados ou novos programas
c) Evolução do Kernel
Entretanto,no Opensuse 11.0 ocorreu que o Yast2 não surtiu efeitos para gerenciamento de atualização de programas do sisrtema. Por isto, foi necessário usar o SMART package manager para suprir essa necessidade.
2. Com o OpenSuse 11.2 – além das soluções, e no período, aconteceu o crescimento de colaboradores:
Veja-se, digitando argumento de pesquisa “geany”, em
http://rpm.pbone.net/index.php3
nos subdiretorios”/home”.
3. Outro recurso do período: webpin – como WebService:
“Name : webpin Relocations: (not relocatable)
Version : 1.0.1 Vendor: openSUSE Build Service
Release : 1.1 Build Date: Dom 21 Dez 2008 00:40:27 BRST
Group : System/Packages Source RPM: webpin-1.0.1-1.1.src.rpm
URL : http://dev-loki.blogspot.com/search/label/webpin
Summary : Command-Line Client for the openSUSE Package Search Web Service
Description :
Command-line client for the openSUSE Package Search web service
commonly known as “webpin”: http://benjiweber.co.uk:8080/webpin/
The Package Search service is written and maintained by Benjamin Weber.
Authors:
Pascal Bleser
Distribution: openSUSE:Tools / openSUSE_11.1
”
E o webpin como web-service: Comunidade – referente a 3 versões:
http://packages.opensuse-community.org/
em que digitando “rxvt-unicode” – resulta num relatório de disponibilidades; no lado direito há um icone “install” que permite executar o download e instalação.
No FlashGot há um ícone para usar o Gerenciador YAST2.
Perfeitissimo.
O Ubuntu tentou resolver esse problema com as versões LTS. Essas ficam recebendo mais atualizações e correções de bug. Como o Manoel citou, o ciclo curto atrai os usuários que gostam das maiores novidades e principalmente as atualizações de hardware.
Teríamos de encontrar uma forma das atualizações de hardware não necessitarem de um kernel novo ou nova versão do X.org e alsa. Pra quem acompanha, essa é uma briga boa entre os desenvolvedores do kernel, que estão cientes desse problema.
Carlos Augusto, vc e meia-dúzia não atualizam. Ok. Mas nos dias de lançamento das distros eh o inferno! Então estah provado que todo mundo atualiza ou quer testar! Todo mundo quer ver a sua camera, multifuncional, celular ser plugado e reconhecido de primeira. Todo mundo eh assim. Ninguem fica feliz por ter que procurar soluções na internet. As vezes querem soh uma firulinha, como o novo sistema de notificação do Jaunty. Fiquem com as LTS. Parem de reclamar. Temos que evoluir o mais rápido possível! Se ficar um bug, relatem imediatamente, coisa que eu faco e pouca gente faz. Eu não fico parado.
Meu caro Ada, teste deve ser feito em versão Alfa, Beta ou Release Candidate. Versão “Release” não deve ser usada para testes, ela deve estar pronta para o uso. Outra coisa: evoluir rapidamente é diferente de evoluir com pressa. Não devemos ter pressa e atropelar coisas básicas no desenvolvimento de qualquer software (testes), seja ele livre ou não. Ser produtivo é diferente de fazer as coisas correndo.
Também costumo relatar bugs do Fedora no bugzilla deles.
Leonardo,
Concordo plenamente com o que voce falou. Nao quero fazer de minha opniao a mais sensata ou qualquer coisa do tipo, mas eu trabalhei com QA por mais de 1 ano e meio e atualmente com sistemas Unix em uma empresa de MUITO grande nome e sei como a questao Qualidade/Tempo funciona, principalmente em sistemas open-source.
Como voce mesmo disse, teste deve ser feito em fase de teste, e tambem acho que aumentar o ciclo de lancamentos para 8 meses e uma otima ideia, alias, 8 meses acho o minimo aceitavel.
Essa historia de se parecer com o Windows nao cola, claro, sao universos diferentes, mas se for assim, o Windows XP foi lancado em 2001 e ate hoje suporta mais de 80% de todos os hardwares do mundo.
Eu creio que o ideal mesmo seria um ciclo de 12 meses daria tempo para testar legal. eu po exemplo estava com o fedora 8 no meu note até a semana retrasada. Decidi atualizar para o fedora 10. Pronto, bug do DNS. Não conseguia acessar internet, de nenhuma forma. Nem fazer um update para baixar a “correção” eu poderia. Instalei o Ubuntu 8.10 para testar, superaquecimento do note! Voltei para o fedora 10 e baixei a mais atual do glibc, uns quatro pacotes, no desktop pelo rpm bone para amenizar o bug que ainda persiste. Se isso não for corrigido em breve vou ter que tirar um fim de semana para instalar o Arch no note também. =/
3 páginas:
“Operating systems News
Quick fixes for common Linux problems
Solve issues with start-up, drivers, networking and more”
link:
http://www.techradar.com/news/software/operating-systems/quick-fixes-for-common-linux-problems-561079
O que vcs esquecem é que NÃO existe sistema perfeito. O pessoal do Ubuntu e do Fedora não fica de barriga pra cima e/ou escrevendo bobagens em fóruns. O pessoal vai atrás das inovações e dos bugs. Quem aqui trabalha lá para afirmar que eles fazem correndo? É muita imaginação. Simplesmente tem distribuições que conseguem evoluir a cada seis meses e outras não. É questão de competência. Só isto. O que nós temos que fazer é relatar todos os bugs que encontramos. E raramente acho um, algo que não funciona. Tem gente que não é capaz de se registrar no launchpad, mas fica o dia inteiro escrevendo reclamação no Ubuntu/Fedora fórum. Assim, pela imensa, universal quantidade de hardware, pode aumentar ainda mais o tempo entre lançamento, que só quando alguém, o premiado que tem este bendito hardware, instalar o linux é que se vai saber que esse bug existe. Simples assim.
“Operating systems News
Quick fixes for common Linux problems
Solve issues with start-up, drivers, networking and more”
na verdade isso não resolve o bug que eu relatei:
https://fedoraproject.org/wiki/Bugs/F10Common#DNS_resolver_not_reliable
e ainda que resolvesse o ideal é vc não enfrentar esse tipo de coisa logo na instalação. Acaba dando espaço pra quem detesta software livre dizer que Linux não presta.
Um lado negativo de ter um roadmap fixo é que a distribuição pode perder uma grande mudança para melhor. No caso do Slackware – que eu acompanho por motivo de força maior – ele ainda vem com Gimp desatualizado entre outros aplicativos.
Um outro exemplo deve ser o Firefox, se no dia do lançamento da ISO sair uma versão nova do Firefox, é melhor atualizar na ISO logo, e o mesmo vale para alguns pacotes com problemas de segurança.
Acho um ciclo de doze meses grande, seis meses acho pouco a não ser que a distribuição não esteja tentando incluir grandes inovações, mas de fato acho que um ciclo deve ter uns dois anos com versões espalhadas entre os ciclos. Do um pro dois deve surgir uns 1.2, 1.3… assim o usuário tem mais noção de quando há um grande salto.
O Launchpad é útil não apenas para o Ubuntu, costumo pesquisar em outras distribuições por idéias, soluções, patches, correções, e tem centenas de sites que ajudam a manter a distro mais atualizada e menos suscetível a erros. O maior problema é ver alguns bons programas abandonados em prol de outros patrocinados pelas maiores distribuições. Eu ainda uso o Bootsplash, porque ele é o melhor que temos ainda, por exemplo.
O que deve medir o tempo entre um release e outro é a atividade da comunidade. Não adianta estender de 6 para 8 meses se a comunidade não se mobilizar para testar e reportar os bugs dos betas, alfas, rcs… E isso não vale só para o openSUSE.
Creio que muitos aqui ajudam, alguns testanto, outros traduzindo, só que a comunidade não se resume aos comentários deste blog. Temos que ajudar e não só criticar.
Apesar de tudo, estou muito feliz com meu Arch seu sistema Rolling Release. =)
Considerando que 2 meses são 1/3 de todo o desenvolvimento atual. Faz sim muita diferença.
Aqui por exemplo, openSUSE, Mandriva e Fedora são as unicas três distros que nunca tive problema de reconhecimento de hardware… Já com outras pessoas acontece justamente ao contrario.
Se pegarmos como base o comentário do Athila, sobre o Windows XP, essas diferenças podem ficar ainda mais evidente. Todo mundo que já trabalhou com desenvolvimento de software sabe que o maior vilão é o prazo, depois é claro do planejamento. Aumentar em 1/3 o tempo do desenvolvimento seja lá de qual ferramenta, é aumentar o tempo disponível para planejar e para desenvolver. Isso só tende a trazer benefícios.
Como o próprio Augusto ressaltou, não é só as distribuições mais novas que possuem o suporte as “novidades”, ainda mais quando a distribuições possui um sistema de atualização online disponível ainda na instalação.
E também não vejo como uma questão de competência. Qualquer programador sabe que algumas coisas nem chuck norris conseguiria fazer de um dia para o outro. Alguns programas mesmo com equipes enormes demoram meses para ficar pronto.
Tempo de desenvolvimento sempre foi, e sempre será o calcanhar de Aquiles de qualquer projeto. E se é possível extende-lo… Porque não faze-lo? O usuário não é um rato de laboratório, ele não é obrigado a testar o software… Isso fica para os devs, e se eles podem “sacrificar” mais dois meses para poder testar, que o façam…
@Cesar Lemos
Tenho de discorda também assim como falaram outros aqui o ciclo de 6 meses foi algo que acelerou muito a evolução do sistema, pense bem antes tinhamos ciclos de 10, 12 e 3 anos de lançamento e mesmo assim não lá grande coisa, mas quando veio o Ubuntu com suas atualizações rápidas (a principil era uma bosta de sistema), ele evoluiu de forma estraordinária, tanto que é que o live cd do Ubuntu roda em mais equipamentos (notebooks, desktops, netbooks, entre outros) que o openSuse por exemplo.
Sem contar que nesta mesma época a evolução pareceu que foi da noite para o dia o qual influenciou muitos outros sistemas, por isso concordo com Mark sobre a idéia de ciclos rápidos.
Agora mesmo estou aguardando a versão 9.04 que será ótima, já que virá com recursos estáveis que realmente são necessários hoje em dia (como o pulseaudio, por exemplo).