Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

On Wed, 2004-06-23 at 19:01 +0000, Ferris McCormick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 23 Jun 2004, foser wrote:
>
> > > >
> > > I don't think it's just duplication.  There have been so many of these, I
> > > am not sure which one to attach this thought to, so I picked this one
> > > because it is short.  And, if I understand your point, this speaks to it.
> > >
> > > I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> > > any architecture.
> > >
> > > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> > >     means essentially one thing:  In my best judgment this package is
> > >     stable for use on sparc.  It doesn't say anything about other
> > >     architectures (except as evidence of goodness).
> >
> > You are not the package maintainer, you should not mark it stable before
> > that happens. So your arch going stable has no wider significance.
> >
> Sure it does, unless the maintainer never makes mistakes.  It's more
> evidence that the package is good (consider the endian problems which
> come up now and then.  If maintainer is little-endian and sparc goes
> stable, that suggests to other big-endian archs that there is probably
> not an endian concern. Look at games, sys-cluster, and I think you'll
> find examples where number of stable architectures matters.)

Well, it only proves it is _more_ stable, but the significance of the
'maintainer arch' is that it is considered a general bugfree ebuild as
far as known bugs is concerned. Arch specific issues are for the arch
maintainers.
 
> For 2.b: Consider a LaTeX document class (there are some in portage) --
> almost certainly architecture-neutral, and maintainer's blessing is
> almost certainly definitive.
>
> For 2.a: Consider a multiprocessor performance measurement tool working
> at a very low level. -- almost certainly architecture-specific, and
> maintainer's blessing might mean only that it's usable on a specific
> architecture.

Nah, we already earlier in the discussion special cased lowlevel
toolchain stuff. It's logical a more direct arch specific direction is
taken there. Anyway as said, the marking stable is more about known
general bugs being resolved and the ebuild being clean & bugfree.

This is more of a general Gentoo wide approach, where arch involvement
usually is limited to marking stable. The arch teams are much smaller
than the maintainers teams, thats pretty much the underlying thought.

- foser