On Fri, Aug 01, 2014 at 10:13:33AM +0100, Steven J. Long wrote: > On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote: > > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: > > > A package that hasn't been tested AT ALL doesn't belong in ~arch. > > > Suppose the maintainer is unable to test some aspect of the package, > > > or any aspect of the package? Do we want it to break completely for > > > ~arch? In that event, nobody will run ~arch for that package, and > > > then it still isn't getting tested. > > > > I'm not saying that we should just randomly throw something into ~arch > > without testing it, but ~arch users are running ~arch with the > > understanding that their systems will break from time to time and they > > are expected to be able to deal with it when/if it happens. ~arch is > > not a second stable branch. > > Nor is it a dumping ground for something you can't be bothered to overlay. I can see why teams like gnome, kde, etc choose to use overlays. They have many packages which need to be kept in sync for every release. For single packages though, an overlay is overkill. Also, overlays are purely optional; there is no Gentoo policy requiring their use. In fact, overlays are considered unsupported.
If you don't know that something is going to break, it can go straight to ~arch. If you know that something will cause breakage, sure, it can go to package.mask. Or, if a bug that causes many systems to break is found in a package, the package should go to package.mask until the bug is fixed. > > > I agree that masking for testing is like having a 3rd branch, but I'm > > > not convinced that this is a bad thing. ~arch should be for packages > > > that have received rudimentary testing and which are ready for testing > > > by a larger population. Masking should be used for packages that > > > haven't received rudimentary testing - they might not have been tested > > > at all. > > > > The concern with this argument is the definition of rudimentary testing > > is subjective, especially when a package supports many possible > > configurations. > > Well it can never be fresh from upstream, even if that upstream is a > Gentoo developer. What does this mean? We drop packages that are "fresh from upstream" into ~arch all the time. > eudev is more of a sanity filter, and doesn't claim > to be upstream. Eudev is a fork, so it is its own upstream. Also, it is used by some distros outside of Gentoo. > If anything we want more constraints when a Gentoo dev > is "lead" on a project, as there are even less dykes in the way. Adding more constraints to software that has Gentoo devs as the upstream authors would be a policy I couldn't support. That is a form of discrimination against our own devs. William
signature.asc
Description: Digital signature
