On Wed, Dec 20, 2017 at 07:12:45PM -0500, Michael Orlitzky wrote: > On 12/20/2017 06:58 PM, William Hubbs wrote: > > > > There already is an overlay for dying packages, it is called graveyard, > > but no one is putting things there. > > > > This email conflates old dying packages with new versions, which are a > > completely separate issue. > > > > Lack of new versions *is* dying. But I can make a package not-dying in a > few seconds by merging a PR, so long as you don't expect me to do the > (relatively high) level of QA required for ~arch. > > > > If a new version of a package is known to cause wide scale breakage, it > > goes in package.mask until the breakage is resolved. Otherwise, putting > > it in ~ is fine. I don't see the need for another level of keywords. > > The quality of ~arch is its own worst enemy; these days, stable packages > are just old ~arch packages. Users and developers expect ~arch to work, > and we have no real policy or documentation stating that it won't. Many > people will tell you that ~arch works better than stable, because it > gets fixed faster.
~arch *will* have breakages from time to time, sometimes major breakages, until they are masked or fixed. We are not supposed to leave major breakages there, but ~arch is definitely not for the faint of heart. If you are using ~arch, you are expected to be a power user at leasst and be able to recover if your system breaks. Production servers should not be running ~arch at all. That's the whole reason ~arch exists. Yes, ~arch gets fixed faster than stable, but that is to be expected. However, it is definitely not a good reason to put your production system on full ~arch. So, I guess this means that the quality of the ~arch tree is supposed to be somewhat lower than the quality of the stable tree. William
signature.asc
Description: Digital signature
