| 1 |
I wanted to take this thread in a slightly different direction so that |
| 2 |
the council has a little more to work with tomorrow. Obviously there |
| 3 |
are multiple opinions on whether a problem currently exists - and the |
| 4 |
council will need to decide on this. If no problem currently exists |
| 5 |
they will likely take no action. However, if a problem does exist, what |
| 6 |
would be a reasonable solution? |
| 7 |
|
| 8 |
Here's a proposal. Maybe not a great one - feel free to come up with |
| 9 |
others (other than just do nothing - if we are going to do nothing we |
| 10 |
don't need to work out what that will be). I think it gives arch teams |
| 11 |
a fair amount of time to keep up with stable requests, but also allows |
| 12 |
package maintainers to eventually get rid of cruft. The exact |
| 13 |
timeframes are of course the easiest and most obvious things to modify. |
| 14 |
|
| 15 |
My hope is that this will give everybody something to think about so |
| 16 |
that if a decision to enact policy is made tomorrow the policy is a good |
| 17 |
one... |
| 18 |
|
| 19 |
|
| 20 |
Ebuild Stabilization Time |
| 21 |
|
| 22 |
Arch teams will normally have until the LATER of the following two dates |
| 23 |
to stabilize ebuilds for non-security-related issues: |
| 24 |
1. 60 days from the day the last substantial change was made to the |
| 25 |
ebuild (clock resets if a non-trivial change is made to the ebuild). |
| 26 |
That's 30 days to allow the package to be proven stable, and 30 days to |
| 27 |
do something about it. |
| 28 |
2. 30 days from the day a bug was filed and keyworded STABLEREQ and the |
| 29 |
arch was CCed and the maintainer either filed the bug or commented that |
| 30 |
it was OK to stabilize (clock starts when all of these conditions are met). |
| 31 |
|
| 32 |
Perhaps the guideline should be one week on both time periods for |
| 33 |
security bugs. |
| 34 |
|
| 35 |
|
| 36 |
Technical Problems With Ebuild Revisions |
| 37 |
|
| 38 |
If an arch team finds a technical problem with an ebuild preventing |
| 39 |
stabilization a bug will be logged as a blocker for the stable keyword |
| 40 |
request. The bug being resolved counts as a substantial change for the |
| 41 |
purpose of #1 above. |
| 42 |
|
| 43 |
|
| 44 |
Removing Stable Ebuilds. |
| 45 |
|
| 46 |
If an ebuild meets the time criteria above and there are no technical |
| 47 |
issues preventing stabilization, then the maintainer MAY choose to |
| 48 |
delete an older version even if it is the most recent stable version for |
| 49 |
a particular arch. |
| 50 |
|
| 51 |
If an ebuild meets the time criteria and there IS a technical problem |
| 52 |
preventing stabilization, but the package is subject to security issues, |
| 53 |
the maintainer MAY choose to mask the vulnerable versions in package.mask. |
| 54 |
|
| 55 |
If an ebuild does not meet the time criteria or there is a technical |
| 56 |
problem preventing stabilization and there isn't an outstanding security |
| 57 |
issue, then the maintainer must not remove the highest-versioned stable |
| 58 |
ebuild for any given arch. |
| 59 |
|
| 60 |
|
| 61 |
Spirit of Cooperation |
| 62 |
|
| 63 |
Ebuild maintainers and arch teams are encouraged to work together for |
| 64 |
the sake of each other and end users in facilitating the testing and |
| 65 |
maintenance of ebuilds on obscure hardware or where obscure expertise is |
| 66 |
needed. Package maintainers are encouraged to use discretion when |
| 67 |
removing ebuilds in accordance with this policy. |
| 68 |
-- |
| 69 |
gentoo-dev@l.g.o mailing list |
Archives