Translation

(itstool) path: listitem/para
<emphasis>Cross-building releases</emphasis> - Building IA-64 or Alpha release on x86 hardware? <command>make TARGET=ia64 release</command>.
156/1400
Context English Portuguese (Brazil) State
For more information about the distribution mirror architecture of the FreeBSD FTP sites, please see the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/hubs/">Mirroring FreeBSD</link> article. Para mais informações sobre a arquitetura do sistema de espelhamento dos sites de FTP para distribuição do FreeBSD, por favor veja o artigo <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/hubs/">Espelhando o FreeBSD</link>.
It may take many hours to two days after updating <systemitem>ftp-master</systemitem> before a majority of the Tier-1 FTP sites have the new software depending on whether or not a package set got loaded at the same time. It is imperative that the release engineers coordinate with the <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">FreeBSD mirror site administrators</link> before announcing the general availability of new software on the FTP sites. Ideally the release package set should be loaded at least four days prior to release day. The release bits should be loaded between 24 and 48 hours before the planned release time with <quote>other</quote> file permissions turned off. This will allow the mirror sites to download it but the general public will not be able to download it from the mirror sites. Mail should be sent to <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">FreeBSD mirror site administrators</link> at the time the release bits get posted saying the release has been staged and giving the time that the mirror sites should begin allowing access. Be sure to include a time zone with the time, for example make it relative to GMT. Pode levar de muitas horas a dois dias após a atualização do <systemitem>ftp-master</systemitem> antes que a maioria dos sites de FTP da camada 1 tenham o novo software, dependendo se um conjunto de pacotes foi ou não carregado ao mesmo tempo. É imperativo que os engenheiros de release coordenem com os <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">administradores dos sites espelho do FreeBSD</link> antes de anunciar a disponibilidade geral de novo software nos sites FTP. Idealmente, o pacote da release deve ser carregado pelo menos quatro dias antes do dia de lançamento. Os bits da release devem ser carregados entre 24 e 48 horas antes do horário de lançamento planejado com as permissões de arquivo <quote>other</quote> desativadas. Isso permitirá que os sites espelho façam o download, mas o público em geral não poderá baixá-los dos sites espelho. Um e-mail deve ser enviado para a lista dos <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">administradores do site espelho do FreeBSD</link> no momento em que os bits da release forem publicados, informando que a release foi preparada e informando o horário em que os sites espelho devem começar a permitir o acesso. Certifique-se de incluir um fuso horário com a hora, por exemplo, torná-lo relativo ao GMT.
CD-ROM Replication Replicação do CD-ROM
Coming soon: Tips for sending FreeBSD ISOs to a replicator and quality assurance measures to be taken. Em breve: Dicas para enviar ISOs do FreeBSD para um replicador e medidas de garantia de qualidade a serem tomadas.
Extensibility Extensibilidade
Although FreeBSD forms a complete operating system, there is nothing that forces you to use the system exactly as we have packaged it up for distribution. We have tried to design the system to be as extensible as possible so that it can serve as a platform that other commercial products can be built on top of. The only <quote>rule</quote> we have about this is that if you are going to distribute FreeBSD with non-trivial changes, we encourage you to document your enhancements! The FreeBSD community can only help support users of the software we provide. We certainly encourage innovation in the form of advanced installation and administration tools, for example, but we cannot be expected to answer questions about it. Embora o FreeBSD forme um sistema operacional completo, não há nada que force você a usar o sistema exatamente como o empacotamos para distribuição. Tentamos projetar o sistema para ser o mais extensível possível, de modo que ele possa servir como uma plataforma na qual outros produtos comerciais possam ser construídos. A única <quote>regra</quote> que temos sobre isso é que se você for distribuir o FreeBSD com mudanças não triviais, nós encorajamos você a documentar suas melhorias! A comunidade do FreeBSD só pode ajudar a suportar usuários do software que fornecemos. Nós certamente encorajamos a inovação na forma de ferramentas avançadas de instalação e administração, por exemplo, mas você não esperar que respondamos perguntas sobre isso.
Scripting <command>bsdinstall</command> Usando o script <command>bsdinstall</command>
<uri xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html">@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html</uri> <uri xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html">@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html</uri>
The FreeBSD system installation and configuration tool, <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry>, can be scripted to provide automated installs for large sites. This functionality can be used in conjunction with <trademark class="registered">Intel</trademark> PXE <_:footnote-1/> to bootstrap systems from the network. A ferramenta de instalação e configuração do sistema FreeBSD, <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry>, pode ser programada para fornecer instalações automatizadas para sites grandes. Essa funcionalidade pode ser usada em conjunto com <trademark class="registered">Intel</trademark> PXE <_:footnote-1/> para inicializar sistemas da rede.
Lessons Learned from FreeBSD 4.4 Lições Aprendidas do FreeBSD 4.4
The release engineering process for 4.4 formally began on August 1st, 2001. After that date all commits to the <literal>RELENG_4</literal> branch of FreeBSD had to be explicitly approved by the Release Engineering Team <email>re@FreeBSD.org</email>. The first release candidate for the x86 architecture was released on August 16, followed by 4 more release candidates leading up to the final release on September 18th. The security officer was very involved in the last week of the process as several security issues were found in the earlier release candidates. A total of over <emphasis>500</emphasis> emails were sent to the Release Engineering Team <email>re@FreeBSD.org</email> in little over a month. O processo de engenharia de release do 4.4 começou formalmente em 1º de agosto de 2001. Após essa data, todos os commits da branch <literal>RELENG_4</literal> do FreeBSD tiveram que ser explicitamente aprovados pela Equipe de Engenharia de Release <email>re@FreeBSD.org</email>. O primeiro release candidate para a arquitetura x86 foi lançado em 16 de agosto, seguido por mais 4 candidatos a versão que antecederam a versão final em 18 de setembro. O agente de segurança esteve muito envolvido na última semana do processo, pois vários problemas de segurança foram encontrados nos candidatos anteriores. Um total de mais de <emphasis>500</emphasis> e-mails foram enviados para a Equipe de Engenharia de Release <email>re@FreeBSD.org</email> em pouco mais de um mês.
Our user community has made it very clear that the security and stability of a FreeBSD release should not be sacrificed for any self-imposed deadlines or target release dates. The FreeBSD Project has grown tremendously over its lifetime and the need for standardized release engineering procedures has never been more apparent. This will become even more important as FreeBSD is ported to new platforms. Nossa comunidade de usuários deixou bem claro que a segurança e a estabilidade de uma versão do FreeBSD não devem ser sacrificadas por quaisquer prazos auto-impostos ou datas-alvo de lançamento. O projeto FreeBSD cresceu tremendamente ao longo de sua existência e a necessidade de procedimentos padronizados de engenharia de versões nunca foi tão aparente. Isso se tornará ainda mais importante à medida que o FreeBSD for portado para novas plataformas.
Future Directions Direções futuras
It is imperative for our release engineering activities to scale with our growing userbase. Along these lines we are working very hard to document the procedures involved in producing FreeBSD releases. É imperativo que nossas atividades de engenharia de release sejam escaladas com nossa crescente base de usuários. Nessa linha, estamos trabalhando muito para documentar os procedimentos envolvidos na produção de versões do FreeBSD.
<emphasis>Parallelism</emphasis> - Certain portions of the release build are actually <quote>embarrassingly parallel</quote>. Most of the tasks are very I/O intensive, so having multiple high-speed disk drives is actually more important than using multiple processors in speeding up the <command>make release</command> process. If multiple disks are used for different hierarchies in the <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry> environment, then the CVS checkout of the <filename>ports</filename> and <filename>doc</filename> trees can be happening simultaneously as the <command>make world</command> on another disk. Using a <acronym>RAID</acronym> solution (hardware or software) can significantly decrease the overall build time. <emphasis>Paralelismo</emphasis> - Algumas partes da compilação da release são, na verdade, <quote>embaraçosamente paralelas</quote>. A maioria das tarefas é muito intensiva em I/O, portanto, ter várias unidades de disco de alta velocidade é realmente mais importante do que usar vários processadores para acelerar o processo do <command>make release</command>. Se vários discos forem usados para hierarquias diferentes no ambiente <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, o CVS checkout das árvores do <filename>ports</filename> e do <filename>doc</filename> podem estar acontecendo simultaneamente como o <command>make world</command> em outro disco. Usar uma solução <acronym>RAID</acronym> (hardware ou software) pode diminuir significativamente o tempo de compilação geral.
<emphasis>Cross-building releases</emphasis> - Building IA-64 or Alpha release on x86 hardware? <command>make TARGET=ia64 release</command>. <emphasis>Releases cross-building</emphasis> - Criação do release IA-64 ou Alpha em hardware x86? Use o comando <command>make TARGET=ia64 release</command>.
<emphasis>Regression Testing</emphasis> - We need better automated correctness testing for FreeBSD. <emphasis>Teste de regressão</emphasis> - Precisamos de melhores testes automatizados para o FreeBSD.
<emphasis>Installation Tools</emphasis> - Our installation program has long since outlived its intended life span. Several projects are under development to provide a more advanced installation mechanism. The libh project was one such project that aimed to provide an intelligent new package framework and GUI installation program. <emphasis>Ferramentas de instalação</emphasis> - Nosso programa de instalação há muito tempo ultrapassou à sua expectativa de vida útil. Vários projetos estão em desenvolvimento para fornecer um mecanismo de instalação mais avançado. O projeto libh era um desses projetos que visava fornecer um novo e inteligente framework de pacotes e um programa de instalação GUI.
Acknowledgements Agradecimentos
Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: <link xlink:href="http://docs.FreeBSD.org/44doc/papers/releng.html"> <emphasis>The Release Engineering of 4.3BSD</emphasis></link> Marshall Kirk McKusick, Michael J. Karels e Keith Bostic: <link xlink:href="http://docs.FreeBSD.org/44doc/papers/releng.html"> <emphasis>A Engenharia de Release do 4.3BSD</emphasis></link>
NetBSD Developer Documentation: Release Engineering <uri xlink:href="http://www.NetBSD.org/developers/releng/index.html">http://www.NetBSD.org/developers/releng/index.html</uri> Documentação do desenvolvedor do NetBSD: Engenharia de Release <uri xlink:href="http://www.NetBSD.org/developers/releng/index.html">http://www.NetBSD.org/developers/releng/index.html</uri>
John Baldwin's FreeBSD Release Engineering Proposal <uri xlink:href="https://people.FreeBSD.org/~jhb/docs/releng.txt">https://people.FreeBSD.org/~jhb/docs/releng.txt</uri> Proposta de engenharia de Release do FreeBSD de John Baldwin <uri xlink:href="https://people.FreeBSD.org/~jhb/docs/releng.txt">https://people.FreeBSD.org/~jhb/docs/releng.txt</uri>
I would like to thank Jordan Hubbard for giving me the opportunity to take on some of the release engineering responsibilities for FreeBSD 4.4 and also for all of his work throughout the years making FreeBSD what it is today. Of course the release would not have been possible without all of the release-related work done by Satoshi Asami <email>asami@FreeBSD.org</email>, Steve Price <email>steve@FreeBSD.org</email>, Bruce A. Mah <email>bmah@FreeBSD.org</email>, Nik Clayton <email>nik@FreeBSD.org</email>, David O'Brien <email>obrien@FreeBSD.org</email>, Kris Kennaway <email>kris@FreeBSD.org</email>, John Baldwin <email>jhb@FreeBSD.org</email> and the rest of the FreeBSD development community. I would also like to thank Rodney W. Grimes <email>rgrimes@FreeBSD.org</email>, Poul-Henning Kamp <email>phk@FreeBSD.org</email>, and others who worked on the release engineering tools in the very early days of FreeBSD. This article was influenced by release engineering documents from the CSRG <_:footnote-1/> , the NetBSD Project, <_:footnote-2/> , and John Baldwin's proposed release engineering process notes. <_:footnote-3/> Eu gostaria de agradecer a Jordan Hubbard por me dar a oportunidade de assumir algumas das responsabilidades de engenharia de release do FreeBSD 4.4 e também por todo o seu trabalho ao longo dos anos fazendo do FreeBSD o que é hoje. É claro quea Release não teria sido possível sem todo o trabalho relacionado a release feito por Satoshi Asami <email>asami@FreeBSD.org</email>, Steve Price <email>steve@FreeBSD.org</email>, Bruce A. Mah <email>bmah@FreeBSD.org</email>, Nik Clayton <email>nik@FreeBSD.org</email>, David O'Brien <email>obrien@FreeBSD.org</email>, Kris Kennaway <email>kris@FreeBSD.org</email>, John Baldwin <email>jhb@FreeBSD.org</email> e o resto da comunidade de desenvolvimento do FreeBSD. Eu também gostaria de agradecer a Rodney W. Grimes <email>rgrimes@FreeBSD.org</email>, Poul-Henning Kamp <email>phk@FreeBSD.org</email>, e outros que trabalharam nas ferramentas de engenharia de release nos primeiros dias do FreeBSD. Este artigo foi influenciado por documentos de engenharia de release do CSRG <_:footnote-1/>, o Projeto NetBSD, <_:footnote-2/>, e as notas de processo de engenharia de release propostas por John Baldwin. <_:footnote-3/>

Loading…

No matching activity found.

Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Source string location
article.translate.xml:992
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/releng.po, string 175