Hi, everyone. After sending the recent proposal for python-r2 eclass suite, I've realized that I have ended up somewhere in the middle of two possible goals. Therefore, I'd like to take a step back and ask what kind of python-r2 suite would be preferable.
I see two basic options: either we go for removing deprecated API while keeping the changes to the bare minimum possible without runtime testing, or we go for changing some more and require runtime testing when porting. Let me expand on both concepts. Approach A: minimal API changes =============================== In this approach, I make only clearly cut API changes. It will be possible to migrate most of the ebuilds via a bunch of seds in a script, and to detect cases needing manual update via some more greps. This will make the migration quick and mostly painless. As an implication of that, I would keep support for all old EAPIs and not make any of the runtime warnings more fatal than they are right now (particularly DISTUTILS_USE_SETUPTOOLS remains a warning). The migration plan would be roughly to: 1. Prepare a script converting ebuilds to new eclasses. 2. Run a test conversion and pass it over to Toralf for random testing. 3. Push the conversion. 4. Deprecate the old eclasses. 5. Convert remaining ebuilds manually (those that script can't convert). 6. Last rite the old eclasses. Approach B: maximum cleanup =========================== This approach involves making all current warnings fatal, and removing support for old EAPIs. While script would still help updating ebuilds, it will be necessary to test every migrated ebuild. The migration plan would be roughly to: 1. Prepare the script. 2. Convert some ebuilds on bumps. 3. Deprecate the old eclasses. 4. Wait forever for ::gentoo to be converted. 5. Last rite the old eclasses. 6. Wait again. 7. Remove the eclasses and hear people complaining that 6.5 years were too short to migrate over. Approach C: hybrid approach =========================== Alternatively, I could combine both approaches: commit python-r2 suite that follows approach A, and python-r3 suite that follows B. For practical reasons, the -r3 eclasses would probably boil down to: _PYTHON_R3_API=1 inherit python...-r2 as they would merely enforce stricter warning rules. The migration plan: 1. Prepare the script. 2. Run a test conversion to -r2, ask Toralf, push it. 3. In parallel, start manually switching to -r3 on bumps. 4. Deprecate -r1 and -r2. 5. Convert remaining ebuilds from -r1 to -r3. 6. Last rite -r1. 7. Wait forever. 8. Last rite -r2. Summary ======= So to summarize, of the three proposed approaches: 1. A & C provide for fast cleanup of old API with mostly-automated conversion. 2. B & C provide for gradual cleanup of warnings and old EAPIs, i.e. stuff requiring runtime testing. 3. A & C makes it possible to get rid of -r1 shortly and reduce maintenance effort. What do you think? -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
