Peter Volkov wrote:

1. Our good non-formal policy "if developer touched anything he becames
responsible for that ebuild and should fix issues noticed" is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.


Keep in mind the downside to such a policy is that people just ignore
problems that are trivial to fix, because they don't have the time to go
over the ebuild with a fine-toothed comb. Then, if people get their
heads chewed off on -dev if they do miss something that lowers the
motivation just a bit more.


Sure, if a dev fixes an ebuild they should give it a once-over to make
sure there are no major problems, and obviously they should do moderate
testing to make sure it builds and works. However, if I spotted a minor
problem with an ebuild that I could fix, and a major problem that I
couldn't fix, chances are that I wouldn't touch it at all. Then the
ebuild stays in the tree with both problems, instead of one fewer.


I think it all boils down to "we're all in this together." If you see a
problem try to fix it, and if you see somebody make a mistake try to
help them out. While we do need policies, and policies do imply
police, nobody likes the police, so let's try to make that work with the
minimum in fuss. A good rule of thumb is whether a dev has left a
situation better off or worse off than when they touched something, and
in this case I'd have to say that we're better off.


While the good can be the enemy of the best, sometimes the best can be
the enemy of the good, and I think that sums up the current situation well.

On Monday 09 November 2009 13:08:52 Peter Volkov wrote:
[Snip]
> Well, it looks like the root of this problem is the following statement:
> "QA is less important then new packages in the tree". I failed to hear
> any arguments why QA is unimportant so I still believe that QA problem
> is a problem.
>
Ok, here's the real problem;

"Unmaintained stuff is unmaintained"

And instead of being happy that people like ssuominen just fix things where
other people don't (be it because these other people have no interest, only
care about a few packages or have become distracted with life) some people get
really confused and start working on demotivating us.

You should understand one thing: I don't care at all about most packages. I'm
handling virtualbox because right now jokey doesn't seem to have the time. I
fixed Xen bugs because drobbins pointed out that there were a few bugs with
it, and the current maintainers seem to have gone for a long walk in the park.
Can't blame anyone there (I've disappeared for some time too), but those
packages would be in a really useless state now.
And if I break something for a day or two, well, that's ~arch for you. I try
to avoid breaking things, but if things break in ~arch the users shouldn't be
too surprised. Otherwise we wouldn't even have to care about having the
arch/~arch split. Better a slightly buggy version than a security-exploitable
version. Especially when the bug gets fixed the next day.

So find me a dozen recruits that can properly maintain things and I won't feel
the need to touch random packages. Stop living in your sandbox and have a look
at the bigger picture
(Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users
discover them. I love that QA!)
I'm trying to get people to help me, but it's a slow tedious process to even
motivate most. And then our recruiting puts up a virtual wall many don't want
to climb over. At times it's tiring, it's demotivating, and still we go on.
Because we still believe that we can improve things. And as they say, you
can't make an omlette without breaking some eggs.

Take care,

Patrick