1 |
Hi all, |
2 |
|
3 |
I have taken the liberty to update the SELinux subproject page a bit |
4 |
(see [1], nothing major there). During the page review I thought about |
5 |
adding the roadmap information on the SELinux subproject on the page. |
6 |
However, Gentoo Hardened already has a roadmap page, so I looked at that |
7 |
one, but have a few remarks: |
8 |
- many subprojects' roadmap information isn't really "benchmarkable" or |
9 |
however you'd like to put it. It is quite vague |
10 |
- some roadmap entries are not assigned, but also do not have an affiliated |
11 |
bug report |
12 |
- some subprojects do not mention the strategic direction they want to take |
13 |
- the page isn't very pleasing to read (and difficult to navigate by end |
14 |
users) |
15 |
|
16 |
So I tried to rewrite the roadmap, without actually removing anything (so |
17 |
some of the remarks remain). The first try-out here is available at [2]. As |
18 |
you can notice, the document is structured as follows |
19 |
1. Vision = what is Gentoo Hardened all about |
20 |
2. Strategy = how do we see our evolution to implement our vision |
21 |
3. Goals and Milestones (Per Project) |
22 |
a. Short information on the current state |
23 |
b. Goals & Milestones for the project |
24 |
|
25 |
The goals and milestones are described as |
26 |
- a generic description what we want to do / achieve |
27 |
- an estimated time to complete this goal / achieve the milestone |
28 |
- state of the milestone (with colors - yay!) |
29 |
- coordinators |
30 |
- related bugs |
31 |
|
32 |
I think that it would be interesting to have all this information available |
33 |
per goal / milestone (except for unassigned milestones, they probably do not |
34 |
have a coordinator yet). It forces the subproject's roadmaps to be clear and |
35 |
to-the-point. |
36 |
|
37 |
I understand that we're a volunteer-driven distribution, so the ETA is |
38 |
something that is moving, but perhaps we can update this roadmap document |
39 |
before each IRC meeting (or after) so that it is up to date for our users? |
40 |
|
41 |
But I'm not finished yet - oh no. While I read through the existing roadmap |
42 |
document, I noticed that some subprojects had their architecture support |
43 |
mentioned as some sort of milestone. Why not create a support matrix |
44 |
document instead? Such a document can then be used by end users to see if |
45 |
their platform is supported or not (or support is on the way) for each |
46 |
subproject. |
47 |
|
48 |
As we are providing (part of) a distribution, I think many users are |
49 |
interested in this. I tried making one [3] which shows the support matrices |
50 |
for the Hardened Toolchain, grSecurity (although I have no idea what the |
51 |
supported platforms are here) and SELinux. Of course, others can be added, |
52 |
but those were the main ones that I found roadmap information on in the |
53 |
first place. |
54 |
|
55 |
So, what do you think? Is this separation of roadmap vs support matrix a |
56 |
good idea? Is the name of the page (support-state.xml) valid or do you have |
57 |
suggestions otherwise? |
58 |
|
59 |
Also, I noticed that some documents talk about our project as "Gentoo |
60 |
Hardened", others as "Hardened Gentoo". What is the title we give ourselves? |
61 |
I always thought "Gentoo Hardened" is the correct one. "Hardened Gentoo" is |
62 |
the result of applying the projects in "Gentoo Hardened" imo. |
63 |
|
64 |
Wkr, |
65 |
Sven Vermeulen |
66 |
|
67 |
[1] http://xrl.us/bkpo6j |
68 |
[2] http://xrl.us/bkpo62 |
69 |
[3] http://xrl.us/bkpo73 |