Consensus on high-level objective of cleanup, refactor or rework patches.

["Carlos O'Donell" <carlos at redhat dot com>]

Community,

Several senior glibc developers are doing  an amazing to cleanup glibc
sources. There is a lot of much-needed refactoring, cleanup, and
rework that needs to be done to remove alloca, duplicated headers,
redundancy between ports etc.

I would like to see this work proceed *more* quickly during early
development of a new branch to allow machine maintainers to check if
it breaks things.

To that end I propose we approve via consensus the concept of a set of
changes and allow the maintainer to commit across the entire code base
to implement the concept without having to go through a second round
of review. The initial review of the concept is approval enough.

(1) Post a patch detailing what you want to change and refactor and why.
- MUST include [CONCEPT] or something so anyone can filter it and
respond immediately for review.
- MUST include a breakdown of the stages the work would happen.
- MUST include information about performance implications.
- MUST describe standards compliance implications.
- MUST include details for changes to machine implementations.

(2) Give some time for consensus to appear around the concept.

(3) Start implementing the changes following the stages of the work
you outlined.
- Do not wait for review.
- Commit the cleanup patches in logical sequence that yields a tree
that always builds and is always clean for testing unless you outlined
exceptions in (1).

I would love to see more great cleanups being done early and
efficiently followed by more time for machines to cleanup if we have
fallout.

Thoughts?

Cheers,
Carlos.