Rich Freeman:> 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.
Huh? That's exactly the place. However, if you mean "AT ALL" in the sense that no one ever tried to compile it, then the guy who comitted should not have commit rights. > 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. In that event, you will get a bug report VERY soon. > I agree that masking for testing is like having a 3rd branch, but I'm > not convinced that this is a bad thing. I have to reiterate: * increases the workload, because we are effectively running 3 branches * decreases the amount of testing for that time period, because... it's masked * causes confusion (see this thread) * decreases the quality of our stable branch, because people suddenly expect the unstable branch to be ...stable and don't bother with filing stabilization requests anymore * makes the whole testing/stabilization iteration actually slower, possibly even causing unnecessary exposures to security issues * causes inconsistency, because not everyone actually agrees on the 3-branches concept and it was never actually decided to be one > Sure, it could go into an overlay, but for that matter so could all of ~arch. Not at all. I made a clear distinction for that. Overlays have some good use cases, but even those get abused and we end up with projects not caring to import ebuilds to the tree anymore. To make the situation even worse, a lot of people don't mask broken packages if they have ever been in ~arch, as if this is a one-way road from hardmask->keywordmask->stable. No, it isn't. > 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? Trying to fix * workflow * user experience * quality of stable branch Inconsistent usage of hardmasks is only one problem here, but it is one. So, from my POV hardmasks are reasonable for these use cases: * package was imported to ~arch, turned out broken, bugs are difficult to fix, no improvement upstream * package has security issues, but we don't want it removed (happens a lot for games) * package is known to be broken, but we want it in the tree (like googleearth) * package is a library and is either known to or expected to break more than half of it's consumers The last 3 points can, depending on the actual situation, be a good use case for an overlay. Some already do it, including for non-trivial libraries. To make a blunt statement here: many commits in profiles/ cause trouble for the user in one way or another. Some people on the forums already told us they want to switch, because they are sick of dealing with world updates since they seem get more and more complicated. For multilib we have been abusing profiles/ a lot, since there is only one alternative way which is almost impossible to carry out given the large scale of these changes: a parallel branch which gets imported in one blow. Profile hackery has to get less. It's not improving user experience. Users are switching to ~arch, because people tell them on IRC and elsewhere that it's "almost stable" and that arch is too slow. That makes the situation even worse. In addition, we should make the most important arch testing points/techniques part of the quizzes and allow maintainers to carry out stabilization on major arches if they have access to them (that doesn't mean they have to, they can still request help from the dedicated arch teams). Having no clear release scheme can be neck-breaking for a project. Rolling release or not. But I doubt we will come to any conclusion here. This thread will get some bikeshed and if someone really cares, he will bring it up to the council which will basically say "we encourage foo, but allow bar as well and leave anything else up to the maintainer", neither deciding on a real 3rd branch, nor declining it (because if they would decide on a 3rd branch, they would actually have to come up with a PMS addition that is sane and not ambigous like hardmasks which are used for all random sorts of things... and don't tell me hardmask messages can be used as an API).
