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
