On 2014.06.30 05:01, William Hubbs wrote: > All, > > I am starting a new thread so we don't refer to a specific package, > but I > am quoting Rich and hasufell from the previous masking thread. > > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: > > On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasuf...@gentoo.org> > wrote: > > > This is still too vague for me. If it's expected to be short- > term, > then > > > it can as well just land in ~arch. > > > > 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. > > > 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. > > I think some packages need wide testing before they go stable, and > that > is where ~arch can help out. > > In particular, I would argue that for system-critical packages, users > should be very careful about running ~arch unless they know what the > fallout can be. > > *snip* > > > I guess the question is, what exactly are we trying to fix? Even > if > > occasionally a maintainer drops the ball and leaves something > masked > > for a year, how is that different from a maintainer dropping the > ball > > and not adding a new release to the main tree for a year? Would we > be > > better off if Docker 1 wasn't in the tree at all? If it happened > to > > have a known issue would ~arch users be better off if some other > dev > > came along and helpfully added it to the tree unmasked no realizing > > that somebody else was already working on it? > > Take a look at profiles/package.mask. You will see many packages in > there with the description, "masked for testing" on their masks, with > no > bug references, that have been there for multiple years. My view is > we > should either get those masks resolved or boot the affected > packages/versions out of the tree. If they haven't received > rudimentary > testing by now, it is pretty obvious that no one cares about them. > > William > >
Once upon a time, not so long ago I don't remember it, there were very few overlays. At that time, there was always a lot of packages in the tree "masked for testing". At that time, well before layman, overlays were inconvenient. As overlays have become more widespread and used as a way to lower the barrier to contributing directly to Gentoo, there are fewer packages "masked for testing". I like the old way, it avoids installing yet another overlay but clearly others feel differently or there would not be so many overlays to choose from. The reality is, both ways work for me. Pragmatically, its not practical to merge all of the overlays into the tree, then ban overlays. That would be a return to the old way. This just represents a change of workflow with time. The question then is do we need to formalise the changed workflow, or can both be allowed to continue side by side? -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
pgpwJVV2X65ZZ.pgp
Description: PGP signature
