1 |
Renat Lumpau <rl03@g.o> writes: |
2 |
|
3 |
> On Wed, Jan 11, 2006 at 04:59:56PM +0100, wrobel@g.o wrote: |
4 |
>> The current proposition is specified here: |
5 |
>> |
6 |
>> http://svn.gnqs.org/projects/gentoo-webapps-overlay/wiki/UpstreamRequirements |
7 |
>> |
8 |
>> In my discussion with Stuart this morning I did realize that there are |
9 |
>> not too many packages available that would actually meet these |
10 |
>> criteria. So far we probably have around five in the portage tree. |
11 |
> |
12 |
> I'm still not 100% clear on rationale for requirements as outlined there. |
13 |
> As Gunnar pointed out, very few packages in Portage currently satisfy those. |
14 |
> Perhaps it would make sense for us to start by outlining the goals of our |
15 |
> upstream requirements (e.g., reliable contact in case of security bugs) and then |
16 |
> decide how to best achieve them? |
17 |
|
18 |
Concerning the goals I have a question: How much of a problem do we |
19 |
currently really have concerning man power in web-apps? If I look at |
20 |
bugzilla, web-apps seems to be in pretty good shape or am I mistaken |
21 |
there? |
22 |
|
23 |
What is hard for me to judge is what kind of impact the security |
24 |
problems had during the last year. What were the main problems for the |
25 |
web-apps herd? |
26 |
|
27 |
In the end security is always a compromise between quality, ease of use and |
28 |
the actual man power available. I admit that I'm usually in favor of usability |
29 |
as long as that is something we can provide with a good conscience. |
30 |
|
31 |
> |
32 |
>> The main blocker are the security requirements since many projects do |
33 |
>> not provide special security contacts or mailing lists devoted |
34 |
>> security. For some projects this probably implies that they actually |
35 |
>> don't care too much about security. |
36 |
> |
37 |
> This also makes it difficult for us to ship packages that are maintained by a |
38 |
> one-man team. While there's something to be said about the maturity and |
39 |
> reliability of such packages, we shouldn't automatically disqualify them. |
40 |
> |
41 |
>> I also had the impression that one of the packages that has been a |
42 |
>> mojor problem last year (phpBB) actually nearly fulfills the current |
43 |
>> requirement proposals (at least to a greater extend than many of the |
44 |
>> smaller packages) but nonetheless has caused quite an amount of grief. |
45 |
>> Having bugs tracker, announcement lists and security mails might not |
46 |
>> always cover up for direct experience with the project itself. |
47 |
> |
48 |
> Excellent point. |
49 |
> |
50 |
>> So I would suggest that we enforce the current proposal in the all |
51 |
>> cases where we do not have a developer in our herd actively using the |
52 |
>> package. I think that any dev's of our herd that actively uses a |
53 |
>> package is probably a better source of information about the security |
54 |
>> of the package than the mailing lists of the project. At least as long |
55 |
>> as I assume that we care a lot more about the security of our servers |
56 |
>> than the average user. But I believe that's a safe bet. |
57 |
> |
58 |
> I don't actively use most of the packages I have been maintaining |
59 |
> (bugzilla, otrs, joomla etc). This means that we'd still have to drop a large |
60 |
> number of ebuilds. Perhaps that's not such a bad thing though. |
61 |
> |
62 |
> I've been toying with the idea of limiting Portage to a key set of web-apps that |
63 |
> are broken down into several categories such as CMS, wiki engines, fora, etc. |
64 |
> Personally, I don't think we need to ship every wiki package out there. Of |
65 |
> course, we'd need to tread carefully to avoid the appearance of limiting |
66 |
> end-user choice, which is where our overlay comes in. Any thoughts |
67 |
> on this? |
68 |
|
69 |
Depends pretty much on whether we decide to clean the tree and move |
70 |
packages out. Once we get an estimate on what amount of package we |
71 |
want to support for the main portage tree we could decide how to |
72 |
distribute that to different categories. |
73 |
|
74 |
-- |
75 |
Gunnar Wrobel Gentoo Developer |
76 |
__________________C_o_n_t_a_c_t__________________ |
77 |
|
78 |
Mail: wrobel@g.o |
79 |
WWW: http://www.gunnarwrobel.de |
80 |
IRC: #gentoo-web at freenode.org |
81 |
_________________________________________________ |