| Summary: | devmanual: Update stabilization policy | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | William Hubbs <williamh> |
| Component: | Devmanual | Assignee: | Gentoo Devmanual Team <devmanual> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | pacho, qa, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | stable.patch | ||
|
Description
William Hubbs
2014-02-01 19:53:19 UTC
Created attachment 369288 [details, diff]
stable.patch
This patch seems backwards from general sanity. "If an older version of a package has been stabilized on an architecture and +a newer stable request has had the architecture team added to it for 90 days, +and there are no blockers and no action has been taken by the architecture team, +you may, at your discretion, destabilize the older version of the package +on this architecture" This means that the arch that hasn't stabled the latest version will lose it's keywords at 90 days? This makes no sense, why is QA authorizing breaking the tree? Perhaps it makes sense to remove the keywords for all arches with a newer stable, this would reduce maintenance burden, however, breaking the last stable version on a "slow arch" is kind of the opposite of Quality Assurance. I can't NACK this hard enough. Please don't break the tree. (In reply to Rick Farina (Zero_Chaos) from comment #2) > This means that the arch that hasn't stabled the latest version will lose > it's keywords at 90 days? If the maintainer agrees to do so; at least in what we voted on, this wording appears to have gone in this patch. > This makes no sense, why is QA authorizing breaking the tree? It contains a clause near the end to prevent that breakage; if you intend other breakage, please highlight; if it's the breakage on the ML, let's avoid discussing that in this bug and discuss it on the ML or on chat instead. > Perhaps it makes sense to remove the keywords for all > arches with a newer stable, this would reduce maintenance burden, +1 We already do this for a long time; if not, I misinterpret this. > however, breaking the last stable version on a "slow arch" is kind of the opposite of Quality Assurance. Same as above, it depends on the definition of breakage. > I can't NACK this hard enough. Please don't break the tree. I agree that what you have brought up is concerning; I would NACK to if certain wording does break the tree, and would ACK clarifications to it. I'm however convinced we should keep this practice, and I think most other QA members do as well due to the majority vote. TL;DR: Thank you for bringing it up and pushing forward to clarify it and make possible breakage more clear; I hope you make the next meeting, Some of us (maybe including myself) just don't manage to get our actual thoughts across and understood; but, I think we know what we are doing. Due to concerns raised about interpretation/wording of the policy, NACK pending us reviewing the policy wording at the next meeting. it's been a while. Re-open if still relevant |
