1 |
On Wed, Jan 11, 2006 at 04:59:56PM +0100, wrobel@g.o wrote: |
2 |
> The current proposition is specified here: |
3 |
> |
4 |
> http://svn.gnqs.org/projects/gentoo-webapps-overlay/wiki/UpstreamRequirements |
5 |
> |
6 |
> In my discussion with Stuart this morning I did realize that there are |
7 |
> not too many packages available that would actually meet these |
8 |
> criteria. So far we probably have around five in the portage tree. |
9 |
|
10 |
I'm still not 100% clear on rationale for requirements as outlined there. |
11 |
As Gunnar pointed out, very few packages in Portage currently satisfy those. |
12 |
Perhaps it would make sense for us to start by outlining the goals of our |
13 |
upstream requirements (e.g., reliable contact in case of security bugs) and then |
14 |
decide how to best achieve them? |
15 |
|
16 |
> The main blocker are the security requirements since many projects do |
17 |
> not provide special security contacts or mailing lists devoted |
18 |
> security. For some projects this probably implies that they actually |
19 |
> don't care too much about security. |
20 |
|
21 |
This also makes it difficult for us to ship packages that are maintained by a |
22 |
one-man team. While there's something to be said about the maturity and |
23 |
reliability of such packages, we shouldn't automatically disqualify them. |
24 |
|
25 |
> I also had the impression that one of the packages that has been a |
26 |
> mojor problem last year (phpBB) actually nearly fulfills the current |
27 |
> requirement proposals (at least to a greater extend than many of the |
28 |
> smaller packages) but nonetheless has caused quite an amount of grief. |
29 |
> Having bugs tracker, announcement lists and security mails might not |
30 |
> always cover up for direct experience with the project itself. |
31 |
|
32 |
Excellent point. |
33 |
|
34 |
> So I would suggest that we enforce the current proposal in the all |
35 |
> cases where we do not have a developer in our herd actively using the |
36 |
> package. I think that any dev's of our herd that actively uses a |
37 |
> package is probably a better source of information about the security |
38 |
> of the package than the mailing lists of the project. At least as long |
39 |
> as I assume that we care a lot more about the security of our servers |
40 |
> than the average user. But I believe that's a safe bet. |
41 |
|
42 |
I don't actively use most of the packages I have been maintaining |
43 |
(bugzilla, otrs, joomla etc). This means that we'd still have to drop a large |
44 |
number of ebuilds. Perhaps that's not such a bad thing though. |
45 |
|
46 |
I've been toying with the idea of limiting Portage to a key set of web-apps that |
47 |
are broken down into several categories such as CMS, wiki engines, fora, etc. |
48 |
Personally, I don't think we need to ship every wiki package out there. Of |
49 |
course, we'd need to tread carefully to avoid the appearance of limiting |
50 |
end-user choice, which is where our overlay comes in. Any thoughts on this? |
51 |
|
52 |
-- |
53 |
Renat Lumpau |
54 |
all things web-apps |
55 |
GPG key id #C6A838DA on http://pgp.mit.edu |
56 |
Key fingerprint = 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA |