1 |
Renat Lumpau <rl03@g.o> writes: |
2 |
> We're in good shape now, but we weren't even a couple of months ago. At this |
3 |
> point, we should be fine if we take care of ongoing maintenance, but things can |
4 |
> _quickly_ turn ugly. As a matter of fact, I'll be offline for the better part of |
5 |
> the summer, possibly as early as May, and I'd really like to make sure I don't |
6 |
> spend another 4 months crawling through 150+ bugs when I return in September. |
7 |
> |
8 |
>> What is hard for me to judge is what kind of impact the security |
9 |
>> problems had during the last year. What were the main problems for the |
10 |
>> web-apps herd? |
11 |
> |
12 |
> There may have been a few security bugs to which we did not react as urgently as |
13 |
> we should have. I don't know any specific instances because I wasn't around, and |
14 |
> when I was, we reacted quickly :) Not to say that I'm the only person doing the |
15 |
> work, just can't speak for all security issues we've had. |
16 |
> |
17 |
> As far as I'm concerned, the main problem is that we were badly out of sync with |
18 |
> upstream for a few months when I was on hiatus. That means dissatisfied users, |
19 |
> lots of bugs, potential security issues, etc etc etc. |
20 |
|
21 |
Ok, so this clearly describes a man power problem that currently does |
22 |
not exist. I know from personal experience that I only have about half |
23 |
a day for looking at a bug assigned to webapps until Renat wakes up and |
24 |
fixes it :) But it's clear that the herd should be able to handle the |
25 |
bugs in case Renat is not around. |
26 |
|
27 |
I think Renats suggestion to reduce the portage tree to a limited set of |
28 |
packages that cover a variety of different topics makes sense. |
29 |
|
30 |
Would it be reasonable to try to define two webapps members as primary |
31 |
maintainers for each of the packages that we select? I believe that |
32 |
could reduce the effect of looking at a bug and deciding that |
33 |
"somebody" will certainly fix it. |
34 |
|
35 |
I believe that we should not make the current suggestion for the |
36 |
security requirements a real requirement for the list of selected |
37 |
applications but instead just declare them as the desired goal. |
38 |
|
39 |
As I mentioned in my last mail, I wanted to be able to have additional |
40 |
packages in portage that I personally use. The main reason for that |
41 |
was that I feel that the overlay will never be on the same level as |
42 |
the tree itself. While it is not extremely complex to use the user |
43 |
will have to know about it, install subversion, check out a |
44 |
repository, and modify the make.conf. This is more than what I |
45 |
consider necessary to tell the user "that this package is less well |
46 |
maintained / less secure than the packages in the main portage tree". |
47 |
I guess it will actually prevent a number of people from ever |
48 |
seeing the package. |
49 |
|
50 |
In addition I believe some users might not be exactly happy if we |
51 |
start moving packages out of portage into the overlay. |
52 |
|
53 |
So in order to make the process less complex I will provide |
54 |
"layman". The tool is able to manage gentoo overlays. In order to get |
55 |
the webapps overlay you run |
56 |
|
57 |
emerge layman |
58 |
layman -f -a webapps-stable -a webapps-experimental |
59 |
|
60 |
to get both overlays fetched and added to your make.conf |
61 |
automatically. To update the repositories you can later run |
62 |
|
63 |
layman --sync |
64 |
|
65 |
People that want to crash their hard drives can get it from my |
66 |
overlay: |
67 |
|
68 |
layman -f -a wrobel-stable |
69 |
emerge layman |
70 |
|
71 |
:) |
72 |
|
73 |
I think this significantly reduces the differences between the overlay |
74 |
and the tree. As a result my urge to add stuff to the tree would also |
75 |
be significantly reduced. And I think that moving stuff from the tree |
76 |
to the overlay would then be an acceptable option. |
77 |
|
78 |
For the overlay I would suggest that the "production-stable" branch |
79 |
should be only accesible to devs and that we handle it the same way as |
80 |
we currently handle the tree. The "experimental" branch would continue |
81 |
to be our playground. |
82 |
|
83 |
Cheers, |
84 |
|
85 |
Gunnar |
86 |
|
87 |
-- |
88 |
Gunnar Wrobel Gentoo Developer |
89 |
__________________C_o_n_t_a_c_t__________________ |
90 |
|
91 |
Mail: wrobel@g.o |
92 |
WWW: http://www.gunnarwrobel.de |
93 |
IRC: #gentoo-web at freenode.org |
94 |
_________________________________________________ |