1 |
On Sunday, 22. July 2007 08:39, Alec Warner wrote: |
2 |
> Author: Who commited the mask. |
3 |
> Date: When was it masked. |
4 |
> Reason: 1 or more lines describing a rationale for the masking. |
5 |
> Packages: one or more lines of text, 1 atom per line, describing |
6 |
> packages affected by this mask entry. |
7 |
> |
8 |
> I wish to add a few more fields: |
9 |
> |
10 |
> Effective-Date: Date the mask goes into effect. This means you can |
11 |
> mask stuff in the future. |
12 |
> Expiration-Date: Date the mask ends. This means you can have masks |
13 |
> that expire after a given time. |
14 |
> |
15 |
> If Expiration-Date was mandatory, we could essentially have a system |
16 |
> that cleans out mask files by removing expired masks. |
17 |
|
18 |
I like the idea, here's my comments: |
19 |
|
20 |
1. For backwards compatibility, we could just put all fields into |
21 |
comments (as it is done now) except for the masked atoms, like this: |
22 |
|
23 |
# Author: Alec Warner <antarus@g.o> |
24 |
# Date: 05 Feb 2007 |
25 |
# Reason: Masked to security problems, use 1.23-r1 until I fix it |
26 |
# ... |
27 |
>=app-admin/ulogd-1.24 |
28 |
|
29 |
The dates usage and parsing could than be added later, while using the |
30 |
format and automation itself today. |
31 |
|
32 |
2. The pro's of using it today would be to mark Last-Rites (just what |
33 |
makes me think that discussion led you to the idea?). |
34 |
I can think of several ways to do this. We could have an |
35 |
optional "Removal-Date" field and if it is set, the package is last |
36 |
rited |
37 |
|
38 |
3. We could also introduce some kind of "Keywords" as in Bugzilla to |
39 |
mark certain situations, as UNUSABLE, SECURITY, LASTRITED. Do we need |
40 |
that? |
41 |
|
42 |
4. How do we handle updates to the an entry, esp. the Date and Author |
43 |
section? |
44 |
|
45 |
|
46 |
> Another thing I wish to address is the addition of entries in |
47 |
> package.mask at the top of the file. I think this restriction just |
48 |
> makes automation more difficult. I can't just append new entries to |
49 |
> the end of the file, I have to read in the file and figure out by |
50 |
> some hardcoded comment strings where the actaul masks begin, and then |
51 |
> insert text right below the examples. This is horrible. Can we nuke |
52 |
> that convention, why are new entries at the top? |
53 |
|
54 |
Drop the convention then... or we could add a marker line at the top |
55 |
"## New entries start here" - Would that make it easier? |
56 |
|
57 |
Robert |
58 |
-- |
59 |
gentoo-project@g.o mailing list |