On Mon, Jun 30, 2014 at 7:29 AM, hasufell <hasuf...@gentoo.org> wrote: > 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.
I mean in the sense that it has been compiled, but that it hasn't been executed, or the maintainer believes that it significant portions of it haven't been executed. Simply being able to compile something shouldn't really be grounds for sticking it in ~arch, at least not for x86/amd64. I could see that workflow making more sense for obscure archs where users are happy to have any packages at all and the fact that something compiles is a useful data point. > >> 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. I have mixed feelings on this. On the one hand I think having "first-class" overlays could be a better solution to getting more outside contribution, and allowing for more variety in QA standards (with users being able to choose). Many distros have a large percentage of their packages in unofficial repositories of some kind. On the other hand, Gentoo is not release-based, which means that overlays will basically always be broken. There has been talk about better announcing changes to common deps and not just quietly patching the tree so that overlay maintainers aren't behind the times. However, overlays will never get systematically tested before changes are made in the main tree, and since we don't have releases that is going to make them problematic. So, I guess I tend to agree with you more than not. > 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. I couldn't agree more here. If we're going to define ~arch as basically stable, and arch as out-of-date, then we might as well drop keywords entirely. That makes no sense, unless you're actually backporting things like Debian does, which we don't. > > 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). > You're basically asking for the practice of hard-masks for testing to be banned. If the council disagrees, it doesn't mean that somebody has to come up with some mechanism to have some full-featured 3rd branch in Gentoo. Maybe they just agree that on occasion it is useful to use hard-masks for testing. Nobody is saying that these masks should sit around for months. That falls into the same category as packages that haven't been revbumped in months despite upstream having new releases. Rich
