public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brad Laue <brad@brad-x.com>
To: Mikael Andersson <snikkt@telia.com>
Cc: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Is there a process for marking ebuilds stable?
Date: 14 Apr 2003 18:03:10 -0400	[thread overview]
Message-ID: <1050357790.15341.16.camel@localhost> (raw)
In-Reply-To: <200304141630.02243.snikkt@telia.com>

On Mon, 2003-04-14 at 12:29, Mikael Andersson wrote:
> I don't think stable.gentoo.org is not a good solution since it's too much
> manual work included from a user for (apparently nothing) in return.

Agreed.

> I think the most efficient way to mark packages stable is statistics based.
> 
> If you compare number of installations of a  package against number of bugs
> filed and their severity i think you should get pretty decent stability 
> figures for most packages. The exception to this is packages with few users
> but the users of such packages is probably more interested in 'voting' for 
> their packages.

A tinderbox would be good to work around problems with 'unpopular'
packages. Over the course of this thread I've seen several problems
which an automated build and report system would solve.

> This is only an initial suggestion, please comment and improve :)
> 
> 1) Successful Emerges/Bugs
>   a) Count package downloads and bugs filed. If no blocker/critical bugs 
> exists after a week or two mark as stable. For important packages this rule
> could be made more stringent.

Good idea.

>   b) Count real merges/unmerges of packages and not only package downloads, 
> this should to opt-in since it would in some way need to post information 
> back to gentoo.org

The package system should probably be self-sufficient; the userbase is
too ephemeral to rely on for something like this; stable.gentoo.org is
evidence of that; a small fraction of the userbase is a) aware of it, b)
interested in using it, and c) interested in using it often enough.

Probably the only input a package should receive from a person is from
the maintainer itself.

Which leads me into another problem; currently there are no official
maintainers for a large number of the ebuilds in the tree. This prevents
the above from being doable; no one is around to represent and vouch for
the functionality of those ebuilds, just the bug reporting system.

So, is a tinderbox doable? One would have to be volunteered for each
supported architecture, or at least x86, sparc and powerpc to begin
with. One foreseeable complication would be the nearly infinite number
of combinations of USE flags, but I'm sure with discussion a way around
this could be found.

Thoughts?

Brad


--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2003-04-14 22:03 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 [this message]
2003-04-14 15:07     ` Brad Laue
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=1050357790.15341.16.camel@localhost \
    --to=brad@brad-x.com \
    --cc=gentoo-dev@gentoo.org \
    --cc=snikkt@telia.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