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