From: Luca Barbato <lu_zero@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
Date: Tue, 12 Jun 2007 12:48:11 +0200 [thread overview]
Message-ID: <466E79EB.1030208@gentoo.org> (raw)
In-Reply-To: <466E772F.6010807@thefreemanclan.net>
Richard Freeman wrote:
> Can you clarify this? What scenarios do you run into where it isn't
> good for stable users to have access to more than one version of the
> software?
- Security issues.
- "Downgrade to hell" scenarios
- Other colorful issues that may happen from time to time.
>
> One thing that I noticed is that in many cases there are multiple
> testing versions of a package available, and one stable version. So, if
> you run unstable you can pick and choose, but if you're running stable
> (which in theory should be the target audience gentoo aims for) then you
> get your choice of only one.
The stable one is supposed to be the best available, the ~ ones are
supposed to be "in flux"
>
> I tend to think that unless something unusual is going on that old
> packages should be kept around for a while (a few weeks at least).
Happens more than often =)
> Others have pointed out that inflexible rules aren't always the answer.
> I'd agree in general, but there should be guidelines. Maybe certain
> packages shouldn't have multiple stable versions to choose from. But
> when "certain packages" becomes 80% of them then I'd wonder if there
> really is a good reason for this...
Keep in mind that the trade off is :
- our time
- our sanity
- what provide to our used
- the quality of what we provide to out users.
We all try our best to not burn out while serving you the best we could
think.
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-06-12 10:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-12 9:40 [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree cilly
2007-06-12 9:49 ` [gentoo-dev] " Christian Faulhammer
2007-06-12 9:53 ` cilly
2007-06-12 9:59 ` [gentoo-dev] " Luca Barbato
2007-06-12 10:04 ` Fernando J. Pereda
2007-06-12 10:01 ` Fernando J. Pereda
2007-06-12 10:14 ` cilly
2007-06-12 10:21 ` Fernando J. Pereda
2007-06-12 10:30 ` cilly
2007-06-12 10:40 ` Marijn Schouten (hkBst)
2007-06-12 10:48 ` cilly
2007-06-12 11:09 ` Marijn Schouten (hkBst)
2007-06-12 10:36 ` Richard Freeman
2007-06-12 10:46 ` Fernando J. Pereda
2007-06-12 10:53 ` cilly
2007-06-12 10:59 ` cilly
2007-06-12 11:27 ` Luca Barbato
2007-06-12 11:37 ` cilly
2007-06-12 11:29 ` Christoph Mende
2007-06-12 11:38 ` cilly
2007-06-13 14:35 ` Robert Buchholz
2007-06-13 14:58 ` Brian Harring
2007-06-12 16:55 ` [gentoo-dev] " Duncan
2007-06-13 14:44 ` banym tuxaner
2007-06-12 11:03 ` [gentoo-dev] " Fernando J. Pereda
2007-06-12 11:08 ` cilly
2007-06-12 16:05 ` Luis Francisco Araujo
2007-06-12 10:48 ` Luca Barbato [this message]
2007-06-12 10:50 ` cilly
2007-06-12 11:21 ` Petteri Räty
2007-06-12 11:50 ` cilly
2007-06-12 11:00 ` Marijn Schouten (hkBst)
2007-06-12 11:25 ` [gentoo-dev] " Christian Faulhammer
2007-06-12 11:52 ` cilly
2007-06-12 12:55 ` [gentoo-dev] " Marius Mauch
2007-06-12 12:59 ` cilly
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=466E79EB.1030208@gentoo.org \
--to=lu_zero@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