Home | History | Annotate | Download | only in docs

Lines Matching full:change

141 #. The developer responsible for a code change is also responsible for making
199 interests change, and unexpected things happen, code ownership is purely opt-in,
231 The minimum quality standards that any change must satisfy before being
245 the change (more invasive changes require more testing). A reasonable subset
249 the future that the change is responsible for. For example:
256 * The change set should not cause performance or correctness regressions for the
263 result from your change.
268 to check the nightly testers for regressions the day after your change. Build
274 reverted. This is necessary when the change blocks other developers from making
275 progress. The developer is welcome to re-commit the change after the problem has
301 please do a test commit (e.g. change a comment or add a blank line). Your first
329 after they are committed, depending on the nature of the change). You are
333 .. _discuss the change/gather consensus:
335 Making a Major Change
353 change to the way LLVM works or want to add a major new extension, it is a good
387 change. Some tips:
390 required before the big change can be made (e.g. API cleanup, etc). These
391 sorts of changes can often be done before the major change is done,
396 consensus on what the end goal of the change is.
398 * Each change in the set can be stand alone (e.g. to fix a bug), or part of a
401 * Each change should be kept as small as possible. This simplifies your work
403 that you will get negative feedback on the change. Small increments also
406 * Often, an independent precursor to a big change is to add a new API and slowly
407 migrate clients to use the new API. Each change to use the new API is often
410 API. This implementation change is logically separate from the API
411 change.
413 If you are interested in making a large change, and this scares you, please make
414 sure to first `discuss the change/gather consensus`_ then ask about the best way
415 to go about making the change.
466 An implication of this is that the LLVM license is unlikely to ever change:
468 them to agree that a license change is acceptable for their contribution. Since
469 there are no plans to change the license, this is not a cause for concern.
474 license for your contributions won't change without your approval in the
527 We have no plans to change the license of LLVM. If you have questions or