From: Brad Laue <brad@brad-x.com>
To: Fredrik Jagenheim <humming@pobox.com>
Cc: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Is there a process for marking ebuilds stable?
Date: 14 Apr 2003 11:07:01 -0400 [thread overview]
Message-ID: <1050332821.31618.10.camel@localhost> (raw)
In-Reply-To: <20030414073218.GB441@pobox.com>
On Mon, 2003-04-14 at 03:32, Fredrik Jagenheim wrote:
> Thus, I propose an extension to emerge that would look through your
> system and see which packages are marked as 'unstable' and ask the
> user interactively if they think the packages are OK. The responses
> could be of the type:
> 1) Yes, I've used it extensively and it works.
> 2) Yes, I've used it somewhat and it seems to work.
> 3) No idea, I don't think I've used it, but nothing is broke.
> 4) No idea, I haven't used it at all yet.
> 5) No, it doesn't work and I've used bugzilla to report the bug.
With some criteria this would be a good idea.
A big question is whether or not Gentoo should concern itself with the
operational functionality of the package in question. A 'does it build'
criteria would very efficiently mark packages stable.
But what if a new point release of foo introduces a bug that causes a
crash? Should Gentoo be responsible for marking the package stable or
unstable on that basis?
I don't think this is practical, although this is what seems to occur
fairly regularly based on my perusal of bugs.gentoo.org. This tends to
cause ebuilds which otherwise work fine to remain marked unstable even
if the user reporting the bug has made a mistake.
Perhaps a combination. If it builds succesfully with ALSA, KDE, GNOME in
the USE flags and sufficient numbers of people report this, mark it
stable. Also leave three prior release versions available for
installation marked stable in case the latest introduces a flaw caused
by programmer error. Introduce patches and fixes to the ebuilds as bugs
are reported.
--
// -- http://www.BRAD-X.com/ -- //
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-04-14 15:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-13 22:25 [gentoo-dev] Is there a process for marking ebuilds stable? Brad Laue
2003-04-13 23:00 ` Rainer Groesslinger
2003-04-13 23:07 ` Rainer Groesslinger
2003-04-13 23:07 ` Jon Portnoy
2003-04-14 9:31 ` Rainer Groesslinger
2003-04-14 7:32 ` Fredrik Jagenheim
2003-04-14 9:00 ` Michael Kohl
2003-04-14 11:04 ` Fredrik Jagenheim
2003-04-14 16:29 ` Mikael Andersson
2003-04-14 20:31 ` Alec Berryman
2003-04-14 21:48 ` Brad Laue
2003-04-14 21:58 ` Alec Berryman
2003-04-15 11:07 ` Mikael Andersson
2003-04-14 22:03 ` Brad Laue
2003-04-14 15:07 ` Brad Laue [this message]
2003-04-14 19:39 ` C. Brewer
2003-04-15 6:21 ` Abhishek Amit
2003-04-15 9:09 ` Fredrik Jagenheim
2003-04-16 0:34 ` C. Brewer
2003-04-15 13:53 ` Brad Laue
-- strict thread matches above, loose matches on Subject: below --
2003-04-15 2:08 Todd Wright
2003-04-15 2:30 ` Jon Portnoy
2003-04-15 5:41 ` Dylan Carlson
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=1050332821.31618.10.camel@localhost \
--to=brad@brad-x.com \
--cc=gentoo-dev@gentoo.org \
--cc=humming@pobox.com \
/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