Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-web-user
Navigation:
Lists: gentoo-web-user: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-web-user@g.o
From: Renat Lumpau <rl03@g.o>
Subject: Re: Upstream requirements for web-apps
Date: Sun, 15 Jan 2006 17:49:59 +0000
On Wed, Jan 11, 2006 at 04:59:56PM +0100, wrobel@g.o wrote:
> The current proposition is specified here:
> 
> http://svn.gnqs.org/projects/gentoo-webapps-overlay/wiki/UpstreamRequirements
> 
> In my discussion with Stuart this morning I did realize that there are
> not too many packages available that would actually meet these
> criteria. So far we probably have around five in the portage tree. 

I'm still not 100% clear on rationale for requirements as outlined there.
As Gunnar pointed out, very few packages in Portage currently satisfy those.
Perhaps it would make sense for us to start by outlining the goals of our
upstream requirements (e.g., reliable contact in case of security bugs) and then
decide how to best achieve them?

> The main blocker are the security requirements since many projects do
> not provide special security contacts or mailing lists devoted
> security. For some projects this probably implies that they actually
> don't care too much about security.

This also makes it difficult for us to ship packages that are maintained by a
one-man team. While there's something to be said about the maturity and
reliability of such packages, we shouldn't automatically disqualify them.

> I also had the impression that one of the packages that has been a
> mojor problem last year (phpBB) actually nearly fulfills the current
> requirement proposals (at least to a greater extend than many of the
> smaller packages) but nonetheless has caused quite an amount of grief.
> Having bugs tracker, announcement lists and security mails might not
> always cover up for direct experience with the project itself.

Excellent point.

> So I would suggest that we enforce the current proposal in the all
> cases where we do not have a developer in our herd actively using the
> package. I think that any dev's of our herd that actively uses a
> package is probably a better source of information about the security
> of the package than the mailing lists of the project. At least as long
> as I assume that we care a lot more about the security of our servers
> than the average user. But I believe that's a safe bet.

I don't actively use most of the packages I have been maintaining
(bugzilla, otrs, joomla etc). This means that we'd still have to drop a large
number of ebuilds. Perhaps that's not such a bad thing though.

I've been toying with the idea of limiting Portage to a key set of web-apps that
are broken down into several categories such as CMS, wiki engines, fora, etc.
Personally, I don't think we need to ship every wiki package out there. Of
course, we'd need to tread carefully to avoid the appearance of limiting
end-user choice, which is where our overlay comes in. Any thoughts on this?

-- 
Renat Lumpau
all things web-apps
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
Attachment:
pgpKQTfytTsY7.pgp (PGP signature)
Replies:
Re: Upstream requirements for web-apps
-- Gunnar Wrobel
Re: Upstream requirements for web-apps
-- Gunnar Wrobel
Re: Upstream requirements for web-apps
-- Wendall Cada
References:
Upstream requirements for web-apps
-- wrobel
Navigation:
Lists: gentoo-web-user: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Upstream requirements for web-apps
Next by thread:
Re: Upstream requirements for web-apps
Previous by date:
Upstream requirements for web-apps
Next by date:
Re: Upstream requirements for web-apps


Updated Jun 17, 2009

Summary: Archive of the gentoo-web-user mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.