Re: [gentoo-dev] package.mask vs ~arch
Greg KH: On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. What toys? Were we given some when we became developers? If I had some I'd send mine back in, but as I don't, I'll keep committing stable kernel ebuilds that I never test as no one seems to be complaining... greg never make absolute statements k-h Depends on what you mean with testing. Just renaming ebuilds like foo-1.2.ebuild - foo-1.3.ebuild and letting the community figure out if that even makes sense (e.g. the ebuild dies in src_prepare, because a patch fails or is missing) is a bit rough, although it may work if you know the underlying package very well. If you are talking about actually testing and running the software then that's a different story and definitely not within our scope when committing to ~arch. That said, I think it's a reasonable minimum to at least check if an ebuild emerges on my current machine with my current setup before committing to ~arch. If even that fails, what's the point of committing the ebuild?
Re: [gentoo-dev] package.mask vs ~arch
On Sun, Jul 06, 2014 at 01:07:18PM +, hasufell wrote: If you are talking about actually testing and running the software then that's a different story and definitely not within our scope when committing to ~arch. That said, I think it's a reasonable minimum to at least check if an ebuild emerges on my current machine with my current setup before committing to ~arch. If even that fails, what's the point of committing the ebuild? Yes, this is basically what I do. I make sure the ebuild emerges and the software runs in the configuration I was running the old version in. Once I know that's true, I don't see anything wrong with committing to ~arch. William signature.asc Description: Digital signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. What toys? Were we given some when we became developers? If I had some I'd send mine back in, but as I don't, I'll keep committing stable kernel ebuilds that I never test as no one seems to be complaining... greg never make absolute statements k-h
Re: [gentoo-dev] package.mask vs ~arch
Rich Freeman wrote: If we're going to define ~arch as basically stable, and arch as out-of-date, then we might as well drop keywords entirely. I actually don't think that would be such a bad thing. I only consider ~arch relevant, because it is the closest to upstream. I want the distribution I use to be as thin as possible; the value it adds is administrative - and the Gentoo packages and tools are fantastic. \o/ The thicker a distribution is, the larger a gap between users and upstream it creates, which inconveniences *both* users and upstream, because users have to wait for new code, and upstreams have to deal with lots of known and possibly fixed bugs. The ideal would be only live ebuilds, but for now we have no precise technology for synchronization. Version numbers are both blunt and arbitrary. //Peter
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 15:19:59 -0400 Rich Freeman ri...@gentoo.org wrote: On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman tom...@gentoo.org wrote: A test of a package to determine whether it appears to be working OK or whether it destructs your system isn't too much asked for; if it works it can then be ~arch tested, if it breaks you have a bug # for p.mask. If someone can't test it at all, why was it added in the first place? So that it can be tested? Maybe the maintainer doesn't have the ability to test the package (might require special hardware). Maybe the maintainer doesn't have the time to test it right away, but wants to allow others to do so (especially if others show an interest). That is an edge case; it's somewhat hard to maintain a package if you can't test it, and there are occasions (eg. Amazon EC2 related packages) where this is indeed needed. I don't see a need to introduce that masked though; but again, it depends on how edgy it is... Sure, I can set up yet another overlay, which will be empty 99% of the time. But, what is the harm in just using a mask? I've yet to leave one sitting around for years (well, not for testing at least). No problem with that if it is for a safe introduction, although I'm not quite sure how much that really invites actual testing; however it's not about that, everything that stays longer forms the problem. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 Jun 2014 15:44:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 03:14 PM, Tom Wijsman wrote: Setting up an overlay for this and poking a stick at a few developers to try it out could help as an intermediary test, to ensure that you don't break every ~arch user in the progress. Better than all or nothing... Or i can just use the same stick to poke them about the p.masked version in the tree. :) All of this just means, to me, that as long as the packages indeed are actively being pursued for testing, I think it's still fine to use package.mask. However, if things aren't being actively tested (ie they've been forgotten about) then probably whomever added the mask should be pinged relentlessly about it until it's resolved one way or another. At least, I would find it perfectly acceptable to being pinged on any mask I've left rotting in the tree. +1 One could say that ensuring it is tested is part of the workflow; and then I don't mean your own testing, but inviting others to do so. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTtEguAAoJEPWZc8roOL/QKKoIAI0KlFu28ri4KB7gAWJAQXe/ cgvNYy7Gy5kwbl9pagCSP9NhBO0VZ4LNRZIMY0OqOhv/fs9pM2+tdKOV3c/f+8mo 3PvE2zW6+U0NUDBeYDmSdRoCVuFecuZiLk9y8gciGLIipLVZ9jaIwW2N5l/jvT69 KZFLLRgoFvLeXFvg05LUbZgKlMsvpi3DJh0HWG2l0CCuGAw+vNSnFqviPyFWnVCP mhZZuYh3Xwf9/yyrWwKHFY+JjlHD2aqCd1rO9q7Ght/Wbi1knzBt4PE+kgj7xTSo 7BVTEuskcAq4yU9wvmxUYKIyGGwnjmVD5L+fK+LcVnWp4A8zwQG6bk6opiSIFN0= =R2Cc -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Wed, Jul 2, 2014 at 1:56 PM, Tom Wijsman tom...@gentoo.org wrote: That is an edge case; it's somewhat hard to maintain a package if you can't test it, and there are occasions (eg. Amazon EC2 related packages) where this is indeed needed. I don't see a need to introduce that masked though; but again, it depends on how edgy it is... No argument there. I think that use of package masks for testing-related purposes should be rare and short-lived. I just don't think that banning them entirely is the right solution. If they're done right they probably shouldn't be noticed by the majority. Rich
Re: [gentoo-dev] package.mask vs ~arch
On 06/30/14 22:15, Jeroen Roovers wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. I usually avoid overlays (best way to make things hard to find), so when there's stuff that upstream says is experimental (e.g. perl6/rakudo with the MoarVM backend) I have no issue with adding it as un-keyworded ebuilds to the tree. That way it's easy to test, and once there's a bit more confidence that it works well enough it's trivial to keyword.
Re: [gentoo-dev] package.mask vs ~arch
On Tue, Jul 1, 2014 at 8:41 AM, Patrick Lauer patr...@gentoo.org wrote: On 06/30/14 22:15, Jeroen Roovers wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. I usually avoid overlays (best way to make things hard to find), so when there's stuff that upstream says is experimental (e.g. perl6/rakudo with the MoarVM backend) I have no issue with adding it as un-keyworded ebuilds to the tree. That way it's easy to test, and once there's a bit more confidence that it works well enough it's trivial to keyword. If the goal is to reduce clutter in the profiles then this could be a good alternative. Nothing would prevent a maintainer from sticking a comment in the ebuild as well. Hate to derail this, but another option would be to migrate package.mask to a directory (eventually) and manage masks by project or by date. Projects could create standing files when needed, and misc masks would go into a file named by year/quarter. Then anybody looking in the directory can spot projects that are dead, or files which are old. Either would be easier to clean up. Obviously restructuring the profiles entirely as has been suggested will help, though not for masks like these. Rich
Re: [gentoo-dev] package.mask vs ~arch
On Sun, 2014-06-29 at 23:01 -0500, 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 realize that not everybody agrees with me, but I see ~arch as a semi-stable branch - an internally consistent branch for people who don't feel like maintaining a horrific mess of keywords and masks in their /etc/portage and don't want to wait weeks/months for bugfixes to their favorite ebuilds to be marked stable by overworked arch teams, and who don't mind seeing an occasional build failure or crash as a consequence of standing closer to the bleeding edge. In my view, experimental work not ready for general exposure should be kept in overlays and/or the main tree's package.mask, depending on how the particular project's workflow is organized. 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. At any given stability level, a system-critical library ideally ought to be better-tested than, say, a game or a media player. In practice, this sometimes doesn't happen, because some system-critical library maintainers don't care about ~arch users and dump experimental code in their laps, and in my view that's a bad thing because it encourages users to come up with ad-hoc mixed arch/~arch setups which have *never* been tested by any developer. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] package.mask vs ~arch
Am Montag, 30. Juni 2014, 06:01:53 schrieb William Hubbs: 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. Hey William, here's my take: Masked commit: * a part of a bigger version bump, i.e. one of many packages that need to update together * or something where I *know* that issues preventing normal function still exist. I.e., I want to be able to ask others for testing, but something is still missing and I'm actively working on it. ~arch commit: * I'm reasonably sure that it should work; it works for me. Now, one can argue that work in progress should go into an overlay. That in my opinion makes sense for e.g. kde packages and kde overlay, or qt packages and qt overlay, or similar. Making a fresh overlay for one package or asking to add my dev overlay for one required ebuild makes no sense. Only my opinion... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] package.mask vs ~arch
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).
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs willi...@gentoo.org wrote: 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. Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. 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. I agree. I think ~arch should break far more often than it does today. However, I wouldn't extend that to sticking stuff in ~arch that hasn't even been executed. If it is THAT unstable then nobody will want to run it, and that defeats the goal of having more testing. 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. Are they even maintained? If not maintained, then leave them alone until treecleaned. If they are maintained, then I'd be interested in hearing from maintainers as to what they're up to. I wouldn't just remove the mask unless somebody is actually going to co-maintain. The issue of absentee maintainers is a different one than masks, though obsolete masks is a symptom of it just like obsolete ebuilds are. Rich
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 2014-06-30 at 11:29 +, hasufell wrote: 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) A branch is is supposed to be internally consistent: for any X and Y, the latest version of X from a given branch is in theory compatible with the latest version of Y from the same branch. If they are not compatible, there should be a bug that somebody is actively working on resolving, or a blocker dependency, and such blockers ought to be relatively rare to make things easy for human minds and package managers. Masked packages are not a third branch. Some packages are hardmasked for being untested, some for impossible-to-fix bugs, some are known to break a reverse dependency and are waiting for that reverse dependency to be updated, some are lastrited for removal in 30 days. There is absolutely no expectation that all masked packages are compatible with each other. * 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 Stablereq for wine-1.6.2 was filed in February. It got stabilized on amd64 exactly 4 months later. Security stablereq for freetype-2.5.3-r1 was filed in March for all arches. Thus far, only hppa and ia64 stabilized it. People don't bother with filing stabilization requests because they realize that arch teams usually have a long backlog of existing requests, and might take weeks/months to get to your new request. Especially if your new request depends on other stablereqs. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. jer
Re: [gentoo-dev] package.mask vs ~arch
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
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. What harm does it cause to commit an untested package in a masked state to the tree? Doing so violates no policy, and IMHO it shouldn't be considered a policy violation either, especially if it makes life easier on anybody who has actually volunteered to test it. Real life example: Mythtv has a fixes branch which I try to update monthly, but sometimes it is every few months. Sometimes users ping me because a fix is likely to be useful to them, or perhaps to others as well (especially if it has been a while since my last update). Generally I don't put new updates in the tree until I've run them for a day or two at home. That to me is the threshold of minimal testing appropriate for ~arch, but not stable. Some users are clamoring for a new set of fixes, but I don't have time to deploy it at home and test for a day or two. Mythtv is not compatible across versions and involves client/server tiers, a php web interface, and plugins. So, I bump it, test-compile it, and mask it and announce it in the bug so those who really want it can have it. It is probably fine, but I haven't so much as run it so I'm not going to foist it on ~arch. A few days or a week later I get around to testing it myself, and unmask it. Just what value does the distro obtain by banning that workflow? Sure, I could stick it in my overlay, but that is an extra step for users. I just don't see a quality issue here unless we're talking about neglect, and in general neglect will cause quality issues no matter how many rules we create. Rich
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 09:25 AM, Rich Freeman wrote: On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs willi...@gentoo.org wrote: 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. Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOxgJ8ACgkQ2ugaI38ACPC8zAD/XwulPJp4f3xNFe4ZP7gE+kmp qhmdvJjUFyWW8j1dTHMA/jFc/mrH/dnyq/MJWBlUbEFY3ccebpLw/8C6/IaSeXw4 =iKL1 -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 10:37:11 -0400 Rich Freeman ri...@gentoo.org wrote: You're basically asking for the practice of hard-masks for testing to be banned. My original point in the other thread was that masked for testing is not a valid reason. A reference to an outstanding issue, bug report, discussion or other resources would help users determine whether it's safe for them to unmask an ebuild locally. Masked for testing offers no guidance at all and is nothing more than a lazy substitute for real content. jer
Re: [gentoo-dev] package.mask vs ~arch
Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 09:25 AM, Rich Freeman wrote: On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs willi...@gentoo.org wrote: 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. Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. But... if you unmask it, someone will test it and report whether it works :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 11:36 AM, Michał Górny wrote: Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 09:25 AM, Rich Freeman wrote: On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs willi...@gentoo.org wrote: 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. Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOxhOIACgkQ2ugaI38ACPD4NwD/Spcjj7VPGNIz+FCVTkSUDmKZ ghVqFhuiemJO7+G62wgA/jc7bpyPsu8S7wbbNs3UYGqE//MyVYNWHDmOoXDZ3Qsk =FEfS -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Which is great, because then you have an actual test result, whereas before you had nothing but a stupid mask. And lots of people are suddenly very much interested in getting any and all bugs fixed in the new ebuild, whereas before you only had the stupid mask. jer
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Which is great, because then you have an actual test result, whereas before you had nothing but a stupid mask. And lots of people are suddenly very much interested in getting any and all bugs fixed in the new ebuild, whereas before you only had the stupid mask. jer I am going to agree with Jer on this. As said before, ~arch users know that their systems will break sometimes, so if the package works for you, unleash it on ~arch. If someone using a configuration you don't have finds that it breaks, I'm sure it would be reported. Then you could determine whether the bug is severe enough to warrant a mask. William signature.asc Description: Digital signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 12:13 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Which is great, because then you have an actual test result, whereas before you had nothing but a stupid mask. And lots of people are suddenly very much interested in getting any and all bugs fixed in the new ebuild, whereas before you only had the stupid mask. This subjects a lot of users to unnecessary inconvenience. Testing is a necessary inconvenience. Anybody who uses ~arch should be prepared for things to sometimes break. However, foisting completely alpha stuff on users that the maintainer simply hasn't gotten a chance to test yet seems excessive. I'm perfectly fine with the suggestion of requiring a bug reference when masking for testing. I think that adds value. I just don't think that giving the maintainers only the options of introducing untested packages directly to ~arch or not putting them in the tree at all is an unnecessary dichotomy. Why tie our own hands? Again, by all means lets require bug references and consider a masks in the absence of activity a QA issue. I'm less concerned with the actual duration and more with the level of activity. If it takes six months of hard work to get something into the tree, that isn't a problem, but six months of just rusting is a separate matter. Rich
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 12:40:59 -0400 Rich Freeman ri...@gentoo.org wrote: I'm perfectly fine with the suggestion of requiring a bug reference when masking for testing. I think that adds value. You don't mean a reference to a bug report that merely says masked for testing or purports to be a tracker (but isn't), right? jer
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs willi...@gentoo.org wrote: On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Which is great, because then you have an actual test result, whereas before you had nothing but a stupid mask. And lots of people are suddenly very much interested in getting any and all bugs fixed in the new ebuild, whereas before you only had the stupid mask. jer I am going to agree with Jer on this. As said before, ~arch users know that their systems will break sometimes, so if the package works for you, unleash it on ~arch. If someone using a configuration you don't have finds that it breaks, I'm sure it would be reported. Then you could determine whether the bug is severe enough to warrant a mask. We're not talking about packages that work for the maintainer. We're talking about packages where the maintainer doesn't know if they work. Or at least, those are the packages I'm talking about. Everybody seems to think that this is a debate between having newer ebuilds in the tree masked vs unmasked. This is a debate between having newer ebuilds in the tree masked vs not having them in the tree at all. Nobody is going to put an ebuild in the tree unmasked if they don't know that it is going to work, and per earlier comments anybody who does that probably shouldn't have commit privs. Rules won't make maintainers do more work. They can only prevent maintainers from doing certain kinds of work. That is why I tend to oppose more rules unless they actually are preventing some kind of harm, or having a likely benefit. I just don't see the benefit here. I'm fine with a policy that says that packages should only be masked for testing if they're actually being tested and there is some kind of roadmap for getting rid of the mask. I don't like seeing 3 year old masks in the profile either. Let's try to curtail that kind of thing. However, I think we're in danger of throwing the baby out with the bath water here. I cringe anytime I hear somebody say that ~arch has fewer issues than stable, but the solution to that isn't to go looking for opportunities to break ~arch. Rich
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 01:07:17PM -0400, Rich Freeman wrote: On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs willi...@gentoo.org wrote: On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Which is great, because then you have an actual test result, whereas before you had nothing but a stupid mask. And lots of people are suddenly very much interested in getting any and all bugs fixed in the new ebuild, whereas before you only had the stupid mask. jer I am going to agree with Jer on this. As said before, ~arch users know that their systems will break sometimes, so if the package works for you, unleash it on ~arch. If someone using a configuration you don't have finds that it breaks, I'm sure it would be reported. Then you could determine whether the bug is severe enough to warrant a mask. We're not talking about packages that work for the maintainer. We're talking about packages where the maintainer doesn't know if they work. Or at least, those are the packages I'm talking about. The debate is sort of two-pronged, and I split out the package.mask question to another thread. There are 6 year old p.mask entries that just say masked for testing, and those are listed in the new thread I started. Everybody seems to think that this is a debate between having newer ebuilds in the tree masked vs unmasked. This is a debate between having newer ebuilds in the tree masked vs not having them in the tree at all. Nobody is going to put an ebuild in the tree unmasked if they don't know that it is going to work, and per earlier comments anybody who does that probably shouldn't have commit privs. What was said earlier is if a maintainer just runs compile tests then commits the new version that person probably shouldn't have commit privs. Rules won't make maintainers do more work. They can only prevent maintainers from doing certain kinds of work. That is why I tend to oppose more rules unless they actually are preventing some kind of harm, or having a likely benefit. I just don't see the benefit here. The benefit of getting packages into ~arch vs masked for testing is that maintainers can get users to test their packages in configurations that the maintainers are not able to test with. Also, it opens up the package to more testing because it will be exposed to more users with different configurations. I'm fine with a policy that says that packages should only be masked for testing if they're actually being tested and there is some kind of roadmap for getting rid of the mask. The problem I see with masked for testing is probably similar to what you are talking about. If something is masked for testing, there should be a push from somewhere to not keep it masked for testing. I don't like seeing 3 year old masks in the profile either. Let's try to curtail that kind of thing. However, I think we're in danger of throwing the baby out with the bath water here. I cringe anytime I hear somebody say that ~arch has fewer issues than stable, but the solution to that isn't to go looking for opportunities to break ~arch. I don't like seeing old masks in the profiles either. p.mask should never be permanent, but there are other issues associated with making that happen that should be in other threads probably. All I'm saying about ~arch is that it is known to break and will continue to break, so lets not try to pretend otherwise. Someone in this thread said ~arch is semi-stable; it is not. If you use ~arch you are on your own and expected to be able to handle any breakage that comes up. William signature.asc Description: Digital signature
[OT] Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 02:04:20 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: I realize that not everybody agrees with me, but I see ~arch as a semi-stable branch - an internally consistent branch for people who don't feel like maintaining a horrific mess of keywords and masks in their /etc/portage and don't want to wait weeks/months for bugfixes to their favorite ebuilds to be marked stable by overworked arch teams, and who don't mind seeing an occasional build failure or crash as a consequence of standing closer to the bleeding edge. [[ TL;DR: This mail is a confirmation with some more side details. ]] +1. I do agree; it works well, and the occasional regression that manages to get through often isn't too bad. Maybe once in multiple years you end up with a broken boot; however, that's not a huge problem if you plan upgrades to not be in front of a deadline / presentation. In my view, experimental work not ready for general exposure should be kept in overlays and/or the main tree's package.mask, depending on how the particular project's workflow is organized. Indeed; take for example MATE, I bump the packages over a span of a few days and keep it masked until mate-base/mate. With GNOME it is similar. This is a case where I need more packages do the standard developer testing; so, I can't just have an individual package unmasked without being able to confirm that it actually works at run-time. For version bumps / new packages I just don't add them to the tree till I have confidently tested for it to not be a bug magnet, but rather a stabilization candidate; I thus don't understand such p.mask entries. At any given stability level, a system-critical library ideally ought to be better-tested than, say, a game or a media player. In practice, this sometimes doesn't happen, because some system-critical library maintainers don't care about ~arch users and dump experimental code in their laps, and in my view that's a bad thing because it encourages users to come up with ad-hoc mixed arch/~arch setups which have *never* been tested by any developer. The granted ability to make a choice brings its own limits. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 10:12:14 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Masked commit: * a part of a bigger version bump, i.e. one of many packages that need to update together * or something where I *know* that issues preventing normal function still exist. I.e., I want to be able to ask others for testing, but something is still missing and I'm actively working on it. This is how I like it to be; for ebuilds that are known as broken, even when that is due to them being incomplete (multiple packages). When testing packages are added as masked, they miss out on more testing; now consider that they might just work, you can miss out on smaller edge case^ bugs if a faster stabilization* must follow later. ^ The more users, the more different system environments, ... * Reverse dependency that needs it, security and so on. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 10:48:22 -0400 Rich Freeman ri...@gentoo.org wrote: On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers who HAVEN'T [...] TESTED AT ALL and still commit their changes to the tree should immediately hand in their toys and leave the project. What harm does it cause to commit an untested package in a masked state to the tree? Doing so violates no policy, and IMHO it shouldn't be considered a policy violation either, especially if it makes life easier on anybody who has actually volunteered to test it. should != must; that joke aside, while it's not punishable by policy (and shouldn't even be punished if it's not repeated behavior) we rather need to keep the package.mask file of a reasonable size. The goal of this file is to have an overview of what _is_ BROKEN; when you add a lot of UNSURE, its contents will diverge away from this goal. A test of a package to determine whether it appears to be working OK or whether it destructs your system isn't too much asked for; if it works it can then be ~arch tested, if it breaks you have a bug # for p.mask. If someone can't test it at all, why was it added in the first place? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/06/14 11:36 AM, Michał Górny wrote: Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius a...@gentoo.org napisał(a): Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Setting up an overlay for this and poking a stick at a few developers to try it out could help as an intermediary test, to ensure that you don't break every ~arch user in the progress. Better than all or nothing... - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTsbcmAAoJEPWZc8roOL/QOVMH/3PXYSKNIOnEbsuo6JbHoksZ UO7D88KNsN0Z8sbygsjM3H6Qkh6+iQSIqIhu8g6Y5OvT2bndz/qoJI3jIyO/Kjg/ no9tfiuCT61erHpQDg81LuPA2IaQnL1DbnNmsYl+j7SIMxu3R7nWLu0VmZbp1DA+ aEWn4eZX9z6IMqQWRDGmiJ7LAyJk36qFZwsvIlUJvfEJQEr0nIhJ+9UQsiNq0sPJ ytZ5VI14MXW2bY84THWxn12Svey42AEsd9ggzgHnWp04v08NWseypvI69kAyvM0z pu2G9k7QAx/ULNz9BuzZUm2vBO7D5qROy1G3EEY+GqySkqYNefOgobtY3CT/T8M= =1qIF -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 11:32:35 -0500 William Hubbs willi...@gentoo.org wrote: As said before, ~arch users know that their systems will break sometimes, so if the package works for you, unleash it on ~arch. If someone using a configuration you don't have finds that it breaks, I'm sure it would be reported. Then you could determine whether the bug is severe enough to warrant a mask. As long as important/core/system packages don't result in a wide scale breakage on ~arch this approach should be fine; we've been doing fine before, so I don't think that this warrants a change in what we do. Just want to note that you can get an idea from previous outages (or similar events like python-exec / UPower) on how much testing is needed. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] package.mask vs ~arch
On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman tom...@gentoo.org wrote: A test of a package to determine whether it appears to be working OK or whether it destructs your system isn't too much asked for; if it works it can then be ~arch tested, if it breaks you have a bug # for p.mask. If someone can't test it at all, why was it added in the first place? So that it can be tested? Maybe the maintainer doesn't have the ability to test the package (might require special hardware). Maybe the maintainer doesn't have the time to test it right away, but wants to allow others to do so (especially if others show an interest). In my example of mythtv, testing might require first updating all the front-ends to be current and ensure that nothing breaks (it might only be emerge --sync'ed monthly). Then a window has to exist where nothing will be recorded. Then everything gets brought down and backed up (not a big deal, but nobody is watching TV for a while). Then you update everything and see if it works, perhaps having to tweak things a bit. Then you do the quick tests (record shows, play things back, check the web front end). Then you leave it alone for a day and see if anybody screams - best not to do this if you'll be really busy the next day. If people are clamoring for an update, it may be more productive to just let them have it with a disclaimer about quality, rather than just putting them off for a week or two. Sure, I can set up yet another overlay, which will be empty 99% of the time. But, what is the harm in just using a mask? I've yet to leave one sitting around for years (well, not for testing at least). Rich
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/14 03:14 PM, Tom Wijsman wrote: On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/06/14 11:36 AM, Michał Górny wrote: Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius a...@gentoo.org napisał(a): Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by me for testing, because when I converted it to multilib i needed to change the way it does some internal ABI determination tests, and although I know it does work fine on multilib-amd64 and (non-multilib) x86, I am not confident without more testing that it will work for cross-compiles or other non-multilib arches. As such, it -is- in the tree, but I've masked it until I can test it myself in these circumstances or find someone else that can do it for me. But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Setting up an overlay for this and poking a stick at a few developers to try it out could help as an intermediary test, to ensure that you don't break every ~arch user in the progress. Better than all or nothing... Or i can just use the same stick to poke them about the p.masked version in the tree. :) All of this just means, to me, that as long as the packages indeed are actively being pursued for testing, I think it's still fine to use package.mask. However, if things aren't being actively tested (ie they've been forgotten about) then probably whomever added the mask should be pinged relentlessly about it until it's resolved one way or another. At least, I would find it perfectly acceptable to being pinged on any mask I've left rotting in the tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOxvhUACgkQ2ugaI38ACPBqfQD/b4Rj0qoczFNwQO6jfnQjkL74 wFvxDV4SvER3BOyZRKkBAK5C63zG0YEAZvpfYTd6CwNLeX4cNdZXuVyMTqbPhx5k =DbOV -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On 06/30/2014 11:27, Jeroen Roovers wrote: On Mon, 30 Jun 2014 10:37:11 -0400 Rich Freeman ri...@gentoo.org wrote: You're basically asking for the practice of hard-masks for testing to be banned. My original point in the other thread was that masked for testing is not a valid reason. A reference to an outstanding issue, bug report, discussion or other resources would help users determine whether it's safe for them to unmask an ebuild locally. Masked for testing offers no guidance at all and is nothing more than a lazy substitute for real content. I would agree to a point. In the case of some toolchain related packages, like gcc and binutils, masked for testing keeps potentially dangerous system updates from propagating out to a majority of users. However, those users and developers who are quite avid about being on the forefront of the latest and greatest already know how to unmask such packages and test them out. So a mask on =sys-devel/gcc-4.9.0 with the reason of Masked for testing makes perfect sense, especially since this version of gcc enables strong stack-protection. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] package.mask vs ~arch
On 06/30/2014 09:25, Rich Freeman wrote: On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs willi...@gentoo.org wrote: 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. Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Or maybe they tested it in a very limited set of circumstances but know that other untested circumstances are important to the users and they have definite plans to get them tested. I think what needs to be defined here is testing. What if I know of a group of packages that are not only open-source and compile w/o major issues, but are in use in enterprise environments, and not yet in Gentoo? Would not a compile and ship it approach, into ~arch, work best for something like that? Do I really need to set up a testing platform for them and test each one out? That's just one example, though. Perhaps we need to work up some very broad and general guidelines on what testing means, and apply that to ~arch. 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. I agree. I think ~arch should break far more often than it does today. However, I wouldn't extend that to sticking stuff in ~arch that hasn't even been executed. If it is THAT unstable then nobody will want to run it, and that defeats the goal of having more testing. I've been running ~arch for years and very rarely, do I see a breakage. We're not one of the BSDs, or even Debian, in which we maintain a static branch of specific package versions. In a way, I view arch to imply something very close to FreeBSD's -RELEASE branch, just with the flexibility of getting new major revisions periodically. ~arch is more like -STABLE, but it moves faster and potentially introduces minor breakages once in a while, but nothing that requires a complete reinstall. We don't really have anything that's like -CURRENT or a nightly-like build, in which major, massive breakages are more common. TBH, I don't know if we should have something like that. The hybrid-like approach we have now seems to work out best for us. 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. Are they even maintained? We probably just need to step up review and cleaning out of package.mask more often. Since Portage tools can parse the file already, it shouldn't be too hard to determine if there are any masks in there for packages or package versions that no longer exist in the tree and prune it down some. If not maintained, then leave them alone until treecleaned. If they are maintained, then I'd be interested in hearing from maintainers as to what they're up to. I wouldn't just remove the mask unless somebody is actually going to co-maintain. The issue of absentee maintainers is a different one than masks, though obsolete masks is a symptom of it just like obsolete ebuilds are. Perhaps some periodic, automated reminders to anyone who adds a package to package.mask to check up on it? If the mask persists for a while after such a notification, it escalates to QA or to -dev? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 15:49:54 -0400 Joshua Kinard ku...@gentoo.org wrote: So a mask on =sys-devel/gcc-4.9.0 with the reason of Masked for testing makes perfect sense, especially since this version of gcc enables strong stack-protection. In that case this version of gcc enables strong stack-protection [which might kill your cow] is a good masking reason. Go for it. Masked for testing never makes sense, let alone perfect sense, because the intent (testing) is prevented by the action (masking). On the other hand, unmasked for testing would make perfect sense. jer
Re: [gentoo-dev] package.mask vs ~arch
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
Re: [gentoo-dev] package.mask vs ~arch
On 2014.06.30 16:40, Ian Stakenvicius wrote: On 30/06/14 11:36 AM, Michał Górny wrote: [snip] But... if you unmask it, someone will test it and report whether it works :P. But... if I unmask it, -everyone- using ~arch will install it and it'll break all the systems that it doesn't work on, which -could- be quite a lot at this point. :D Yep. The good old days ... X11 going modular ... expat-2 and a few others that I've forgotten. There was no news then so if you missed an email to the list you got to pick up the pieces. Those examples may well be me missing emails. I've run ~arch since mid 2002 and until the last few years always had a few builds fail or things build then operate so badly they needed to be p.masked locally. That's what buildpkg is for ... so that after you spend 10 hours building *office and find out its a dud, you can back it out in a few minutes. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpjfKriB3eLY.pgp Description: PGP signature
[gentoo-dev] package.mask vs ~arch
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 signature.asc Description: Digital signature
