Comprovado?!: Acho que o Dunc-Tank demostrou que "contribuições financeiras externas" para partes específicas de projetos livres são ineficientes.

E eu ainda não entendi qual é o problema com o fato das releases do Debian saírem "tardiamente" ao que é pré-visto.

Em caso de uso em servidores, quanto menos releases, melhor (ou quase isso).

Em caso de desktops, não se usa o stable, né? Eu, a princípio, uso o Sid, que é mais estável que o Ubuntu e o Kurumin (!).

O importante, na minha opinião, é que sejam lançadas releases dentro das conformidades do Debian, de estabilidade, segurança e qualidade.

Negando o que não se afirmou?: Oi Rafael! Eu perdi alguma coisa, ou você que leu além do que foi escrito? Acho que não há nada indicando que o projeto foi "comprovado", nem na notícia do BR-Linux nem no artigo/entrevista original. Para mim parece bem claro que ele não atingiu suas principais metas, embora tenha gerado alguns efeitos colaterais dignos de estudo.

Mas eu acho que a tua conclusão sobre o que se comprovou foi um pouco ampla. O que o projeto Dunc-Tank demonstrou foi que esta forma de remuneração experimentada, com coleta de doações direcionadas para desenvolvedores específicos dentro de projetos mantidos essencialmente por voluntários, e que trabalham no topo da cadeia de valor formada por uma série de empacotadores e desenvolvedores que não receberam uma parte desta doação, não funciona como incentivo para que os prazos do projeto como um todo sejam alcançados. Mas há outros projetos livres em que há modelos de remuneração de contribuições financeiras externas para partes específicas que funcionam bem, e provavelmente funcionam melhor ainda quando aumenta a especificidade.

Não sei se há um problema com os lançamentos do Debian ocorrerem com atraso em relação à data definida pelo próprio Debian. Para mim certamente não há nenhum. Mas o Debian Project Leader certamente se esforçou para que o prazo fosse alcançado, e o projeto Dunc Tank nasceu com esta meta específica (e com participação do DPL). Aparentemente eles valorizam esta questão cronológica e da expectativa dos usuários com relação às previsões definidas e divulgadas pelo projeto.

Concordo que excesso de lançamentos em distribuições para servidores pode atrapalhar, mas quanto a se usar o unstable em desktops, eu não sei dizer se isto continuaria sendo verdade se o ciclo de lançamentos de outras versões fosse mais curto ou melhor definido. Não tenho visto os usuários de outras distribuições com ciclos mais curtos considerando natural e comum preferir usar as suas versões equivalentes ao que no Debian é o unstable (cooker, os diversos pre-releases do ubuntu e fedora, etc.) Não vejo isso como uma desvantagem do Debian, mas como argumento me parece estar tendendo para o circular.

E concordo que é importante que sejam lançadas releases dentro das conformidades do Debian, de estabilidade, segurança e qualidade. Mas o que percebo é que o projeto Debian elegeu um DPL cujo foco e proposta era justamente lançar o Etch dentro do cronograma definido, então me parece que o próprio projeto acredita na importância desta proposta também.

Edgy?!: Edgy? O nome não seria Etch?

Edgy é do Ubuntu.. :)

É, tá errado mesmo: O correto é "ETCH", não "EDGY". O pior é que o Augusto comeu mosca duas vezes.


long live rock!

Baaaaaaaaahhhhhhhh viajou: Baaaaaaaaahhhhhhhh viajou bonito nessa!

Mas qual é o problema de: Mas qual é o problema de atrasar uma release? A principal concorrente e atual diabo na Terra também atrasa seus releases....
E aproveitando... Dizer que quanto menos releases melhor para os servidores é uma falácia!
Quanto mais atualização de pacotes com correções e features melhor. Esse negócio de não precisar atualizar é coisa de admin preguiçoso. Prefiro sim um sistema estável e meu cliente feliz (e principalmente quieto).

Agora ocorreu-me... Se o release do Debian sair durante o FISL, essa galera podia fazer uma festa a fantasia, não. Aproveitar, que mascarados não vão faltar.

Qual a nova data para o lançamento?: Quando vai sair a versão 4.0 tem uma nova previsão?
Procuro no site do debian.org e nas noticias não se fala mais nada da versão ETCH.

Viajei ;-): É, viajei, acho que comi muita maionese ontem. Corrigido, obrigado!

Realmente, qual a data? SDS: Realmente, qual a data? SDS (Só Deus Sabe)?

Demorem o quanto quiserem...: ...desde que ele venha estável, robusto e bonito :)

Analisando ao pé-da-letra: Olá Augusto!

Fiz uma relação entre o título desse aritgo, "30 dias depois da data prevista para o Etch...", com o que foi publicado anteriormente, explicando o objetivo do Dunk-Tank.

Sinceramente, só tenho conhecimento do que foi publicado na mídia referente ao Dunc-Tank mas, pelo que entendi, trata-se de um projeto para testar o quão eficiente é o patrocínio de áreas específicas para um objetivo maior, nesse caso, o lançamento do Etch (e não Edgy ;)) dentro do prazo previsto.

Porém, o lançamento já extremou-se ao previamente estipulado e, dessa forma, nesse caso em específico, aparenta-se que o projeto Dunc-Tank não obteve êxito.

Quanto ao fato do Debian eleger o Anthony, que tem seu pricipal foco no gerenciamento dos lançamentos, como DPL, acredito que seja mais pressão da "opinião pública" e não tanto dos desenvolvedores.

Talvez tenhamos outros exemplos de sucesso com certos investimentos. Mas, no caso do Debian, o sistema é um pouco mais complexo.

Não mesmo: Então amigo, você não deve ser administrador de sistemas em produção, não mesmo.

No problems: E aproveitando... Dizer que quanto menos releases melhor para os servidores é uma falácia!
Por isso que eu coloquei entre-parênteses, "ou quase isso". Em determinados tipos de servidores, que precisam trabalhar sem interrupções, atualizar uma release é algo bastante problemático, pois sempre há alguns detalhes que precisam de um pós-ajuste.

Quanto mais atualização de pacotes com correções e features melhor. Esse negócio de não precisar atualizar é coisa de admin preguiçoso. Prefiro sim um sistema estável e meu cliente feliz (e principalmente quieto).
Com certeza. Mas para ter correções nos pacotes não há a necessidade de uma nova release. Novas features, quando necessárias, obtem-se instalando a partir do source de determinado programa, mesma forma para os casos especiais, que precisam de atualizações mais constantes.

Levando em consideração que isso é muito mais trabalhoso, acredito que não seja "admin preguiçoso", muito pelo contrário.

Cronograma para quê?: Se o cronograma não pode ser cumprido, então não há necessidade de que ele exista.

Um cronograma não cumprido gera frustrações na espectativa dos usuários, e no mundo corporativo se um cronograma não é cumprido os responsáveis por ele podem até serem demitidos.

Os cronogramas são interessantes para que os usuários e administradores possam se organizar na instalação de um servidor ou mesmo desktops, porém se os cronogramas não são cumpridos, então é melhor não tê-los.

O Debian Etch conta hoje com mais de 115 bugs críticos e esse número deve ser reduzido a ZERO para que o Etch esteja na condição de ser considerado a versão "stable".

Para que isso ocorra, eu creio que deverá haver mais uns 2 ou 3 meses de trabalho árduo.

E detalhe: O lançamento era para ter ocorrido em 04/12/2006, portanto o lançamento está atrasado em quase 2 meses!

Um abraço,
Renato

Pode se considerar como uma: Pode se considerar como uma meta, agora um projeto só pode estar pronto quando ele atenda certos requisitos para o que ele se proponhe.
Não adianta lançar na data, e ele simplesmente vim cheio de bugs, acho minha opinião, nesse caso, seguir uma data assim rigida uma besteira, se estabelece uma meta, um pouca de atraso normal.