submitters +1ing their own packages

[Andre Robatino]

Kevin Fenzi <kevin <at> scrye.com> writes:

> * As a maintainer you should only be pushing an update you feel
>   works/fixes something anyhow. Shouldn't that be an implied +1 always
>   from the maintainer?

Well, there's actual testing, vs. being convinced based on the apparent
simplicity of a patch that it doesn't need to be tested. I've seen a number of
non-working "fixes" that obviously fell into the second category, given that
they failed in a 100% reproducible, environment-independent way, and would have
only taken a minute or two to actually test.

> * As a maintainer it's easy to have a env that gets out of sync with
>   what a QA or end user would use. Ie, you make 20 iterations of a
>   package to test something, tweak configs to check something, and get
>   it all working, but perhaps your machine is no longer setup the way a
>   fresh install or upgrade of your package would be. Or you tested a
>   version and then changed just 'one little thing' and pushed that and
>   it turned out to break it. 
> 
> * Even the best of us would like another pair of eyes to confirm
>   something is really fixed/working. 

Obviously packagers may have more trouble doing objective testing than
outsiders, but it's possible. My opinion is that packagers should be allowed to
+1 their own packages after a certain delay (1 week, maybe?) if it hasn't gotten
sufficient karma from others by then, and they do actual testing in a non-custom
environment (for example, maintain a VM with close to default settings). If a
packager repeatedly submits +1 for updates which turn out later couldn't
possibly have worked in actual testing, then their karma privileges could be
revoked.