| /linux/Documentation/translations/pt_BR/process/ |
| H A D | maintainer-devicetree.rst | 11 escrever bindings de Devicetree corretamente e como enviar patches.
13 Revisão e tratamento de patches
16 Os patches sob responsabilidade dos mantenedores de Devicetree são processados
20 os patches são revisados e aplicados pelos mantenedores de DT.
23 os patches são revisados pelos mantenedores de DT, mas devem ser aplicados
26 Documentation/devicetree/bindings/submitting-patches.rst.
36 Os mantenedores de Devicetree revisam patches usando o Patchwork; portanto, o
38 drivers, o Patchwork recebe toda a série de patches, mas normalmente apenas
39 alguns patches são bindings de Devicetree e, assim, revisados pelos
56 Nova revisão e pings de patches
[all …]
|
| H A D | applying-patches.rst | 21 Além de explicar como aplicar e reverter patches, uma breve descrição das
22 diferentes árvores do kernel (e exemplos de como aplicar seus patches
31 patches são criados com o programa ``diff``.
46 Os patches para o kernel Linux são gerados relativamente ao diretório pai que
115 Erros comuns ao aplicar patches
150 kernel, mas apenas patches do kernel.org, e você aplica os patches na ordem
164 frequência, você encontrará patches que precisam ser aplicados com ``-p0`` em
209 modificada. Portanto, se você obtiver esses erros com patches do kernel.org,
220 gerar um patch que represente as diferenças entre dois patches e, em seguida,
224 passo. A flag -z do interdiff permite até mesmo passar patches em formato
[all …]
|
| H A D | 5.Posting.rst | 3 Enviando patches
9 conjunto de convenções e procedimentos que são usados no envio de patches;
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
20 Existe uma tentação constante de evitar o envio de patches antes que eles
21 estejam completamente "prontos". Para patches simples, isso não é um problema.
31 olhar para patches que sabidamente estão "meio cozidos" (half-baked), mas aqueles
36 Antes de criar patches
40 de patches para a comunidade de desenvolvimento. Elas incluem:
48 mais informações sobre séries de patches). Note que isso pode ser
68 Preparação de patches
[all …]
|
| H A D | maintainer-netdev.rst | 14 - **Tamanho da série** – não envie séries grandes (> 15 patches);divida-as em
16 - **Intervalo de envio** – não reenvie seus patches dentro de um período de 24
69 Árvores git e fluxo de patches
118 Revisão de patches da netdev
151 patches definidos como ``Awaiting upstream`` no patchwork
162 patches para este estado automaticamente com base nas
166 Os patches são indexados pelo cabeçalho ``Message-ID`` dos e-mails que os
175 histórico do estado dos patches; portanto, ter várias pessoas atualizando o
192 patches por conta própria. Nenhum e-mail deve ser enviado à lista com o
196 O uso do bot é restrito aos autores dos patches (o cabeçalho ``From:`` no envio
[all …]
|
| H A D | email-clients.rst | 11 de quem recebe, os mantenedores usam ``git am`` para aplicar os patches.
21 Os patches para o kernel Linux são enviados por email, preferencialmente como
28 para patches quanto para outras mensagens. https://useplaintext.email pode ser
32 Clientes de email usados para patches do kernel Linux devem enviar o texto do
36 Não envie patches com ``format=flowed``. Isso pode causar quebras de linha
50 Copiar e colar (ou recortar e colar) geralmente não funciona para patches
55 Não use assinaturas PGP/GPG em emails que contenham patches. Isso quebra muitos
56 scripts que leem e aplicam os patches.
60 aplicá-la com sucesso com o comando 'patch' antes de enviar patches para as
67 patches para o kernel Linux. Estas dicas não pretendem ser resumos completos da
[all …]
|
| H A D | 2.Process.rst | 35 O processo de integração (*merging*) de patches segue um fluxo simples a
41 ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações)
57 Ao longo das próximas seis a dez semanas, apenas patches que corrijam
69 envio de patches diminui com o tempo. Linus lança novos kernels -rc cerca
94 especialmente graves. Por esta razão, patches que causam regressões são
148 Os patches não vão diretamente do teclado do desenvolvedor para o kernel
170 - Revisão inicial. Os patches são postados na lista de
217 Como os patches entram no Kernel
220 Existe exatamente uma pessoa que pode integrar patches no repositório do
221 kernel principal: Linus Torvalds. Mas, por exemplo, dos mais de 9.500 patches
[all …]
|
| H A D | index.rst | 29 Enviando patches: o guia essencial para colocar o seu código no kernel <submitting-patches>
30 Lista de verificação para submissão de patches do kernel Linux <submit-checklist>
44 Como aplicar patches <applying-patches>
89 Como encontrar as pessoas que aceitarão seus patches e manuais úteis para os
|
| H A D | submitting-patches.rst | 5 Enviando patches: o guia essencial para colocar o seu código no kernel
18 Para patches de binding de device tree, leia
19 Documentation/devicetree/bindings/submitting-patches.rst.
22 patches. Se você não está familiarizado com o ``git``, é muito recomendado que
41 próprias árvores e desejam ver os patches preparados em relação a essas árvores.
61 ou árvores específicas de fornecedores/produtos que selecionam apenas patches
89 Quando você enviar ou reenviar um patch ou uma série de patches, inclua a
178 ou mais patches. Se as suas alterações incluírem uma atualização de API e um novo
179 driver que utiliza essa nova API, separe-os em dois patches.
193 Ao dividir a sua mudança em uma série de patches, tome um cuidado especial para
[all …]
|
| H A D | 7.AdvancedTopics.rst | 11 Gerenciamento de patches com o git
23 Gerenciar patches com o git pode facilitar muito a vida do desenvolvedor,
24 especialmente à medida que o volume desses patches cresce. O git também tem suas
39 como o git funciona antes de tentar usá-lo para disponibilizar patches para
49 Usar o git para gerar patches para submissão por e-mail pode ser um bom exercício
66 Branches disponíveis publicamente devem ser criadas com cuidado; mescle patches
74 Uma série de patches pode ser reescrita como se tivesse sido escrita no topo da
78 pode ajudar na criação de conjuntos de patches limpos e com menos problemas.
117 movimento em massa de patches de um repositório para outro torna fácil a
120 veem esse tipo de coisa acontecer; disponibilizar uma árvore git com patches não
[all …]
|
| /linux/Documentation/process/ |
| H A D | applying-patches.rst | 19 In addition to explaining how to apply and revert patches, a brief
21 their specific patches) is also provided.
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
157 in the wrong directory. Less often, you'll find patches that need to be
203 So if you get these errors with kernel.org patches then you should probably
216 generate a patch representing the differences between two patches and then
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
232 downloading and applying of patches (https://www.selenic.com/ketchup/).
241 Where can I download the patches?
[all …]
|
| H A D | 5.Posting.rst | 3 Posting patches
9 of conventions and procedures which are used in the posting of patches;
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
20 There is a constant temptation to avoid posting patches before they are
21 completely "ready." For simple patches, that is not a problem. If the
30 patches which are known to be half-baked, but those who do will come in
34 Before creating patches
38 sending patches to the development community. These include:
68 The preparation of patches for posting can be a surprising amount of work,
86 up patches is a bit of an art; some developers spend a long time figuring
[all …]
|
| H A D | maintainer-netdev.rst | 14 - don't post large series (> 15 patches), break them up
15 - don't repost your patches within one 24h period
88 RFC patches sent for review only are obviously welcome at any time
140 patches set to ``Awaiting upstream`` in netdev's patchwork
148 pw-bot can automatically set patches to this state based
161 about the history of the state of patches, therefore having multiple
176 completely. Maintainers will classify and update the state of the patches
180 The use of the bot is restricted to authors of the patches (the ``From:``
192 Generally speaking, the patches get triaged quickly (in less than
206 There are 2 services actively providing LLM-generated review on posted patches:
[all …]
|
| H A D | 2.Process.rst | 31 merging of patches for each release. At the beginning of each development
36 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
52 Over the next six to ten weeks, only patches which fix problems should be
88 serious. For this reason, patches which cause regressions are looked upon
206 How patches get into the Kernel
209 There is exactly one person who can merge patches into the mainline kernel
210 repository: Linus Torvalds. But, for example, of the over 9,500 patches
228 maintainers to track a list of patches, including authorship information
230 patches in their repository are not found in the mainline.
233 the patches they have selected for merging from their repositories. If
[all …]
|
| H A D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
34 Procedure for submitting patches to the -stable tree
39 Security patches should not be handled (solely) by the -stable review
101 patches present in the series itself. For example, if you have the following
124 * Delay pick up of patches::
183 - When the -stable maintainers decide for a review cycle, the patches will be
191 - The ACKed patches will be posted again as part of release candidate (-rc)
194 issues, some patches may be modified or dropped or additional patches may
201 containing all the queued and tested patches.
[all …]
|
| H A D | contribution-maturity-model.rst | 19 take on upstream contributions such as reviewing other people’s patches,
40 * Software Engineers are not allowed to contribute patches to the Linux
47 * Software Engineers are allowed to contribute patches to the Linux
64 * Software Engineers are expected to review patches (including patches
92 time focused on Upstream Work, which is defined as reviewing patches,
|
| H A D | 7.AdvancedTopics.rst | 11 Managing patches with Git
23 Managing patches with Git can make life much easier for the developer,
24 especially as the volume of those patches grows. Git also has its rough
39 understanding of how Git works before trying to use it to make patches
49 Using Git to generate patches for submission by email can be a good
65 Publicly-available branches should be created with care; merge in patches
115 mass movement of patches from one repository to another makes it easy to
118 thing happening; putting up a Git tree with unreviewed or off-topic patches
123 You can send me patches, but for me to pull a Git patch from you, I
130 To avoid this kind of situation, ensure that all patches within a given
[all …]
|
| /linux/scripts/package/ |
| H A D | mkdebian | 109 mkdir -p debian/patches
117 } > debian/patches/config.patch
118 echo config.patch > debian/patches/series
120 "${srctree}/scripts/package/gen-diff-patch" debian/patches/diff.patch
121 if [ -s debian/patches/diff.patch ]; then
126 " debian/patches/diff.patch
128 echo diff.patch >> debian/patches/series
130 rm -f debian/patches/diff.patch
|
| /linux/Documentation/bpf/ |
| H A D | bpf_devel_QA.rst | 6 workflows related to reporting bugs, submitting patches, and queueing
7 patches for stable kernels.
9 For general information about submitting patches, please refer to
10 Documentation/process/submitting-patches.rst. This document only describes
44 Submitting patches
49 A: BPF CI is GitHub based and hosted at https://github.com/kernel-patches/bpf.
53 The following steps lay out how to start a CI run for your patches:
59 or bpf branch, and apply your to-be-tested patches on top of it
62 kernel-patches/bpf's bpf-next_base or bpf_base branch, respectively
65 that capacity is shared with patches submitted upstream being checked and so
[all …]
|
| /linux/Documentation/livepatch/ |
| H A D | cumulative-patches.rst | 5 There might be dependencies between livepatches. If multiple patches need
7 an order in which the patches will be installed. And function implementations
10 This might become a maintenance nightmare. Especially when more patches
30 Once the transition is finished, all older patches are automatically
65 to reverse it and restore the replaced patches atomically.
78 executed. Any callbacks from the replaced patches are ignored.
83 As a result, it might be dangerous to replace newer cumulative patches by
93 enabled patches were called.
|
| /linux/drivers/scsi/aic7xxx/aicasm/ |
| H A D | aicasm.c | 74 STAILQ_HEAD(patch_list, patch) patches;
126 STAILQ_INIT(&patches); in main()
425 for (cur_patch = STAILQ_FIRST(&patches); in output_code()
429 cur_patch == STAILQ_FIRST(&patches) ? "" : ",\n", in output_code()
493 pinfo = &scope->patches[patch]; in emit_patch()
515 STAILQ_INSERT_TAIL(&patches, new_patch, links); in emit_patch()
596 cur_patch = STAILQ_FIRST(&patches); in output_listing()
804 cur_scope->patches[1].skip_patch = in process_scope()
806 cur_scope->patches[1].skip_instr = in process_scope()
816 cur_scope->patches[0].skip_patch = patch0_patch_skip; in process_scope()
[all …]
|
| /linux/Documentation/translations/zh_TW/process/ |
| H A D | 5.Posting.rst | 26 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
158 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
189 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
196 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
204 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
|
| /linux/Documentation/arch/riscv/ |
| H A D | patch-acceptance.rst | 22 RISC-V has a patchwork instance, where the status of patches can be checked:
29 Automation runs against this patchwork instance, building/testing patches as
30 they arrive. The automation applies patches against the current HEAD of the
39 We'll only accept patches for new modules or extensions if the
52 RISC-V extensions, we'll only consider patches for extensions that either:
|
| /linux/Documentation/nvdimm/ |
| H A D | maintainer-entry-profile.rst | 15 In general patches can be submitted against the latest -rc; however, if
19 are cases where patches are more suitable to be merged through a
32 Those tests need to be passed before the patches go upstream, but not
38 Before patches enabling a new _DSM family will be considered, it must
52 and some patches may require multiple development cycles to review.
|
| /linux/tools/lib/python/abi/ |
| H A D | abi_regex.py | 169 patches = what.split("/")
170 patches.reverse()
171 patches.append(self.leave_others)
173 for search_group in patches:
|
| /linux/Documentation/driver-api/acpi/ |
| H A D | linuxized-acpica.rst | 125 Linux patches. The patches generated by this process are referred to as
126 "linuxized ACPICA patches". The release process is carried out on a local
182 Before the linuxized ACPICA patches are sent to the Linux ACPI community
191 Ideally, all of the ACPICA commits should be converted into Linux patches
219 user space simulation utilities, thus the linuxized ACPICA patches may
222 linuxized ACPICA patches during the release process. When the release
236 utilities to obtain Linux patches corresponding to upstream ACPICA commits
260 top of the generated ACPICA release patches::
264 $ generate/linux/make-patches.sh -u [commit ID]
|