From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'
Date: Fri, 02 Jul 2004 17:37:29 -0400 [thread overview]
Message-ID: <1088804249.9271.55.camel@localhost> (raw)
In-Reply-To: <200407021706.44649.absinthe@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
On Fri, 2004-07-02 at 17:06, Dylan Carlson wrote:
> On Friday 02 July 2004 4:29 pm, Chris Gianelloni wrote:
> > A "tested profile" would also have to include specific versions,
> > otherwise there is no way that a person could properly certify the
> > validity of the test.
>
> I agree. The profiles only list ~70 packages and those versions aren't
> pinned. Although maybe they should be. The difference between the
> versions in a tested configuration/profile and what ends up getting
> installed later should include security updates (backported security
> fixes) -- which is not something we do right now...
...and I doubt that we ever will. Gentoo tries to remain as much like
the upstream packages as possible, which means we're more likely to
require an upgrade than to back-port a patch. This is the exact reason
why any plans for an enterprise version of Gentoo all focus on being a
separate project from Gentoo proper. I know for a fact that I don't
want to waste the precious development time that I have doing the
mundane task of back-porting patches to some old version of a package
that I've long since forgotten.
> My point is that I believe we could address this (at least in part) by
> pinning versions in profiles, and having repoman block commits that
> attempt to remove ebuilds that are required by a profile. It's not a new
> idea. This, instead of branching CVS. Although I'm not opposed to that
> idea either, but IIRC some devs are...
Pinning versions in the profiles sounds pretty cool, but it turns
*every* package maintainer and arch maintainer into a profile
maintainer, which I think is a bad idea. It also bloats the portage
tree, since there would be multiple versions of every ebuild, compared
to the one or two for most packages that we have now. I still think
that the "pinned" tree should be a separate branch.
--
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux
Is your power animal a penguin?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-07-02 21:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-02 1:20 [gentoo-dev] Policy for retirement of old gentoo "versions" Barry Shaw
2004-07-02 2:17 ` [gentoo-dev] Policy for retirement of old gentoo 'versions' Donnie Berkholz
2004-07-02 12:48 ` Chris Gianelloni
2004-07-02 13:44 ` William Kenworthy
2004-07-02 14:41 ` Grant Goodyear
2004-07-02 15:15 ` Dylan Carlson
2004-07-02 20:29 ` Chris Gianelloni
2004-07-02 21:06 ` Dylan Carlson
2004-07-02 21:37 ` Chris Gianelloni [this message]
2004-07-03 6:34 ` Dylan Carlson
2004-07-04 22:10 ` Marius Mauch
2004-07-05 1:14 ` Dylan Carlson
2004-07-04 22:16 ` Barry Shaw
2004-07-05 1:01 ` Dylan Carlson
2004-07-05 2:19 ` Barry Shaw
2004-07-02 20:21 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1088804249.9271.55.camel@localhost \
--to=wolf31o2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox