| 1 |
On Mon, 2003-04-14 at 12:29, Mikael Andersson wrote: |
| 2 |
> I don't think stable.gentoo.org is not a good solution since it's too much |
| 3 |
> manual work included from a user for (apparently nothing) in return. |
| 4 |
|
| 5 |
Agreed. |
| 6 |
|
| 7 |
> I think the most efficient way to mark packages stable is statistics based. |
| 8 |
> |
| 9 |
> If you compare number of installations of a package against number of bugs |
| 10 |
> filed and their severity i think you should get pretty decent stability |
| 11 |
> figures for most packages. The exception to this is packages with few users |
| 12 |
> but the users of such packages is probably more interested in 'voting' for |
| 13 |
> their packages. |
| 14 |
|
| 15 |
A tinderbox would be good to work around problems with 'unpopular' |
| 16 |
packages. Over the course of this thread I've seen several problems |
| 17 |
which an automated build and report system would solve. |
| 18 |
|
| 19 |
> This is only an initial suggestion, please comment and improve :) |
| 20 |
> |
| 21 |
> 1) Successful Emerges/Bugs |
| 22 |
> a) Count package downloads and bugs filed. If no blocker/critical bugs |
| 23 |
> exists after a week or two mark as stable. For important packages this rule |
| 24 |
> could be made more stringent. |
| 25 |
|
| 26 |
Good idea. |
| 27 |
|
| 28 |
> b) Count real merges/unmerges of packages and not only package downloads, |
| 29 |
> this should to opt-in since it would in some way need to post information |
| 30 |
> back to gentoo.org |
| 31 |
|
| 32 |
The package system should probably be self-sufficient; the userbase is |
| 33 |
too ephemeral to rely on for something like this; stable.gentoo.org is |
| 34 |
evidence of that; a small fraction of the userbase is a) aware of it, b) |
| 35 |
interested in using it, and c) interested in using it often enough. |
| 36 |
|
| 37 |
Probably the only input a package should receive from a person is from |
| 38 |
the maintainer itself. |
| 39 |
|
| 40 |
Which leads me into another problem; currently there are no official |
| 41 |
maintainers for a large number of the ebuilds in the tree. This prevents |
| 42 |
the above from being doable; no one is around to represent and vouch for |
| 43 |
the functionality of those ebuilds, just the bug reporting system. |
| 44 |
|
| 45 |
So, is a tinderbox doable? One would have to be volunteered for each |
| 46 |
supported architecture, or at least x86, sparc and powerpc to begin |
| 47 |
with. One foreseeable complication would be the nearly infinite number |
| 48 |
of combinations of USE flags, but I'm sure with discussion a way around |
| 49 |
this could be found. |
| 50 |
|
| 51 |
Thoughts? |
| 52 |
|
| 53 |
Brad |
| 54 |
|
| 55 |
|
| 56 |
-- |
| 57 |
gentoo-dev@g.o mailing list |
Archives