1 |
On Wed, Jan 07, 2015 at 12:45:07PM -0500, Rich Freeman wrote: |
2 |
> On Wed, Jan 7, 2015 at 11:30 AM, William Hubbs <williamh@g.o> wrote: |
3 |
> > That's the whole point of a last rites, to get people to step up and |
4 |
> > take responsibility for packages. Also, this was cleared with the qa |
5 |
> > lead before it was ever sent out. |
6 |
> |
7 |
> Define "take responsibility for packages." As far as I'm aware there |
8 |
> is no policy that requires maintainers to fix any upstream bug, and |
9 |
> security issues are almost always upstream bugs. |
10 |
|
11 |
You're right, there isn't a requirement for us to fix upstream bugs, and |
12 |
there shouldn't be. |
13 |
|
14 |
> |
15 |
> A package with a security bug for 10 years could be perfectly |
16 |
> well-maintained, with regular updates/etc as often as upstream |
17 |
> publishes them. Some software projects are fairly mature and don't |
18 |
> get a lot of upstream updates, so a package might be untouched for 5 |
19 |
> years and have security issues and still be "well-maintained." |
20 |
> |
21 |
> I think the solution to this is to have the community agree on just |
22 |
> what "well-maintained" actually means and documenting this as policy, |
23 |
> versus just making individual judgment calls. To be sure there will |
24 |
> still be grey areas, but I think that right now the policies are too |
25 |
> vague to try to enforce something like this. |
26 |
|
27 |
Based on our conversation on irc, what about this -- this is really |
28 |
about information in package.mask. |
29 |
|
30 |
If we want to keep proprietary packages with security issues in the |
31 |
tree, they should be marked as proprietary in package.mask so it is |
32 |
obvious that they will never be fixed. |
33 |
|
34 |
If there is an upstream security issue with a non-proprietary |
35 |
package: |
36 |
|
37 |
When a version or revision with the fix is available, it should be |
38 |
fast stabled. Once that is done, all older versions should be removed |
39 |
if possible. if this is not possible right away, the older versions |
40 |
should go in p.mask with a removal date. |
41 |
|
42 |
Thoughts? |
43 |
|
44 |
William |