On 2017.12.21 00:35, William Hubbs wrote:
> 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
> 
> 

William,

I've been running ~arch everywhere since May 2002 and had exactly 
two major issues. They were :-
Xorg going modular ... which I was aware of before it happened and
expat which came as a surprise while I was dealing with modular
Xorg.

There have been some minor inconviences along the way too but
problems running ~arch have reduced over the years.

Nobody should run Gentoo at all in production unless they build
and test packages offline before pushing the binaries to production.
Then they can run whatever they want.
Every Gentoo install is different and very few possible 
combinations are actually tested.

By all means lower the bar for ~arch. Say, to "builds and works for 
me, needs more testing".  The down side is that it will create more
bug reports and more work, so it may only exchange one problem
for another.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

Attachment: pgp1acaAGrvTc.pgp
Description: PGP signature

Reply via email to