On Fri, 2011-09-09 at 12:22 +0200, Vít Ondruch wrote:
> Sorry, you are mixing two things:
>
> 1) One is testing environment and it can be probably well defined,
> clean, etc.
And thus incomparable to real-life environments. Mind, I'm not arguing
against some testing (e.g. automated regression tests, AutoQA) being
done in defined environments. But I doubt that it's enough if all
testing is done under these conditions, because this implicates we need
to define, and test against, all (or at least the majority of)
environments under which our software could be run, which frankly is
unrealistic. Therefore I'd rather have people also test in their
"naturally grown" environments to better cover real life situations that
deviate from defaults.
> 2) The other thing is maintainer mindset. You can try to convince
> yourself to take a different look but I doubt it will work. It reminds
> me like if you do patch review of your patches, which doesn't make
> sense. You, as a developer, are not able to spot weak points.
This is quite condescending, and a straw man to boot. Testing a piece of
software in the way we do it is on no way comparable to reviewing
patches: In the one case I'd be using the software _like any other user
or tester_, try out some functionality, partly related to what was
intended to be fixed, partly a few basic functionality ("smoke") tests,
in the other case I'd be looking at code changes which I worked on for
let's say the last few hours or even days. I grant you that the latter
case invites say a less skeptical approach than is warranted when
reviewing patches, but it's also much harder to do and much less well
defined (thus much easier to trick yourself into biased behavior) than
the former: with testing it's clear what you have to do (to a maintainer
or developer possibly even more than John Random Tester) and it's clear
how results should be interpreted. Either it does what it's supposed to
do, or it doesn't. If it doesn't, and it did before, it's a regression.
If I can describe to a tester how something should be tested, I can test
it myself.
> And it is
> expected that every developer delivers well tested and well behaving
> code from his side (i.e. automatic +1 karma from his side).
And that's wrong either way how I look at it: If I submit an update only
after I've done testing in the way I described above, I've wasted
precious time in which others could have tested as well. If submitting
an update would automatically imply that level of testing, I couldn't
submit updates for Fedora releases which I don't use.
When I submit an update it usually means that I've tried out the code
(not necessarily the package, probably rather from a checked out source
tree), checked it against bugs supposed to be fixed and done minimal
smoke tests. Nothing more.
> If there is
> not enough karma for his package to bring it into the stable, then there
> is probably time to ask somebody (probably on fedora-devel), to test
> this package.
We have a default of +3 karma for automatic pushes to stable, so a +1
from the maintainer by itself isn't enough to push an update to stable
already. Non-critical-path updates can be pushed to stable within 7 days
of them having been pushed to testing, without any karma at all, which
seems a much lower hurdle if I wanted to dump broken software onto
people.
> BTW no policy can stop some "evil maintainer" who will create other
> Fedora accounts and give karma to his packages under different
> identities.
And that's supposed to mean... what?
> You can even add karma without Fedora identity, but I am not sure if
> that counts.
It doesn't.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
